stsymmt.comかnote.stsymmt.comか、Search Console登録で迷った日
前回、Google Search Console（GSC。Googleが無料で提供している、自分のサイトが検索でどう見えているかを確認できるツール）の所有権確認方式を「DNSのTXTレコード（ドメインの管理情報に文字列を1行追加する仕組み）で証明する」やり方に決めた。今日はその続きで、実際にGSCとAWSのDNS管理サービスであるRoute 53の設定を進めた。作業を進めるうちに、大小合わせて4つの迷いどころが出てきたので、それぞれどう考えて答えを出したかを記録しておく。
1. 登録するのはstsymmt.comか、note.stsymmt.comか
結論から言うと、ルートドメイン（stsymmt.com）を登録することにした。
CodeNoteは実際にはnote.stsymmt.comというサブドメイン（ドメインの前に付く「部屋番号」のようなもの）で動いている。だから素直に考えれば「実際に動いているサブドメインをそのまま登録すればいい」となりそうだった。ただ、将来www.stsymmt.comで別のホームページを作る計画があることを思い出し、念のため計測範囲の違いを調べ直した。
- ルートドメイン（
stsymmt.com）を登録すると、配下の全サブドメイン（note.も、将来のwww.も、api.も）が1つのプロパティに自動で集約される - サブドメイン（
note.stsymmt.com）を登録すると、そのサブドメイン自身とさらに配下のものだけが対象になる。GSCのヘルプにも「子ドメインのプロパティには親ドメインのデータは含まれない」とはっきり書かれていた
イメージとしては、ルートドメインの登録はマンション全体の集合ポストを1つ用意するようなもので、サブドメインの登録は1部屋分のポストだけを用意するようなものだ。集合ポストなら、後から入居する部屋（将来のサブドメイン）の郵便もまとめて受け取れる。
ここで「全部混ざって見づらくなるのでは」と一瞬心配になったが、これは杞憂だった。GSCのパフォーマンスレポートにはページ（URL）の絞り込みフィルタがあり、後からnote.だけ、www.だけと個別に見ることができる。さらに、GSCは同一アカウントで最大1,000件のプロパティを重複登録できる。つまりルートドメインとサブドメインを両方登録することもできるので、「ルートドメインを選ぶと後戻りできない」という不安も実は当たらなかった。
将来のwww.stsymmt.com開設を見据えて、今回1回のDNS検証で済ませておけば、後からサブドメインを増やすたびに再登録する手間もなくなる。この理由でルートドメインを選んだ。
2. Route 53のTXTレコード、引用符は本当に必要か
手順書には「値は前後を二重引用符で囲む」と書いてあった。ただ、以前Route 53でCNAMEレコード（ドメインの別名を指定する設定）を作ったときは、そんなことをした覚えがない。この違和感から調べ直した。
分かったのは、そもそもレコードの性質が違うということだった。CNAMEは「ホスト名」という単一の値を持つのに対し、TXTレコードはDNSの仕様上「自由なテキスト」を格納するためのもので、慣習的に二重引用符で囲む形式になっている。
問題はここからだ。Route 53のコンソールが「入力した値に自動で引用符を補完するのか」「それとも手入力した引用符をそのまま使うのか」については、確認したソースの間で食い違いがあった。AWS公式ドキュメントには引用符付きで入力する例が載っている一方、ユーザーコミュニティには「Route 53が自動で引用符を追加するので、手入力すると二重引用符になってしまう」という報告もあった。
どちらが正しいか、断定できる情報源は見つからなかった。ここで無理に答えを決めつけるのはやめ、代わりに「引用符ありで作ってみて、保存された値を見て判断する」という検証ステップを手順に足しておいた。
そして実際に手を動かしてみた結果、答えがはっきりした。引用符なしでそのまま入力しても、レコード一覧の表示にはちゃんと引用符が付いていた。 つまりRoute 53は保存時に自動で二重引用符を付与する仕様で、もし手入力でも引用符を付けていたら、二重に引用符が付いた値になってしまっていたということだ。ユーザーコミュニティの報告の方が実態に合っていたことになる。
断定できない情報に出会ったときに無理に答えを決めつけず、実際に確認できる手順を用意しておいたのがここで効いた。おかげで「どちらが正しいか分からないまま進める」ことにならずに済んだ。
3. サイトマップの登録、相対パスでいいと思っていたら違った
以前作った手順書には「サイトマップの入力欄にはsitemap.xmlという末尾のパスだけ入れればいい」と書いていた。これはURLプレフィックスプロパティ（https://note.stsymmt.com/のように単一のURLに固定されるプロパティ）を前提にした書き方だった。
ところが、今回はプロパティ種別をドメインプロパティに変更している。ドメインプロパティは複数のサブドメイン・プロトコルをまとめて扱うため、「この相対パスをどのホストにくっつければいいのか」という基準そのものが存在しない。相対パスだけ渡しても、どこにつなげればいいかGSC側が判断できないということだ。
調べ直すと、ドメインプロパティでサイトマップを登録する場合は、サブドメイン・プロトコルを含む完全なURL（https://note.stsymmt.com/sitemap.xml）を入力する必要があるとわかった。
もしこれに気づかず古い手順のまま進めていたら、GSC側は「どのサイトのサイトマップか特定できない」状態になっていたはずだ。プロパティ種別を変えたら、それに紐づく他の手順も全部見直す必要がある、という当たり前のことに改めて気づかされた。
4. サイトマップを登録したら、すぐインデックスされる？（軽めの疑問）
これは作業の合間に聞かれた素朴な疑問だった。サイトマップを送信した後、どのくらいでインデックス（検索結果に載る状態になること）されるのか、と。
調べたところ、Googleの公式ドキュメントには「サイトマップの送信は単なるヒントであり、Googleがダウンロード・クロールに使用することを保証するものではない」とはっきり書かれていた。期間の保証はどこにもない。
個別のページを急いでインデックスさせたい場合は、URL検査ツールから任意でインデックス登録をリクエストできる補完手段もある。ただし1日10〜12件程度の上限があるとされていて、記事を量産するような使い方には向かない。
「サイトマップを送ったから安心」ではなく、「ヒントを渡しただけ」くらいの期待値で運用するのが正しい、と認識を改めた。
今日の学び
- プロパティ種別（ドメイン/URLプレフィックス）を変えると、計測範囲だけでなく「サイトマップの入力形式」のような細部の手順まで前提が変わる。一箇所の設計変更は、それに連なる手順全部の見直しを要求してくる
- 断定できない情報（Route 53のTXT引用符の自動補完有無）に出会ったとき、無理に答えを決めつけるより、「実際に作って確認する」という検証可能な手順に変換したほうが安全。今回はそれが功を奏し、Route 53は値を自動で引用符付きにする仕様（手入力すると二重になる）と実機で確定できた
- 「サイトマップを送信する」＝「インデックスされる」ではない。Google自身が「ヒントに過ぎない」と明言している
本記事は Sonnet 5（claude-sonnet-5）が生成しました。