把握していたのは4サイト、実際は15ドメイン — 手持ちのサイトを棚卸しした日

持っているサイトは4つ、と口で説明した。数え終わったら15あった。

説明できたのは4つだった

ようやくWordPressをホスティングへ移し終えたので、全体を一度点検しておきたくなった。 まず、どのリポジトリがどのドメインで公開されているかを自分の口で並べた。WordPressから移してきたサイト、法人名義のサイト、日々やっていることを出しているこのブログ、仕事用のランディングページ。4つである。この4つを順番に見ていけば終わる話だと思っていた。

リポジトリごとに調査エージェントを立てて並列で走らせ、別に1体、本番へ実際にアクセスして生存とヘッダを確かめる係を置いた。最終的に7体を投げたことになる。リポジトリ調査が4本、本番のライブ確認、旧アプリの移行可否、このブログのナビ構造分析である。 途中でモデルのセッション上限に当たって4体が落ちた。ナビ構造を調べていた1体だけが完走して結果を返していたので、残りは上位モデルの枠に切り替えて再開させた。

戻ってきた報告で、数が合わなくなった。

仕事用のランディングページは1枚ではなかった。1つのコードベースから業種別に量産する仕組みで、そのうち10サイトが本番で200を返していた。もう1つ、実体はデプロイ済みなのにDNSが繋がっていないものがある。さらに、画像配信用のサブドメインが1つ動いていた。

把握していた4つに、業種別ページ群と画像配信用を足して、公開ドメインは全部で15。自分の持ち物のうち3分の2は、朝の時点で口に出せていなかった。 どれも自分で作って自分でデプロイしたものである。作った記憶はあるのに、いま生きているかどうかの記憶がなかった。

「統合は考えていない」と言った数分後に、自分で前提を崩した

旧PaaSに残している学習アプリの話になった。記事はそのまま生かしたいが、新規に配信する予定はない。だったらPaaSを止めて静的化してしまえばいい、という案が出た。

実体を確かめさせたら、そのアプリはPaaS上で今もSSRとして動いていた。レスポンスヘッダにPaaSのルーター名とサーバー名が残っている。今のホスティングは前段のCDNとして通っているだけで、PaaSが止まればサイトも落ちる。DB接続もサーバー側の環境変数もないので、静的化なら1〜2日で切り離せるという見込みまで出た。

そこで、このアプリを別サイトへ寄せるかどうかが論点になった。 私は独立したまま両方残す前提だと言った。統合は考えていない、と。

その数分後に、自分でその前提を訂正することになった。

もともと、このアプリは法人名義のサイトへ統合する構想だったのを思い出した。忘れていた。 思い出しただけでなく、証拠が出てきた。旧WordPressサイトにあった仕訳問題の6つのURLが、法人名義のサイト側の4ページへ301していた。飛び先を叩くと4つすべて実在する。受け皿は先に作られていたわけだ。2月に書いた移行計画にも、このアプリを旧PaaSから移す話がそのまま書かれていた。

統合した方がいいという一般論は理解できる。受け皿も一部は動いている。 それでも、独立させたまま両方残す判断は変えなかった。片方は凍結したアーカイブとして置いておきたいだけで、育てるつもりがない。育てないものを、育てているサイトに混ぜても導線が濁るだけだと考えた。

訂正はもう1件あった。「移行提案書が過去にある」と示された資料を裏取りさせたら、それは名前の似た別アプリのもので、このアプリとは無関係だった。旧PaaSからの移行は、これまで一度も検討されていなかった。実体のソースが入っているリポジトリも別だった。 自分の記憶違いを1つ、示された根拠の読み違いを1つ、同じ日に潰したことになる。

棚卸しで出てきた実害

役割をどう整理するかを考えるつもりだったのに、その手前で拾うものが増えた。役割の話は明日でも困らないが、訪問者と検索エンジンに今日ぶつかっているものは別である。

このブログのトップページに、404へ落ちるリンクが3本出ていた。 いずれも踏むと必ずエラーページに着く。原因は nuxt.config.ts の設定矛盾だった。6月12日に「インデックスさせずに一般公開する」意図でプリレンダリング対象へ追加したのに、別の箇所の除外設定が優先されて生成されないままになっていた。ビルドログには「Added N routes」と成功の顔で出るので、成功したと思い込む。1か月半、リンクだけが表に出ていた。

法人名義のサイトと業種別ページ群で、<title> とmeta descriptionが本番HTMLに存在しなかった。 本番のHTMLにgrepをかけても1行も出てこない。SSR自体は効いているので、head設定の抜けである。検索結果ではタイトルの代わりにURLが並ぶ状態だった。

そのほかに拾ったもの。

• サブドメインなしの素のドメインが、全パスを法人名義サイトのトップへ301していた。パスを落として集約するので、移設したばかりのページには誰も到達できない
• 法人名義のサイトの sitemap.xml が404。robots.txt にもSitemap行がなく、URL一覧を渡す口がない
• このブログの本番HTMLに localhost:4000/api が残っていた。開発用のローカルアドレスがそのまま配信されている
• 法人名義サイトの1ページが、canonicalとして旧PaaSアプリのURLを指していた。その参照先は404。存在しないページを正規URLとして宣言し続けている
• 旧WordPressサイトの記事本文に、旧PaaSアプリのドメインへの参照が120箇所あった。PaaSを止めれば全部切れる
• このブログのトップページには57本のリンクが並び、グローバルナビがない。読み物とテスト用デモが同じ平面に同居している

移行が途中で止まっているものも見つかった。資格試験向けの教材を別サイトへ移す計画を6月に立てていたのに、このブログ側には「準備中」の見出しが残ったままだった。

現状分析で区切った

集まった調査結果を図解4枚にまとめ、1本のHTMLドキュメントにした。図はどれも文字のはみ出しがないことを確認し、Chromeで開いて表や図の描画も自分の目で見た。

ここで手を止めた。解決策は書いていない。 書けなかったのではなく、書くと私の判断を先取りしてしまう論点が5つ残っていたからだ。

• 旧PaaSのアプリを静的化して残すか、法人名義のサイトへ寄せるか
• 各サイトの役割を明文化するか
• 英単語の語源コンテンツを法人名義のサイトに置き続けるか
• 業種別ページを今の数のまま維持するか
• 旧WordPressサイトを何のサイトとして残すか

翌日の積み残しとして登録した。再開するときは、まず計画書をChromeで表示するところから始める段取りにしてある。 登録後の確認スクリプトが文字化けしてセクションの判定を誤ったので、エンコーディングを指定して読み直させた。ここだけ二度手間になった。

静的化の前に確かめておくことも1つメモに残した。旧世代のフレームワークで書かれているので、いま手元にあるNode 22でそのまま静的生成が通るかは分からない。落ちるなら古いNodeを用意するところから始まる。

残ったもの

朝に4つと言い、夜に15と数えた。増えたわけではなく、10か月前や5か月前の自分が作って、そのまま公開したままにしていたものが返ってきただけである。

棚卸しで一番効いたのは、ドメインの数そのものではない。 「これは独立で残す」と言い切った直後に、自分が過去に別の構想を持っていた事実を突きつけられたところだ。前提は記憶の中では確定しているのに、リポジトリの中では別の答えが動いていた。301の飛び先が、私より正確に私の意図を覚えていた。

判断そのものは変えなかったので、決め直したことは何もない。 ただ、明日の最初の判断は論点1になる。止めれば月々の支払いが1つ消えるアプリを、静的化して独立に残すのか、受け皿のある側へ寄せるのか。ここだけは、301の記録に決めさせるわけにいかない。