WordPressで新しいサイトを公開しても、すぐにGoogleやBingの検索結果へ表示されるとは限りません。
検索結果にページが掲載されるまでには、大きく分けて、
サイトを発見される
↓
クローラーがアクセスする
↓
ページ内容を取得する
↓
インデックス対象として評価される
↓
検索インデックスへ登録される
↓
検索結果に表示される
という段階があります。
したがって、単に「GoogleへURLを送る」だけでは不十分です。
重要なのは、
- 検索エンジンがサイトを発見できる
- クローラーが正常にアクセスできる
- インデックス禁止設定が存在しない
- 正規URLが明確になっている
- サイト内の各記事へリンクをたどれる
- 新規記事や更新情報を検索エンジンへ伝えられる
という状態を作ることです。
この記事では、WordPressサイトをGoogle・Bingなどへ適切に認識させるために、実施価値の高い対策を順番に整理します。
最初に理解しておきたい「クロール」と「インデックス」の違い
検索エンジンにURLを通知すれば、必ず検索結果に掲載されるわけではありません。
Googleも、サイトマップ送信やクロールリクエストはあくまで発見・再クロールのための手段であり、インデックス登録を保証するものではないと説明しています。
そのため、目標は、
「インデックスを強制する」
ことではなく、
「検索エンジンが問題なく発見・クロール・評価できる環境を作る」
ことです。
この考え方を前提にすると、必要な対策が整理しやすくなります。
WordPressの「検索エンジン非表示」を確認する
WordPressサイトを公開した直後に、最初に確認したい項目です。
WordPress管理画面から、
設定
↓
表示設定
↓
検索エンジンでの表示
を確認します。
「検索エンジンがサイトをインデックスしないようにする」にチェックが入っている場合は、公開サイトなら解除します。
現在のWordPressでは、この設定が有効になっていると、ページに検索エンジンへインデックスしないよう伝えるrobots設定が出力されます。
新サイトを開発中にこの設定をONにして、そのまま公開してしまうケースは特に注意が必要です。
noindexが混入していないか確認する
WordPress全体の設定だけでなく、個別記事やSEOプラグインの設定によってnoindexが付いている可能性もあります。
たとえばHTMLに、
<meta name="robots" content="noindex">
が存在すると、検索エンジンがこの指定を取得した場合、そのページはインデックス対象から外れます。
確認対象は、
- トップページ
- 固定ページ
- 投稿記事
- カテゴリページ
- タグページ
- SEOプラグインの設定
- HTTPレスポンスの
X-Robots-Tag
などです。
特にSEOプラグインを利用している場合、WordPress本体ではインデックス許可になっていても、プラグイン側でカテゴリや記事がnoindexになっていることがあります。
公開したいページについては、
WordPress本体
SEOプラグイン
HTML meta robots
HTTP X-Robots-Tag
の各層を確認すると安全です。
robots.txtでクローラーを妨げていないか確認する
robots.txtは検索エンジンのクローラーに対し、どのURLをクロールしてよいかを伝えるためのファイルです。
サイト全体を公開したいのに、
User-agent: *
Disallow: /
となっていれば、クロールを大きく妨げます。
一方で注意したいのは、robots.txtとnoindexは別物だという点です。
noindexを認識するためには、そのページ自体をクローラーが取得できる必要があります。
したがって、
クロール制御 → robots.txt
インデックス制御 → noindex
と役割を分けて考える必要があります。
Google Search Consoleへ登録する
Google検索でサイトを管理するなら、Google Search Consoleは重要な管理基盤になります。
新しいサイトでは、可能であればドメインプロパティとして登録すると管理しやすくなります。
ドメインプロパティでは、
example.com
www.example.com
sub.example.com
http
https
など、対象ドメイン配下のプロトコルやサブドメインをまとめて把握できます。
所有権確認にはDNSレコードを利用できます。
特に今後、
example.com
tools.example.com
docs.example.com
のようにサブドメインを増やす予定があるサイトでは、ドメインプロパティで管理するメリットが大きくなります。
XMLサイトマップをGoogleへ送信する
Search Consoleの登録後は、サイトマップを送信します。
WordPressにはサイトマップ生成機能があり、標準環境ではサイトマップインデックスが生成されます。
代表的なURLは、
https://example.com/wp-sitemap.xml
です。
サイトマップは検索エンジンへ、
「このサイトにはこのURLがあります」
と知らせるための発見経路になります。
Search Consoleでは「サイトマップ」から登録できます。
送信後は、
- 正常に取得されたか
- エラーが発生していないか
- URLが認識されているか
を確認します。
ただし、サイトマップへの掲載はインデックス保証ではありません。
robots.txtにもサイトマップを記載する
Search Consoleへの送信とは別に、robots.txtからサイトマップを知らせることもできます。
たとえば、
Sitemap: https://example.com/wp-sitemap.xml
のように記載します。
これにより、
Search Console
+
robots.txt
という複数の入口からサイトマップを知らせられます。
設定コストが小さいため、実施しておく価値があります。
重要ページはURL検査からインデックス登録をリクエストする
新しく公開したサイトの場合、重要なページについてはGoogle Search Consoleの「URL検査」を利用できます。
最初は、
- トップページ
- 各主要カテゴリ
- サイトの中核となる記事
- 新しく追加した重要記事
などを優先するとよいでしょう。
URL検査からGoogleへクロールをリクエストできます。
ただし、同じURLを何度も送信しても効果が高まるわけではありません。
記事公開
↓
一度リクエスト
↓
後日状態確認
程度で十分です。
内部リンクで孤立ページを作らない
検索エンジンはサイトマップだけでなく、ページ内のリンクをたどって新しいURLを発見します。
基本的には、
<a href="URL">
という通常のリンク構造を使います。
WordPressサイトでは、記事を公開したら少なくとも、
トップページ
↓
カテゴリページ
↓
記事
既存関連記事
↓
新記事
という経路を作っておくとよいでしょう。
記事だけ公開して、
どこからもリンクされていない
という状態を避けることが重要です。
カテゴリページをクロールのハブとして使う
WordPressではカテゴリページを単なる記事一覧として扱いがちですが、検索エンジンから見ると有効な内部リンクハブになります。
たとえば、
機械設計
├─ ボルト
├─ ベアリング
├─ 公差
└─ 強度計算
のように関連コンテンツを集約すれば、カテゴリから各記事を発見できます。
さらに各記事から関連カテゴリや関連記事へリンクすれば、
トップ
↕
カテゴリ
↕
記事
↔
関連記事
というネットワークになります。
新しい記事を追加しても既存ページから自然にリンクされる構造を作ることが、長期的には重要です。
canonicalを正しく設定する
WordPressでは同じコンテンツへ複数URLからアクセスできる状況が発生する場合があります。
検索エンジンには、
「このコンテンツの代表URLはどれか」
を分かりやすくしておく必要があります。
そのために利用されるのが、
<link rel="canonical" href="https://example.com/example-page/">
です。
内部リンクについても、できるだけcanonicalで指定しているURLへ統一します。
たとえば、
http://example.com/page
https://example.com/page
https://example.com/page/
などが混在している場合は、利用するURL形式を整理します。
SEOプラグインを利用しているWordPressでは自動設定されることも多いですが、実際のHTMLを一度確認しておくと安全です。
サイトマップには正規URLを掲載する
canonicalを整理したら、サイトマップも同じURLへ統一します。
理想的には、
内部リンク
canonical
サイトマップ
の3つが同じURLを指している状態です。
これにより検索エンジン側が、
「どのURLが正式なページなのか」
を判断しやすくなります。
HTTP・DNSエラーを放置しない
SEO以前の問題として重要なのが、検索エンジンのクローラーがサイトそのものへ到達できることです。
確認したい項目は、
DNS
↓
HTTPS
↓
HTTPステータス
↓
WordPress
↓
ページ表示
です。
特に新規ドメインでは、
- DNS設定
- ネームサーバー
- Aレコード
- AAAAレコード
- wwwの有無
- HTTPS証明書
- リダイレクト
などを一度確認しておく価値があります。
ブラウザからアクセスできるだけでなく、外部クローラーから安定してアクセスできることが重要です。
Bing Webmaster Toolsにも登録する
GoogleだけでなくBingにもサイトを登録しておくと、検索エンジンへの発見経路を増やせます。
Bing Webmaster Toolsでは、Google Search Consoleで確認済みのサイトをインポートする方法もあります。
そのため、
Google Search Console設定
↓
Bing Webmaster Toolsへ登録
という順序にすると管理しやすくなります。
Bing側でも、
- クロール状態
- インデックス状況
- サイトマップ
- 検索パフォーマンス
- SEO上の問題
などを確認できます。
IndexNowを利用する
Bingを中心とした検索エンジンへの更新通知にはIndexNowを利用できます。
IndexNowは、
新規公開
更新
削除
されたURLを検索エンジンへ通知するための仕組みです。
WordPressではIndexNow対応機能を持つSEOプラグインなどを利用できます。
運用イメージは、
WordPress記事公開
↓
IndexNow通知
↓
参加検索エンジンがURL変更を認識
↓
必要に応じてクロール
です。
サイトマップが「サイト全体の地図」だとすれば、IndexNowは「このURLが変更された」という通知に近い役割を持ちます。
RSS・Atomフィードも維持する
WordPressでは通常RSSフィードが生成されます。
RSSは最近更新されたURLを伝える仕組みとして利用できるため、WordPress標準フィードを不要に削除する必要はありません。
サイトマップとRSSは競合するものではなく、
XMLサイトマップ
→ サイト全体のURL
RSS
→ 最近更新されたURL
という異なる役割を持たせられます。
外部に管理しているページからサイトへ自然にリンクする
検索エンジンがサイトを発見する入口は、自サイトだけに限定されません。
たとえば自分が管理している、
- GitHubプロフィール
- GitHub README
- SNSプロフィール
- 公開プロフィールページ
- 関連プロジェクトページ
などから公式サイトへ自然にリンクしておけば、サイトの存在を認識する経路を増やせます。
目的は大量の被リンクを人工的に作ることではありません。
公式サイト
GitHub
SNS
公開ツール
など、自分が実際に運営している資産同士を正しく関連付ける程度で十分です。
構造化データを導入する
構造化データそのものがインデックスを保証するわけではありませんが、検索エンジンがページの意味を理解する補助になります。
WordPressサイトでは内容に応じて、
Article
BreadcrumbList
Organization
WebSite
などが候補になります。
SEOプラグインを利用している場合、すでにJSON-LD形式の構造化データが生成されている可能性があります。
ただし、
クロール可能
↓
インデックス可能
↓
正規URL明確
↓
本文内容が充実
という基礎を先に整えるべきです。
構造化データは基礎部分が正常になった後の強化策として考えるとよいでしょう。
Search Consoleでインデックスされない理由を確認する
インデックス対策では、設定したら終わりではありません。
Search Consoleを使って、
クロール済み
未登録
重複
canonical問題
noindex
リダイレクト
404
サーバーエラー
などの状態を確認します。
重要なのは、
「インデックスされていない」
という結果だけを見るのではなく、
「なぜインデックスされていないのか」
まで確認することです。
たとえばnoindexなら設定ミスの可能性があります。
一方、「クロール済み – インデックス未登録」であれば、単純なクロール障害とは限らず、コンテンツや重複性など別の要因も検討する必要があります。
新規WordPressサイトで実施する順番
実際の作業順をまとめると、次のようになります。
WordPressの検索エンジン非表示をOFF
↓
noindexを確認
↓
robots.txtを確認
↓
DNS・HTTPS・HTTP状態を確認
↓
Google Search Console登録
↓
XMLサイトマップ送信
↓
robots.txtにSitemapを記載
↓
トップ・カテゴリ・重要記事をURL検査
↓
canonicalを確認
↓
内部リンクを整備
↓
Bing Webmaster Tools登録
↓
IndexNow導入
↓
RSSを維持
↓
外部の公式プロフィール等からリンク
↓
Search Consoleで継続監視
特に新規サイトなら、前半部分を早めに済ませておくとよいでしょう。
WordPress公開時のチェックリスト
サイト基盤について一度確認する項目は、
- WordPressの検索エンジン非表示がOFF
- robots.txtがクロールを妨げていない
- XMLサイトマップが正常
- Search Console登録済み
- Bing Webmaster Tools登録済み
- canonicalが正常
- IndexNowが動作
- HTTPSが正常
- DNSが安定
です。
記事公開時には、
- 公開状態になっている
- noindexではない
- sitemapへ含まれている
- カテゴリへ所属している
- 他のページから内部リンクされている
- slugが適切
- 必要ならURL検査を実施
程度を確認すれば運用できます。
インデックス対策は自動化できる
WordPressでは、多くの作業を自動化できます。
たとえば、
記事公開
↓
WordPress sitemap更新
↓
RSS更新
↓
IndexNow通知
↓
内部カテゴリ一覧更新
までを自動で動かすことができます。
人間が毎回行う作業は、
Search Consoleで異常を確認する
↓
問題が発生した場合だけ修正する
という運用へ近づけられます。
記事数が増えるほど、毎回URLを手作業で登録する方式より、自動的に発見される構造を作ることの方が重要になります。
まとめ
WordPressサイトを検索結果へ表示させるために重要なのは、一つの裏技ではありません。
必要なのは、
クロールを許可する
+
サイトマップでURLを知らせる
+
Search Consoleで状態を監視する
+
内部リンクでページを接続する
+
canonicalを統一する
+
DNS・HTTPを安定させる
+
BingやIndexNowにも通知する
という複数の経路を整備することです。
特に重要なのは、
- WordPressのインデックス禁止設定確認
- Google Search Console登録
- XMLサイトマップ送信
- noindex・robots.txt確認
- 内部リンク整備
- canonical整理
- Bing Webmaster Tools登録
- IndexNow導入
- DNS・HTTPの安定性確認
- Search Consoleによる継続監視
です。
一度この基盤を整えてしまえば、新しく記事を公開するたびに検索エンジンへ手作業で知らせ続ける必要性は小さくなります。
最終的に目指すべき状態は、
記事を公開する
↓
自動的にサイトマップ・RSS・IndexNowへ反映
↓
内部リンクからも発見可能
↓
検索エンジンがクロール
↓
Search Consoleで状態を観測
という仕組みです。
検索インデックス対策は、個々の記事に施す「SEOテクニック」というより、サイト全体の情報流通経路を設計する作業として考えると、長期運用しやすくなります。
参考情報
- Google Search Central「URLの再クロールをGoogleにリクエストする」
- Google Search Central「サイトマップの作成と送信」
- Google Search Central「リンクに関するベストプラクティス」
- Google Search Central「noindexを使用してコンテンツをインデックスから除外する」
- Google Search Central「canonicalの指定」
- Google Search Console「サイトの所有権を確認する」
- WordPress.org「Settings Reading screen」
- Bing Webmaster Tools「IndexNow」
- Bing Webmaster Tools「Add and Verify site」
