公開から1ヶ月以上経って、別の作業の合間に Search Console を眺めていたとき、ふと気付きました。
「あれ、この記事だけ表示が変わっていない」── ずっと「検出 – インデックス未登録」のままだったんです。
他の記事は、後から投稿したものでも数日でインデックスされていました。なのにこの一本だけ、なぜか登録されない。
対象は、私が開発している WordPress プラグイン「Rapls PDF Image Creator」（WordPress.org のプラグインページ）の解説記事でした。プラグインの作者として、自分なりに丁寧に書いたつもりだった記事が、Google に届いていない状態だった、ということです。
軽い気持ちで Search Console の「インデックス登録をリクエスト」を押してはみたものの、何度押しても状況は変わりません。「あ、これは押し続けるだけで動くやつじゃないな」と察したところから、本格的に原因を切り分けていくことにしました。
結論から書くと、最終的に効果があったのは URL を変えて 301 リダイレクトを設定する、という一手でした。ただこれは、最初から狙いに行く方法ではないと思っています。技術的な確認、リライト、内部リンクの見直しといった基本を全部潰したうえで、最後の選択肢として実行したものです。
この記事では、その過程と、私のケースで実際に何が効いたのかを、順番に書いていきます。
先に大事なことだけ
「検出 – インデックス未登録」が長期化したときに最初に試すべきは、noindex / robots.txt / canonical / サーバー応答 / 内部リンク / 内容の重複といった基本要素の確認です。これらを潰してもどうしても動かない場合に、URL 変更＋301 リダイレクトという選択肢が出てきます。私のケースではこの最終手段で動きましたが、最初から狙う方法ではありません。
検証時の環境：WordPress 6.9 / Cocoon 2.9.0 / Xserver スタンダードプラン / Google Search Console / Redirection プラグイン（2026年2月時点）
最初に試したのは、Search Console からのリクエストだった
Search Console を開いて、URL 検査ツールに対象の URL を入力すると、「インデックス登録をリクエスト」というボタンが出てきます。最初に押したくなるのはここですよね。
私もまずはここからでした。「Google にまだ見つけてもらえていないだけで、声をかければ動くかもしれない」と思っていたんです。
ところが何度押しても、Search Console の表示は変わりませんでした。
考えてみると、「検出 – インデックス未登録」は、Google が URL の存在を認識しているけれどクロールしていない（あるいはクロールしたが優先度が低くインデックスを保留した）状態を表します。リクエストを送ること自体が無駄とは言いませんが、押せば必ず数日でインデックスされる、という性質のものではないわけです。
連打しても変わらないなら、原因は別のところにある。そう判断して、技術的な要素を一つずつ確認していくことにしました。
noindex / canonical / robots.txt を全部の角度から見直した
ここで気を付けたのは、ひとつの方法だけに頼らないことです。
SEO プラグインの設定画面で「インデックスする」になっていても、テーマやキャッシュの影響で実際の HTML 出力がずれていることがあるんですよね。私自身、過去に「プラグイン側は OK なのに HTML には noindex が出ていた」という事故に遭ったことがあります。だから、最終的にブラウザに届いている HTML を自分の目で確認する、というのが私の確認ルーティンになっています。
具体的には、4つの方法を順番に使いました。
方法1：ブラウザの「ページのソースを表示」でメタタグを直接探す
対象記事を開いて、Ctrl + U（Mac は Option + Cmd + U）でソースを表示。<meta name="robots"> と <link rel="canonical"> を直接検索しました。
確認するのはシンプルで、robots に noindex が入っていないか、canonical が想定どおり自身の URL を指しているか、の2点だけです。
方法2：Search Console の URL 検査ツールで HTML レスポンスを見る
方法1と似ていますが、こちらは Google が実際に取得した HTML を見ることになります。Google 視点での canonical 判定や、レンダリング後の HTML が確認できるので、ブラウザでのソース表示との突き合わせができます。
もしブラウザのソースと Search Console の HTML レスポンスが食い違っていたら、その差分自体がヒントになります。
方法3：SEO プラグインの個別記事設定を確認する
SEO プラグインの設定画面で、対象記事だけ何か特殊な設定が入っていないかを確認しました。サイト全体ではインデックス許可になっていても、特定記事だけ「この投稿を noindex にする」がオンになっている、という事故は普通にあります。
方法4：robots.txt をブラウザで直接開く
最後に、https://raplsworks.com/robots.txt をブラウザで直接開いて、対象記事のパスをブロックする記述が無いことを確認しました。
SEO プラグインの管理画面ではなく、実際にブラウザで /robots.txt を開く、という所がポイントです。プラグインの設定が反映されていないこともありますし、サーバー側で別の robots.txt が動いていることもあるので、本当に Google に届いている内容を見たいなら、ブラウザで直接開くのが一番早い。
ここまでひと通り見ても、明らかな技術的ミスは見つかりませんでした。noindex は入っていない。canonical は自身を指している。robots.txt も問題なし。サーバーは 200 を返している。
言い換えると、技術的にはどこにも止める要素が無い。それなのにインデックスされない。これはこれで、ちょっと不気味な状態でした。
リライトしてみた──消去法で行き着いた仮説
技術的な要素に問題が無い以上、残るのは記事内容そのものです。
正直、最初は記事の内容が原因だとは思っていませんでした。プラグインの公式解説として、自分なりに丁寧に書いていたつもりだったからです。
ただ、ほかに疑える要素を全部潰していった結果、消去法的に「内容に何か引っかかる部分があるのかもしれない」というところに行き着きました。
とくに気になったのは、対象記事と WordPress.org のプラグインページの構成が、なんとなく似すぎている気がすることでした。WordPress.org のプラグインページには readme.txt の内容（機能説明、インストール手順、変更履歴など）が表示されるので、プラグイン作者がそれと別に自サイトで公式解説記事を書くと、扱う情報の流れがどうしても似てくる。
「なんとなく似すぎている気がする」という直感に近いものではありましたし、Search Console に「重複しています」のような明示的な表示が出ていたわけでもありません。だから断定はできない。それでも、ほかに動かせる手がかりが無い以上、この線で動いてみるしかないと判断しました。
そこで、記事を大幅に書き直しました。具体的には、プラグインを作った経緯、自分のサイトで困っていた事情、サーバー環境ごとの注意点、実際に使うときのおすすめ設定、トラブル時の確認ポイント、よくある質問、といった話を増やしました。要するに、WordPress.org の説明ページには絶対に書かれていない情報、「使う側」ではなく「作った側」しか書けない一次情報を増やしたつもりです。
ただ、リライト後も Search Console の状態はしばらく変わりませんでした。
このとき気付いたのは、Google がそもそもまだそのページをクロールしに来ていない段階では、何を書き直しても評価には反映されない、という当たり前の事実です。中身を直しても、Google が再訪してくれないと意味がない。それまでの自分は、リライトすれば Google が「見直してくれる」と暗に期待していたんですが、その前提が崩れていた、ということでもあります。
内部リンクと外部リンクも見直した
次にやったのは、対象記事への導線を増やすことでした。
新しい URL や見つけてもらいたい URL を Google に拾ってもらうには、内部リンクが効きやすい、というのが一般論です。すでにインデックスされている関連記事の本文中から、対象記事へのリンクを文脈的に自然な形で追加しました。
加えて、別ドメインで運営しているブログの関連記事からも、内部参照を貼りました。
それでも、しばらく状況は動きませんでした。
このあたりまで来ると、「単にリンクが少ないから見つかっていない」のでは無さそうだ、と感じはじめます。Google がそのページを取りに来ていない、もしくは、来ているけれど何らかの理由でインデックス候補にしていない。残されたシナリオはそのあたりに絞られてきました。
ここまでを整理して、URL を変えることにした
ここまでで試したことを並べると、こんな状況でした。
- サイト内の他の記事はインデックスされていた
- 対象記事だけ「検出 – インデックス未登録」が長く続いていた
- 技術的な noindex や robots.txt の問題は無かった
- 記事内容をリライトしても、すぐには変化しなかった
- 内部リンクを増やしても、すぐには変化しなかった
これだけ手を尽くして動かないなら、問題は「この URL 自体に対する Google の評価や優先度」のほうにあるんじゃないか。そう考えて、URL を変えて新しいページとして扱ってもらう方向に踏み切ることにしました。
URL を変えるのは、画面上は軽い作業に見えます。
ただ、SEO 上はかなり大きな変更です。SNS のシェア数がリセットされる、外部からの被リンクは旧 URL のまま残る、といった代償が必ず付いてきます。だから普段は試すべきではないし、最初に手を出す方法でもない。それを 1 ヶ月以上動かなかった現状と天秤にかけて、最後の手段として実行しました。
実際にやった4ステップ
実際の手順は、こんな流れです。
ステップ1：スラッグを変更する
WordPress の投稿編集画面から、対象記事のスラッグを変更しました。
| 項目 | URL |
|---|---|
| 変更前 | /wordpress-rapls-pdf-image-creator/ |
| 変更後 | /rapls-pdf-image-creator-guide/ |
新しいスラッグは「短く、内容が伝わる形」を意識しました。「wordpress」みたいな広すぎるキーワードを入れるより、プラグイン名と用途が伝わるスラッグの方が、URL を読んだ人にも検索エンジンにも親切だ、という判断です。
ステップ2：旧URLから新URLへ301リダイレクトを設定する
スラッグだけ変えると、旧 URL にアクセスした人は 404 ページに飛びます。SNS のシェアや外部からのリンクを残しておくためにも、旧 → 新の 301 リダイレクトは絶対にセットで必要です。
私は Redirection プラグインを使って設定しました。
301 を入れた理由
- 旧 URL から来た読者を新 URL へ案内するため
- 外部や SNS に残った旧 URL を生かすため
- 検索エンジンに「ページが恒久的に移動した」と伝えるため
ここを省略すると、読者にとっても検索エンジンにとっても不親切な状態になります。URL を変えるなら、301 リダイレクトはセット運用、と思っておくのが安全です。
ステップ3：内部リンクを新URLに置き換える
旧 URL を貼っていた他の記事の内部リンクを、新 URL に書き換えました。
301 で自動転送されるとはいえ、内部リンクは直接新 URL を指している方がきれいです。リンク先が増えるたびに 301 を経由するのは、サイト構造としても望ましくない。私は対象が数記事だったので、手作業で確認しながら直しました。記事数が多い場合は Search & Replace 系のプラグインで一括置換する方が早いと思います。
ステップ4：新URLでインデックス登録をリクエストする
最後に、Search Console から新しい URL を URL 検査ツールにかけて、インデックス登録をリクエストしました。
このときは、何度も連打せず、1 回だけ送って様子を見ることにしました。連打しても結果は変わらない、というのは最初の試行で学んでいたからです。
新 URL を作って、内部リンクを張り直して、サイトマップにも反映された。Google が見つけやすい状態を整えたうえで、最終的なリクエストを 1 度送る、という流れにしました。
URL変更から数日でインデックスされた
新 URL で登録リクエストを送って数日後、Search Console の表示が変わりました。
「URL は Google に登録されています」── ようやく、です。
正直に書いておくと、URL 変更が単独で効いた、と断定はできません。直前にリライトしていますし、内部リンクも増やしていますし、時間が経過したこと自体も要因かもしれません。これらが重なって、ようやくインデックスされた、というのが正確な書き方です。
ただ、1 ヶ月以上動かなかった状態が、URL 変更を起点に動き出したのは事実です。同じように長期間「検出 – インデックス未登録」で止まっている記事があるなら、最後の手段としての URL 変更は、覚えておく価値のあるカードだと思います。
URL を変える前に、まず確認したいこと
URL 変更は、最初に試す方法ではありません。
順番として安全なのは、まずこのあたりを確認しておくことです。
| 確認 | 項目 |
|---|---|
| □ | ページに noindex が入っていないか（HTML を直接確認） |
| □ | robots.txt でブロックしていないか（ブラウザで直接開いて確認） |
| □ | canonical が意図しない URL を指していないか |
| □ | サーバーが 200 を返しているか |
| □ | サイトマップに対象 URL が含まれているか |
| □ | インデックス済みの記事から自然な内部リンクがあるか |
| □ | WordPress.org や他の強いサイトと内容が重複しすぎていないか |
これらに問題が見つかった場合は、URL を変えるよりもその原因を直す方が先です。
とくに noindex や canonical は、SEO プラグインの管理画面では正しく見えていても実際の HTML 出力では狂っている、というケースがあります。Search Console の URL 検査ツールやブラウザのソース表示で、最終的な出力を必ず自分の目で確認してください。
URL 変更が向いているケースとそうでないケース
実体験から言うと、URL 変更を検討してもよさそうな状況はかなり限定的です。私の中では、こういう条件がそろっているときに限る、と整理しています。
- 特定の記事だけ「検出 – インデックス未登録」が長く続いている
- 同じサイトの他の記事はインデックスされている
- noindex / robots.txt / canonical / サーバー応答に問題が無い
- 記事内容を見直しても変化が無い
- 内部リンクを整えても変化が無い
- 旧 URL に強いこだわりが無い（被リンクや SNS シェアが少ない）
逆に、サイト全体がほとんどインデックスされていない場合は、URL 変更だけでは解決しないと思います。問題はサイト全体の品質や信頼性側にあるので、運営者情報、プライバシーポリシー、記事の質や数、カテゴリ整理、といった土台を整える方が先です。
URL 変更のデメリットも知っておく
URL 変更にはメリットだけでなく、それなりの代償もあります。実行を決めるなら、これらは最初に把握しておいた方がいいです。
SNS のシェア数がリセットされることがある
SNS の「いいね」やシェア数のカウントは、URL 単位で集計されることが多いです。URL を変えると、表示上のカウントがゼロからになります。
アクセス自体は 301 リダイレクトで新 URL に流れますが、見た目のシェア数までは引き継がれない、というのが一般的です。バズった記事ほどここの代償は大きくなります。
外部リンクは旧 URL のまま残る
他サイトから貼られた被リンクは、基本的に旧 URL のままです。301 を設定していれば訪問者は問題なく新 URL にたどり着けますし、検索エンジン側のリンクシグナルも引き継がれるはずですが、可能であればリンク元に修正をお願いした方がきれいです。
必ず成功するとは限らない
これが一番大事な話です。
私のケースではうまくいきましたが、すべてのサイトで同じ結果になるとは限りません。原因がサイト全体の品質や信頼性にある場合、URL を変えても結果は変わりません。WP.org との重複や低品質といった問題が残ったままなら、新 URL でも同じ評価になる可能性があります。
URL 変更は「特効薬」ではなく、「条件がそろっている時に試す価値がある選択肢の一つ」だと思ってください。
最後に
「検出 – インデックス未登録」が長く続くと、何を直せばいいのかが本当に分からなくなります。私自身、リクエスト連打、技術的確認、リライト、内部リンク強化── どれをやっても動かない時期があって、かなり悩みました。
最終的に、URL 変更と 301 リダイレクトを実行したところ、私のケースでは数日でインデックス登録まで進みました。ただ、これが万能策ではないことも、書いてきたとおりです。
順番として安全なのは、技術的な要素を全方位から確認して、内容と内部リンクを見直して、それでも動かないなら URL 変更を検討する、という流れだと思います。
同じように Search Console の「検出 – インデックス未登録」で止まっている方に、何かのヒントになれば幸いです。
関連記事
- Cocoon・画像・キャッシュを全部見直してもPageSpeedが伸びなかった話｜原因はSite Kit ── 同じく Search Console と Site Kit を使った計測周りの話。
コメント