1記事だけ「検出 – インデックス未登録」が1ヶ月以上続いた話｜URL変更と301リダイレクトで動いた

Search Console で「検出 – インデックス未登録」のまま1か月以上動かないページを、あなたは持っていますか。私は持っていました。

気づいたのは、別の作業の合間にレポートを眺めていたときです。この記事だけ表示が変わっていない。他の記事は、あとから投稿したものでも数日でインデックスされているのに、一本だけ登録されない。URL 検査ツールを開いて「インデックス登録をリクエスト」を押しました。数日待って、また押しました。表示は変わりません。三度目を押しながら、これは押し続けて動くやつではないな、と気づいたところが、この件でいちばん手が止まった瞬間でした。

対象は、私が開発している WordPress プラグイン Rapls PDF Image Creator（WordPress.org のプラグインページ）の解説記事でした。作者として自分なりに丁寧に書いたつもりの記事が、Google に届いていない。先に書いておくと、最終的に効いたのは URL を変えて 301 リダイレクトを設定する、という一手です。ただしこれは最初から狙う方法ではありません。技術的な確認、リライト、内部リンクの見直しを全部潰したうえで、最後に選んだ手でした。順番に見ていきます。

検証時の環境：WordPress 6.9 / Cocoon 2.9.0 / Xserver スタンダードプラン / Google Search Console / Redirection プラグイン（2026年2月時点）

リクエストを連打しても、何も変わらなかった

「検出 – インデックス未登録」は、Google が URL の存在を認識しているけれどクロールしていない、あるいはクロールしたものの優先度が低くてインデックスを保留した状態を表します。リクエストを送ること自体が無駄とは言いませんが、押せば必ず数日でインデックスされる、という性質のものではありません。連打しても変わらないなら、原因は別のところにある。そう判断して、技術的な要素を一つずつ確認していくことにしました。

余談ですが、ボタンを押している数日のあいだ、私は何かが動いている気になっていました。手を動かした感触があると、待っている時間が作業に見えてしまう。実際には、待っていただけです。

止める要素は、どこにもなかった

ここで気を付けたのは、ひとつの方法だけに頼らないことです。SEO プラグインの設定画面で「インデックスする」になっていても、テーマやキャッシュの影響で実際の HTML 出力がずれていることがあります。私自身、過去にプラグイン側は問題ないのに HTML には noindex が出ていた、という事故に遭ったことがあって、それ以来、最終的にブラウザへ届いている HTML を自分の目で確認するのが確認ルーティンになりました。4つの方法を順番に使っています。

ブラウザの「ページのソースを表示」でメタタグを直接探す

対象記事を開いて Ctrl + U（Mac は Option + Cmd + U）でソースを表示し、<meta name="robots"> と <link rel="canonical"> を検索します。見るのは2点だけです。robots に noindex が入っていないか、canonical が想定どおり自身の URL を指しているか。

Search Console の URL 検査ツールで HTML レスポンスを見る

こちらは Google が実際に取得した HTML を見ることになります。Google 視点での canonical 判定や、レンダリング後の HTML が確認できるので、ブラウザでのソース表示と突き合わせができます。もし両者が食い違っていたら、その差分自体がヒントになります。

SEO プラグインの個別記事設定を確認する

サイト全体ではインデックス許可になっていても、特定の記事だけ「この投稿を noindex にする」がオンになっている、という事故は普通に起きます。

robots.txt をブラウザで直接開く

管理画面ではなく、https://raplsworks.com/robots.txt をブラウザで開いて、対象記事のパスをブロックする記述がないことを確認します。プラグインの設定が反映されていないこともありますし、サーバー側で別の robots.txt が動いていることもある。本当に Google へ届いている内容を見たいなら、直接開くのが一番早い。

ここまで見ても、明らかな技術的ミスは見つかりませんでした。noindex は入っていない。canonical は自身を指している。robots.txt も問題なし。サーバーは 200 を返している。技術的にはどこにも止める要素がない、それなのにインデックスされない。これはこれで、少し不気味な状態でした。

内容が似すぎているのではないか

技術的な要素に問題がない以上、残るのは記事の内容そのものです。最初は内容が原因だとは思っていませんでした。プラグインの公式解説として、丁寧に書いたつもりだったからです。ただ、ほかに疑える要素を全部潰した結果、消去法で「内容に何か引っかかる部分があるのかもしれない」というところへ行き着きました。

気になったのは、対象記事と WordPress.org のプラグインページの構成が、どことなく似ていることでした。WordPress.org のプラグインページには readme.txt の内容、つまり機能説明、インストール手順、変更履歴などが表示されます。作者がそれとは別に自サイトで公式解説を書くと、扱う情報の流れがどうしても似てくる。似ている気がする、という直感に近いものではありましたし、Search Console に「重複しています」のような表示が出ていたわけでもありません。断定はできない。それでも、ほかに動かせる手がかりがない以上、この線で動いてみるしかないと判断しました。

そこで記事を書き直しました。プラグインを作った経緯、自分のサイトで困っていた事情、サーバー環境ごとの注意点、実際に使うときのおすすめ設定、トラブル時の確認箇所、よくある質問。WordPress.org の説明ページには絶対に書かれていない情報、使う側ではなく作った側しか書けない一次情報を増やしたつもりです。

それでも、しばらく状態は変わりませんでした。ここで気づいたのは、Google がそもそもまだそのページをクロールしに来ていない段階では、何を書き直しても評価には反映されない、という当たり前の事実です。中身を直しても、再訪してくれないと意味がない。それまでの私は、リライトすれば Google が見直してくれると暗に期待していました。その前提のほうが崩れていた、ということでもあります。

導線を増やしても動かなかった

次にやったのは、対象記事への導線を増やすことでした。新しい URL や見つけてもらいたい URL を拾ってもらうには内部リンクが効きやすい、というのが一般論です。すでにインデックスされている関連記事の本文中から、文脈的に自然な形でリンクを追加しました。別ドメインで運営しているブログの関連記事からも参照を貼りました。こちらは半分くらい、藁にもすがる気持ちです。

それでも、しばらく状況は動きません。このあたりまで来ると、単にリンクが少ないから見つかっていない、のではなさそうだと感じはじめます。Google がそのページを取りに来ていないか、来ているけれど何らかの理由でインデックス候補にしていないか。残るシナリオはそのあたりに絞られてきました。

では、URL そのものが嫌われているのか

ここまでで試したことを並べると、サイト内の他の記事はインデックスされていて、対象記事だけ「検出 – インデックス未登録」が長く続いていて、技術的な noindex や robots.txt の問題はなく、記事内容をリライトしても、内部リンクを増やしても、すぐには変化しなかった、という状況でした。

これだけ手を尽くして動かないなら、問題はこの URL 自体に対する Google の評価や優先度のほうにあるのではないか。そう考えて、URL を変えて新しいページとして扱ってもらう方向に踏み切ることにしました。URL を変えるのは、画面上は軽い作業に見えます。ただ SEO 上はかなり大きな変更で、SNS のシェア数がリセットされる、外部からの被リンクは旧 URL のまま残る、といった代償が必ず付いてきます。普段は試すべきではないし、最初に手を出す方法でもない。それを1か月以上動かなかった現状と天秤にかけて、最後の手段として実行しました。

実際にやった4ステップ

スラッグを変更する

投稿編集画面から、対象記事のスラッグを変えました。

新しいスラッグは、短く、内容が伝わる形を意識しました。wordpress のような広すぎるキーワードを入れるより、プラグイン名と用途が伝わるほうが、URL を読んだ人にも検索エンジンにも親切だという判断です。

旧 URL から新 URL へ 301 リダイレクトを設定する

スラッグだけ変えると、旧 URL にアクセスした人は 404 に飛びます。SNS のシェアや外部からのリンクを残すためにも、旧から新への 301 は絶対にセットで必要です。私は Redirection プラグインを使いました。

301 を入れる理由は3つあります。旧 URL から来た読者を新 URL へ案内するため。外部や SNS に残った旧 URL を生かすため。そして検索エンジンに、ページが恒久的に移動したと伝えるため。ここを省略すると、読者にとっても検索エンジンにとっても不親切な状態になります。URL を変えるなら 301 はセット運用、と思っておくのが安全です。

内部リンクを新 URL に置き換える

旧 URL を貼っていた他の記事のリンクを、新 URL に書き換えました。301 で自動転送されるとはいえ、内部リンクは直接新 URL を指しているほうがきれいです。私は対象が数記事だったので手作業で直しました。記事数が多い場合は Search & Replace 系のプラグインで一括置換するほうが早いと思います。

新 URL でインデックス登録をリクエストする

最後に、Search Console から新しい URL を URL 検査ツールにかけてリクエストしました。このときは連打せず、1回だけ送って様子を見ています。連打しても結果は変わらないというのは、最初の試行で学んでいました。新 URL を作って、内部リンクを張り直して、サイトマップにも反映された。見つけやすい状態を整えたうえで、最終的なリクエストを1度送る、という流れにしました。

数日でインデックスされた

リクエストを送って数日後、Search Console の表示が「URL は Google に登録されています」に変わりました。1か月以上動かなかったあとの、数日です。

ただし、URL 変更が単独で効いたと断定はできません。直前にリライトしていますし、内部リンクも増やしていますし、時間が経過したこと自体も要因かもしれない。これらが重なってようやくインデックスされた、というのが正確な書き方です。それでも、1か月以上動かなかった状態が URL 変更を起点に動き出したのは事実でした。

URL を変える前に確認したいこと

URL 変更は、最初に試す方法ではありません。順番として安全なのは、まずこのあたりを確認しておくことです。

これらに問題が見つかった場合は、URL を変えるよりその原因を直すほうが先です。とくに noindex や canonical は、SEO プラグインの管理画面では正しく見えていても実際の HTML 出力では狂っている、というケースがあります。URL 検査ツールやブラウザのソース表示で、最終的な出力を必ず自分の目で確認してください。

そのうえで、URL 変更を検討してよさそうな状況はかなり限定的だと思っています。特定の記事だけ長く止まっていて、同じサイトの他の記事はインデックスされていて、技術的な問題がなく、内容を見直しても内部リンクを整えても変化がなく、旧 URL に強いこだわりがない。この条件がそろっているときに限る、というのが私の整理です。逆に、サイト全体がほとんどインデックスされていない場合、URL 変更だけでは解決しません。問題はサイト全体の品質や信頼性の側にあるので、運営者情報、プライバシーポリシー、記事の質と数、カテゴリ整理といった土台を整えるほうが先です。

何を失うのか

SNS のシェア数がリセットされることがある

いいねやシェア数のカウントは URL 単位で集計されることが多いので、URL を変えると表示上のカウントがゼロからになります。アクセス自体は 301 で新 URL に流れますが、見た目のシェア数までは引き継がれないのが一般的です。バズった記事ほど、ここの代償は大きくなります。

外部リンクは旧 URL のまま残る

他サイトから貼られた被リンクは、基本的に旧 URL のままです。301 を設定していれば訪問者は問題なく新 URL にたどり着けますし、検索エンジン側のリンクシグナルも引き継がれるはずですが、可能ならリンク元に修正をお願いしたほうがきれいです。

必ず成功するとは限らない

これが一番大事な話です。私のケースではうまくいきましたが、すべてのサイトで同じ結果になるとは限りません。原因がサイト全体の品質や信頼性にあるなら、URL を変えても結果は変わらない。WordPress.org との重複や低品質といった問題が残ったままなら、新 URL でも同じ評価になる可能性があります。特効薬ではなく、条件がそろっているときに試す価値がある選択肢のひとつ、くらいに思っておいてください。

「検出 – インデックス未登録」が長く続くと、何を直せばいいのかが本当に分からなくなります。私もリクエスト連打、技術確認、リライト、内部リンク強化と、どれをやっても動かない時期があって、かなり悩みました。安全な順番は、技術的な要素を全方位から確認して、内容と内部リンクを見直して、それでも動かないなら URL 変更を検討する、という流れだと思います。もし今あなたの手元で1か月以上止まっているページがあるなら、まずリクエストのボタンから手を離して、HTML を1枚だけ自分の目で見てください。

関連記事

• Cocoon・画像・キャッシュを全部見直しても PageSpeed が伸びなかった話｜原因は Site Kit 。 同じく Search Console と Site Kit を使った計測まわりの話。
• Rapls PDF Image Creator 技術リファレンス 。 この記事で扱った、対象のプラグインです。