自社サイトを直して得たSEOの教訓

数日かけて、検索エンジンと同じ目線で自社サイトを読み直し、直すべき点を6つ見つけました。すべてのページが2つのFAQブロックを宣言していました。Googleは、装飾的な背景のグローをサムネイルとして使っていました。一部のテンプレートページは、答えていない検索語句で順位がついていました。サイトの新しいセクションは、ステージング環境で自社のエッジにブロックされていました。どれも劇的な問題ではありません。しかし、どれも静かに露出を損なっていました。

サイトを一段落で説明すると

mythex.aiは、ビルド時にプリレンダリングしているシングルページアプリです。スクリプトがすべてのルートをたどり、各ルートの静的なHTMLファイルを書き出します。そして、ページのタイトル、説明、構造化データを埋め込みます。構造化データとは、ページが何であるかを検索エンジンに伝えるJSON-LDブロックのことです（構造化データとは何かを参照）。以下の内容の多くは、このプリレンダリングの工程に関係しています。クローラーが実際に読むHTMLを生成するのが、この工程だからです。

1. すべてのページが自分をFAQページだと主張していた

現象。 HTMLのテンプレートには、サイト全体に適用されるFAQPageブロックが構造化データとして含まれ、そのURLは/faqを指していました。そこへプリレンダリングが、各ページ固有のFAQPageを追加していました。その結果、サイトのすべてのページに2つずつ含まれ、プライバシーポリシーがGoogleに対して自分はFAQページだと伝えていたのです。

なぜ問題か。 Googleは、1ページにつきFAQPageが最大1つであることを期待しています。別の場所を指す2つ目のものがあると、単に無視されるだけでなく、ページのマークアップの評価が下がるおそれがあります。

修正。 サイト全体のブロックを削除しました。各ページのFAQマークアップは、1か所から生成されるようになりました。/faq自体も含め、全質問のリストからマークアップを組み立てます。FAQがないページは、何も宣言しないようになりました。これが正直な答えだからです。さらに、ビルドで1ページにFAQPageが2つ以上含まれていれば失敗させるようにしました。誰かの記憶にしかないルールは破られますが、ビルドで強制されるルールは破られません。

2. Googleが誤った画像を使っていた

現象。 検索結果で、Mythexのサムネイルとして表示されていたのは、トップページのヒーローの背後でふわっと光るグロー、つまり装飾用の背景画像でした。共有用のカード画像ではありませんでした。

なぜ起きたか。 各ページをどの画像で表すべきか、Googleに伝えていませんでした。そのため、見つけた画像を勝手に選ばれていたのです。

修正。 同じ問題の二つの側面に対応しました。

• そのページの画像を明示します。 トップページには、共有用カードをprimaryImageOfPageで指すWebPageノードを追加しました。プリレンダリングされたすべてのページの構造化データには、そのページ固有の画像（ページの共有画像、または既定の画像）を記載するようにしました。
• 装飾を隠します。 背景画像はrobots.txtで許可しないようにし、noindex, noimageindexヘッダーを付けて配信するようにしました。これで画像検索やサムネイルに出にくくなります。

3. 検索エンジンが知っていたのはロゴだけだった

Organizationのマークアップには、名前、ロゴ、いくつかのSNSリンクしか含まれていませんでした。ブランド情報だけで、それ以外の事実はなかったのです。検索エンジンは企業のナレッジパネルを、登記情報のような事実をもとに組み立てます。そこで、商業登記の情報から正式名称、設立日、創業者、登記上の住所を追加しました。電話番号は意図的に含めませんでした。

4. テンプレートページが違う質問に答えていた

現象。 Search Consoleでは、3つのテンプレートページが表示回数を集めているのに、クリックがゼロでした。1つは「content strategist portfolio」とその派生語で、1つは「best italian restaurant website design」で、1つは「agile board」周辺の一群で順位がついていました。そのうち半分ほどの検索語句には「free」が含まれていました。順位は20位台半ばから50位台でした。

理由。 各ページは、実際に聞かれている質問とは別の質問に答えていたのです。イタリアンレストランのサイトのよいデザインを知りたい人が、ビルダーを売り込むページに着いてしまっていました。

修正。 3ページとも、製品向けではなく検索向けに書いたセクションを加えました。タイトルと説明文は、人々が実際に入力する言葉にしました。すでに出力していたマークアップに見合うFAQも加えました。

同じコミットで、目立たない問題も直しました。「関連テンプレート」のブロックは、カテゴリ内の最初の4つのテンプレートを表示していたため、ポートフォリオのテンプレートはすべて同じ4つのポートフォリオにリンクしていました。そのカテゴリの残りのテンプレートには、内部リンクがまったくありませんでした。そこで、サブカテゴリ順のリングに置き換えました。これにより、すべてのテンプレートページが内向きに4つ、外向きに4つのリンクを持つようになりました。さらに、プリレンダリングされたHTMLにもそれらのリンクを出力するようにしました。以前は、JavaScriptが実行された後にしか存在しなかったため、クローラーがまったく見ない可能性がありました。

5. 新しいページを公開直後にBingへ知らせる

Googleは、URLが変わったときに検索エンジンへ通知するプロトコルであるIndexNowを無視します。IndexNowを使うのはBing、Yandex、Seznamです。そして、ChatGPTの検索が参照しているのはBingのインデックスです。AIアプリビルダーが、AIアシスタントから見つけられないというのは、特に深刻な問題です。

素朴な方法は、デプロイのたびにサイトマップ全体を送信することですが、それではキーがスロットリングされてしまいます。しかも、ほとんどのデプロイは、検索エンジンが気にするような内容を何も変えません。そこで、配信中のサイトマップと、今回ビルドされたサイトマップを比較し、差分だけを送信するスクリプトを作りました。

これを機能させた要点は2つです。

• デプロイの前にスナップショットを取ります。 ベースラインは、新しいビルドが公開される前に取得しておく必要があります。公開後には、「現在の」サイトマップがすでに新しいものになっており、差分はすべて空になってしまいます。
• 当面は新規ページだけを対象にします。 私たちのサイトマップにはlastmodの日付がありません。そのためスクリプトは、新しいページは知らせますが、書き換えられたページは知らせません。すべてのURLにビルド日を付けると、デプロイのたびにサイト全体が変更されたことになってしまいます。それは、まさに避けたかったスパムです。

このスクリプトは本番デプロイのときだけ実行され、ビルドを失敗させることはありません。実行される時点では、サイトはすでに公開されています。検索エンジンへの通知が、赤いデプロイに値するわけではないからです。

6. 自社のエッジが「見つからない」と返していた

/aiのページを公開したとき（その詳細はあらゆる種類のビジネスのためのランディングページで紹介しています）、ステージング環境では、静的ホストは正しく配信しているのに、そのすべてのページが「Not found」と表示されていました。

マーケティング用ホストの前段にあるサービスは、許可リストに登録されたパスだけを転送し、それ以外には即座に404を返します。/aiは新しく、その許可リストに含まれていませんでした。そこで/aiと/ai/*を追加し、それらが通ることを確認するテストも加えました。小さなバグですが、まさにこうした問題によって、新しいセクションが誰にも気づかれないままクローラーから見えなくなるのです。

得られた教訓

• クローラーが読むHTMLを確認してください。 これらの問題のほとんどは、ブラウザでは見えず、プリレンダリングされたファイルを見ればすぐにわかるものでした。
• SEOのルールはビルドのチェックにしてください。 「1ページにFAQPageは1つ」というルールは、今では覚えておくのではなく強制されています。
• 検索エンジンに意図を明確に伝えてください。 どの画像、どの事実があなたを表すのかを伝えなければ、検索エンジンは推測します。
• Search Consoleは、人々がどんな質問をしたかを教えてくれます。 表示回数はあるのにクリックがない場合、多くはページが別の質問に答えていたことを意味します。
• すべてを送るのではなく、差分を送ってください。 変更された分だけを通知すれば、レート制限の範囲内に収まります。

自分で作ったウェブサイトで同じことをしたい場合は、AIで作ったウェブサイトのSEOとGoogle Search Consoleの設定のガイドで基本を解説しています。