ウェブサイト公開前に見落としやすいSEO設定とは？

公開当日にトップページが検索で見つからない、商品ページが除外されているといった場合、原因はコンテンツ不足ではなく、公開・移行・多言語設定の際にいくつかの基本的なSEO設定が漏れていることが少なくありません。まず検索エンジンが正しいページにアクセスできるかを確認し、その後に速度、言語バージョン、コンバージョン導線を処理します。この順序を逆にすると、その後の最適化が誤ったURLやインデックス範囲を前提に進んでしまう可能性があります。

「サイトは公開済みだが、検索エンジンが正常にクロールできない」状態を先に除外する

最もよくある問題は、テスト環境のインデックス禁止設定が残っていることです。サイト制作段階では、テストページが検索結果に入るのを防ぐため、ページレベルのメタタグにnoindexを追加したり、robots.txtでディレクトリをブロックしたりすることがよくあります。正式ドメインへの切り替え後、トップページは公開されていても、商品詳細、記事、絞り込みページが依然としてルールによりブロックされている場合があります。トップページのソースコードだけを確認するのではなく、異なるテンプレートのページ、特に言語ページ、カテゴリーページ、サイト内検索結果ページ、フォームのランディングページを抽出して確認する必要があります。

robots.txtとnoindexの役割も混同されがちです。前者はクローラーのクロール経路を制限し、後者はアクセス済みのページをインデックスに登録しないよう指示します。noindexが設定された古いページをrobotsルールで完全にブロックすると、検索エンジンはnoindex指示を再読み込みできない場合があり、古いURLの処理により長い時間がかかります。明確に残すべきでないテストURLについては、必要なクロールを先に許可してnoindexを残すか、適切なステータスコードを直接返したうえで、実情に応じてアクセスルールを厳格化します。

サイトマップも「一度生成すればよい」ものではありません。送信するXML Sitemapには、インデックス登録を希望し、200を返す正規ページだけを記載する必要があります。リダイレクト先URL、404ページ、パラメータ付きの絞り込みリンク、noindexページを混在させると、クロールシグナルが混乱します。特にサイト構築システムが自動でsitemapを生成する場合は、ページネーション、タグページ、多言語URLが重複して記載されていないか確認してください。

正規URLを設定し、同一コンテンツの評価分散を防ぐ

1つのページにwwwあり・なし、http・https、末尾スラッシュ、パスの大文字・小文字、トラッキングパラメータなど、複数のURLでアクセスできる場合は、公開するバージョンを1つに確定しなければなりません。サーバー側の301リダイレクト、ページ内のcanonicalタグ、サイトマップURLは、すべて同一のURLを指すべきです。canonicalだけを記述してhttpページを処理していない場合や、トップページだけを転送して下層ページを見落とした場合も、重複した入口が残ります。

canonicalを機械的にすべてトップページへ向けてはいけません。商品ページ、サービスページ、記事ページにはそれぞれ独自の価値があり、誤ってトップページに統合すると、これらのページが検索対象になりにくくなります。広告パラメータ、並べ替えパラメータ、セッションパラメータを含むページこそ、パラメータなしのメインURLへ統合するのに適しています。絞り込み結果が実際に独立し、安定していて検索価値のあるページを生成する場合は、独自のタイトル、本文コンテンツ、正規URLが必要であり、多数の類似した絞り込みページをすべて公開するべきではありません。

旧サイトを移行する際、リダイレクトの対応付けはページの意図に基づいて行う必要があります。旧商品ページは対応する新商品ページへ、旧記事は内容が近い新記事へ優先的に転送します。すべての旧URLを一律でトップページにリダイレクトすると、404は回避できるように見えても、訪問者と検索エンジンの双方が元の文脈を失います。公開前には、高トラフィックページ、外部リンクが多いページ、主要ディレクトリを抽出して1件ずつテストし、「旧ページ→中間ページ→新ページ」という複数回のリダイレクトが発生していないことを確認できます。

タイトル、説明文、ページ本文がそれぞれ別のことを述べないようにする

タイトルタグの重複は、テンプレートを一括公開する際に最も見落とされやすい問題です。ページタイトルでは、まずそのページがどのような課題を解決するかを示し、その後に具体的なカテゴリー、地域、利用条件を補足するべきです。すべてのページに同じブランド語やカテゴリー名だけを残してはいけません。説明タグはランキングを直接決定するものではありませんが、検索結果における理解やクリック判断に影響するため、実際のファーストビューの内容と一致させ、ページ内に存在しない情報を約束しないようにします。

重要な各ページには明確なH1を設け、本文、画像の代替テキスト、内部リンクのアンカーテキストを同一テーマに沿って展開する必要があります。H1はtitleと完全に同じである必要はありませんが、一方が「工業部品」と書かれているのに、もう一方では主に「業界レポート」を表示するような状態ではいけません。たとえばリソースページで国際貿易企業のリスク管理と予防に関する研究を引用する際は、リンク付近でページテーマとの関係を説明し、無関係なキーワードをナビゲーション、フッター、非表示エリアに詰め込んではいけません。

速度の問題はリソースとページタイプまで特定する

「画像を圧縮済み」であっても、パフォーマンスに問題がないとは限りません。ファーストビューの大きな画像に実際の表示サイズを大幅に上回る元画像を使用すると、モバイル回線では主要コンテンツの表示が遅れます。カルーセル内の複数画像は、ユーザーがスライドしていなくても事前にダウンロードされる可能性があります。ファーストビューには実際に情報を伝える役割を担う画像を残し、ファーストビュー以外の画像には遅延読み込みを有効にし、画像の幅と高さを明確に指定して、読み込み時のページレイアウトのずれを減らします。

スクリプトもよくある盲点です。オンラインチャット、アクセス解析コード、地図、動画プレーヤー、ポップアップ、広告トラッキングは、それぞれ異なる部門から導入されることが多く、個別には大きくなくても、重なると操作を妨げます。公開前には、社内ネットワークだけで確認するのではなく、モバイル回線のシミュレーション環境でトップページ、商品ページ、フォームページをテストする必要があります。ファーストビューのコンテンツがいつ表示されるか、ボタンを適時にクリックできるか、フォーム送信後に異常な待機がないかを重点的に確認します。ファーストビューの機能に影響しないスクリプトは遅延実行に変更でき、重複した計測タグについては唯一のソースを残すべきです。

多言語サイトは言語シグナルで手戻りが発生しやすい

異なる言語バージョンでは、ナビゲーションやボタンだけを置き換えるのではなく、本文、タイトル、説明文、通貨または単位の表現も対象言語のページに合わせる必要があります。複数の言語URLが実際には同じ言語コンテンツを返している場合、検索エンジンは各バージョンが誰を対象としているのかを判断しにくくなります。各言語ページはhreflangで相互に宣言し、自身への参照も含める必要があります。言語コード、地域コード、canonical URL、sitemap内のURLは一致していなければなりません。

hreflangは自動リダイレクトを意味するものではありません。IPに基づいて訪問者を特定の言語ページへ強制的に送ると、クローラーや別の地域の訪問者が他のバージョンを閲覧できなくなる可能性があり、共有済みリンクを直接開くことも妨げられます。より安全な方法は、表示可能な言語切替入口を提供し、ユーザーの選択を保持し、切替後に一律でトップページへ戻すのではなく、対応するコンテンツページに到達できるようにすることです。

公開前にコンバージョンページの技術的な細部を見落とさない

SEOによってアクセスが増えても、ページが利用可能であるとは限りません。問い合わせフォームが、CAPTCHA、必須項目の検証、メール通知、送信インターフェースの設定エラーによって届かない場合、トラフィックの価値は最後の段階で失われます。実際のフローを使って、デスクトップとモバイルをそれぞれテストする必要があります。入力、送信、成功メッセージ、通知の受信、流入元記録が完全かどうかを確認します。サンクスページに独立したURLがある場合は、誤ってインデックス対象のコンテンツページと見なされないようにします。

最後に、構造化データがページ上で表示される内容と一致しているか確認します。商品価格、在庫、レビュー、組織情報などの項目がページ上に表示されていない場合や、古いテンプレートに由来する場合は、リッチリザルトのためだけに残すべきではありません。公開後のインデックス変動が常にコンテンツの問題とは限りません。クロール可能性、正規URL、レスポンスステータス、言語間の対応関係から順に特定するほうが、直ちに大量のページを書き換えるよりも効果的であることが多いです。