このAstroブログのSEO周りを、Codexと一緒に整えた。canonical、OGP、記事の構造化データを確認し、Google Search Consoleも設定した。

その中で気になったのが、「memida」と検索するとContactが上の方に出てくることだった。ページを直したことと、検索結果が変わったことを混同しないように、作業と確認結果を分けて残しておく。

画像：Google Search Centralの共有用画像。

ページの情報を、一か所から出す#

このサイトでは、Meta.astroという共通コンポーネントから、ページタイトル、説明、canonical、OGP、構造化データを出している。

canonicalは、そのページの正規URLを検索エンジンへ伝えるための指定だ。現在の実装では、アクセス時のクエリ文字列を含めず、サイトの公開URLとパスから組み立てている。通常のページの末尾にはスラッシュを揃えている。

情報	このサイトでの扱い
タイトル・説明	ページ固有の値を渡し、OGPにも使う
canonical	公開ドメインとパスから生成する
記事の著者	共通設定から名前とAboutへのリンクを取得する
公開日・更新日	記事に保存した値を使い、ビルド日で上書きしない
記事画像	通常の表示と、共有用OGPの参照先を確認する

ページごとに同じ情報を別々に書くと、タイトルだけ直ってOGPが古い、といったずれが起きやすい。値の入口を揃えて、出力先をまとめて確認できる構成にした。

構造化データも、記事のデータから作る#

記事にはBlogPosting、サイトにはWebSite、著者にはPersonという種類を使っている。記事と著者の関係は、同じ識別用の@idを参照してつないでいる。

記事のタイトル、説明、日付、画像、著者URLは、ページの表示に使うデータから組み立てる。Googleの記事向け構造化データの説明を参考に、ページの内容を機械にも伝わる形にしている。

JSONをHTMLへ埋め込むところでは、JSON.stringify()のあとに小なり記号をUnicodeエスケープへ置き換えている。記事に入る文字列が、script要素の終わりとして解釈されることを避けるための処理だ。

構造化データを出しただけで、検索順位が上がったとは言えない。今回まず確認したのは、生成された値が記事と一致し、参照するURLや画像が存在することだった。

AEOの前に、普通に読めるサイトを整える#

AI検索への対応も気になっていたが、今回追加した中心は、ページの説明、著者情報、リンク、サイトマップなどだ。

GoogleのAI検索向け案内では、AIによる概要やAIモードのための特別な最適化は必要なく、通常のSEOの基本が引き続き重要とされている。

そこで、専用ファイルやFAQを増やすことより、記事が取得でき、内容と著者が分かり、公開記事へたどれる状態を先に整えた。これはGoogleの案内に基づく判断で、すべてのAIサービスへの掲載を保証するものではない。

ビルドと、本番の両方を見る#

整備時には、生成されたHTMLのcanonical、OGP、構造化データと画像の参照先を確認した。RSSとサイトマップにも公開記事が含まれることを確認している。下書きの扱いは、別の記事にまとめた。

公開後にも、本番のHTMLとrobots.txtを確認した。このサイトでは配信側のCloudflareがrobots.txtへ情報を追加するため、リポジトリに書いた内容だけでは、実際の応答を判断できない。

そのうえで、検索エンジン側からどう見えているかをSearch Consoleで確認した。

TOPは、登録されていた#

最初に区別したかったのは、TOPが検索に登録されていないのか、それとも登録されているけれど今回の検索ではContactが目立っているのか、ということだった。

そこで、Google Search ConsoleでTOPのURLを確認した。

結果は、登録済み。Googleが正規のページとして選んでいるURLも、意図したTOPのURLだった。少なくとも「TOPがGoogleに存在を知られていない」という状態ではなかった。

最後にクロールされた日時は、確認した画面では9月13日になっていた。9月16〜17日に直した内容より前だ。

ただ、この日付だけでContactが上に出た理由が分かるわけではない。分かったのは、最近の変更が、その最終クロール時点のページにはまだ入っていないということだった。

Analyticsを入れたところで止まっていた#

このサイトには、Google Analyticsは入れてあった。SEOの話を始めたときには、Search Consoleも登録済みだと思っていたけれど、途中で「アナリティクスしか入れてないかも」と気づいた。

実際にSearch Consoleの設定を進め、既存のAnalyticsタグを使って所有権を確認した。サイトマップも送信し、正常に処理されたことを確認した。

そこでようやく、サイトを訪れた人の状況に加えて、検索側でページがどう扱われているかを確かめる準備ができた。

登録直後のレポートには、まだデータ処理中のものもあった。設定したその場で、検索流入の全体像が分かるわけではなかった。

タイトルにも、サイトの名前を入れた#

TOPのタイトルは、それまで「memi」だった。

サイト内で使っている名前はmemi。ドメインはmemida.dev。今回は、TOPのタイトルを「memi | memida.dev」に変えた。

「memida」と検索している人が、どのサイトなのかを見分ける材料になるように、タイトルにもドメインを入れた形だ。

変更を公開して、本番のページにも新しいタイトルが出ていることを確認した。そのあとSearch Consoleからインデックス登録をリクエストし、優先クロールのキューへ追加されたという表示まで確認した。

ここまでが、今回やったことだ。

変更したことと、検索結果が変わること#

サイトのタイトルは、自分で変更して公開できる。一方で、検索結果にいつ、どう表示されるかは、それとは別に確認しないといけない。

Googleの説明では、検索結果のタイトルはページ内のタイトルや見出しなど、複数の情報から自動生成される。こちらで書いたタイトルが、そのまま表示されるとは限らない。

また、再クロールを依頼する機能も、即時の反映や検索への掲載を保証するものではない。同じURLを繰り返し申請しても、処理が早まるわけではないと案内されている。

だから今は、「Contactが上に出る問題を直した」とまでは言えない。TOPの登録状況を確認し、タイトルを整え、更新を見てもらう依頼を出した。その結果は、これから確かめる。

自分のサイトを、外から見る#

サイトを作っていると、いつもTOPを開いて、そこから記事へ移動していた。

でも、検索から来る人が最初に見るページは、それとは限らない。今回は、自分の名前で検索するだけで、その違いに気づいた。

Contactは必要なページだ。ただ、作品や文章も置いているので、検索から来た人にも、そこへたどり着いてほしい。

まずは名前とページの説明を整えた。次に見るのは、検索結果にどう出るか、どのページが見られるか。

TOPを仕上げたあとにも、自分のサイトを見る場所はまだあった。

---

検索結果は、自分が「memida」で検索した際の表示について書いています。固定の順位や、すべての利用者に同じ結果が出ることを示すものではありません。