リンク先を変えたのに旧URLが残る場所｜構造化データ・canonical・OGPまで洗い出して揃える手順
リンク先を変えたのに旧URLが残る場所｜構造化データ・canonical・OGPまで洗い出して揃える手順
ページのボタンやメニューのリンク先を新しいURLに変えた。押せば新しいページに飛ぶ。それなのに、検索結果のリッチリザルトや、LINEやFacebookで共有したときのカードの行き先が旧URLのまま、という相談を受けることがあります。
原因はほぼ決まっています。URLは、目に見えるリンク以外の場所にも埋まっているからです。構造化データ（JSON-LD）、canonical、og:url、サイトマップ、転送設定。これらは画面に表示されないので、ブラウザで見て回っても気づけません。可視リンクだけを直すと、人間には正しく見えるのに、Googleや共有先のサービスには旧URLを申告し続けている状態になります。
結論から書きます。リンク先を変えるときは、次の順で進めます。
- 正しい行き先のURLを1つに確定する（正規URL）
- 旧URLの文字列でファイル全体を検索する。目視ではなく機械で洗い出す
- 見つかった箇所を、その箇所の意味を確認しながら全て新URLに揃える
- 旧URLの残存が0件か、新URLの件数が期待どおりか、構造化データが壊れていないかを検証する
- Search Consoleでインデックス登録をリクエストし直し、共有先のキャッシュを更新する
この記事では、弊社graciautoが首都圏の学習塾のWebパンフレットで、コース案内LPへの導線を可視リンク3か所と構造化データ5か所の計8か所同時に切り替えた実例をもとに、URLが埋まっている場所の一覧、洗い出しと検証の手順、切り替え後にGoogleと共有先へ反映させる方法をまとめます。
URLが埋まっている場所の一覧｜見える場所と見えない場所
まず、1ページの中でURLが書かれている場所を整理します。上の3つは画面に出ますが、下の5つは画面に出ません。
| 場所 | 画面に出るか | 旧URLが残ると何が起きるか |
|---|---|---|
| a要素のhref（ボタン・メニュー・本文リンク・フッター） | 出る | クリックすると旧ページへ飛ぶ |
| 画像やコースマップのリンク（area、図版のhref） | 出る | 図から押したときだけ旧ページへ飛ぶ |
| ページ内目次・パンくずのリンク | 出る | 目次から旧ページへ飛ぶ |
| 構造化データ（JSON-LD）のurl・mainEntityOfPage・significantLink・relatedLink・Offerのurl | 出ない | 検索結果のリッチリザルトや関連リンクが旧URLを案内する |
| canonical | 出ない | Googleが評価をまとめる先が旧URLのままになる |
| og:url・twitter系のメタ | 出ない | 共有カードの行き先が旧URLになる |
| サイトマップ（sitemap.xml） | 出ない | 旧URLをクロール対象として申告し続ける |
| 転送設定（.htaccessなど） | 出ない | 旧URLへの来訪者が新ページに届かない |
構造化データは1つのページに複数のURLを持てます。ページ自身のURL（mainEntityOfPage）のほかに、関連ページ（significantLink・relatedLink）、申込先（Offerのurl）、講座の案内ページ（Courseのurl）と、役割ごとに別々の項目があります。1つのリンク先を変えると、構造化データの中だけで4〜5か所を書き換えることになるのが普通です。
さらに、サイトの外にも同じURLが埋まっています。QRコード、LINEのリッチメニュー、Googleビジネスプロフィールのリンク、広告の最終ページURL、メール署名。サイト内を揃えたあとに、こちらも順番に確認します。サイト外のURLの確認は、QRコードについてはQRコードのリンク先を確認する方法に手順をまとめています。
実例｜可視リンク3か所と構造化データ5か所を同時に揃えた
弊社が制作・保守している首都圏の学習塾のWebパンフレット（1ページ完結・約23万バイト）を例にします。このページはコース案内LPへの導線を3か所持っていました。コース紹介のボタン、コース全体を図にしたコースマップ、フッターのコース一覧です。
同時に、構造化データの中にも同じコースのURLが5か所埋まっていました。significantLink、relatedLink、CourseのURL、OfferのURL、mainEntityOfPageです。合計8か所です。
行き先が3種類に割れる構造
この案件では、コース案内LPを新しく作り直し、新URLに置きました。ここで注意が必要なのは、新LPのURLが元のURLと違った点です。元のURLはクライアントが別の用途（提携先経由の計測）で使い続けていたため上書きできず、新LPは別のパスに置きました。元のURLを別用途で使い続けるケースは珍しくありません。
さらに、新LPの完成前には、暫定ページへ一時的にリンクを差し替えていた期間がありました。暫定ページは正規ページではないので、そのときは構造化データを暫定URLに書き換えず、元のURLのまま据え置く判断をしています。この判断自体は妥当です。暫定ページを正規ページとしてGoogleに申告する必要はないからです。
ただし、この経路を通ると、最終的な切り替え時点で次の状態になります。
| 場所 | 指しているURL |
|---|---|
| 可視リンク3か所 | 暫定ページ |
| 構造化データ5か所 | 元のURL（別用途で稼働中） |
| 正しい行き先 | 新LP |
可視リンクだけを新LPに直すと、構造化データは元のURLを指したままになります。画面上は正しい。しかしGoogleには「このページのコース案内は元のURLです」と申告し続けることになり、リッチリザルトや関連リンクは元のURLを案内します。片方だけ直すと、直したつもりで食い違いが残る。これが冒頭の相談の正体です。
実施した手順と検証結果
8か所を同時に新URLへ揃えました。手順は次のとおりです。
- ローカルにファイルを取得し、暫定ページのパスと元のパスの2種類の文字列で全体を検索して、8か所を特定
- 8か所すべてを新LPのパスに置換。構造化データは項目の意味（申込先、関連ページ、ページ自身）を確認しながら、機械的な置換で済むことを確かめてから実行
- 置換後に検証。旧2パスの残存0件、新パス8件、構造化データ5本すべてを構文解析して正常、リンク先の5URLすべてが200、本番に置いたファイルとローカルのハッシュ値が一致
- 実ブラウザで表示崩れ・404・JSエラーが0件であることを確認
- サーバー側のバックアップを取り、1ファイルだけを差し替え
検証の項目は多く見えますが、機械で回すので数分です。この確認を省くと、「置換で構造化データの引用符を壊した」「置換漏れが1か所残った」という事故が起こりえます。構造化データは壊れていてもページ表示には影響しないので、構文解析で確認しないと気づけません。
手順｜旧URLの文字列でファイル全体を検索する
ここからは、案件を問わず使える手順です。
1. 正しい行き先を1つに決める
切り替え作業の前に、正規URLを1つに確定します。ここが曖昧だと、可視リンクとcanonicalとog:urlで別々のURLを書く事故が起こります。特に、拡張子ありとなし（/page.html と /page）、末尾スラッシュありとなし（/page と /page/）は別のURLとして扱われるので、表記まで含めて決めます。URLの拡張子を消す運用についてはURLの.htmlを消す正しい.htaccess設定で扱っています。
制作前の資料（配信設計書、原稿、QRの発注書）に書かれたURLと、HTMLのcanonicalに書くURLが食い違うことも起こりえます。公開前に、資料側とHTML側のURLを並べて突き合わせておくと防げます。
2. 文字列で洗い出す
静的HTMLなら、旧URLのパス部分を検索語にしてファイル全体を検索します。
grep -n "/old-course/" index.html
grep -rn "old-course" ./ --include="*.html" --include="*.php" --include="*.js" --include="*.xml"検索語は、絶対URL（https://example.com/old-course/）ではなく、パス部分（/old-course/）にします。相対パスで書かれた箇所や、プロトコルなしで書かれた箇所を取りこぼさないためです。旧URLに表記ゆれ（拡張子あり、末尾スラッシュなし）がある場合は、その分だけ検索語を増やします。
WordPressなどのCMSでは、URLは本文だけでなく、カスタムフィールド、テーマの設定、ウィジェット、メニュー、SEOプラグインの設定に分散して保存されています。管理画面の検索は本文しか対象にしないことが多いので、データベースを直接検索するか、検索置換用のプラグインで全テーブルを対象に検索します。
3. 箇所ごとの意味を確認して置換する
見つかった箇所を、そのまま全部置換してよいかは、箇所の意味で判断します。
- 可視リンク・og:url・canonical・sitemap：新URLへ揃える
- 構造化データのmainEntityOfPage：そのページ自身のURL。他ページへのリンクを変えただけなら触らない
- 構造化データのOfferやCourseのurl：申込先・案内ページなら新URLへ
- 転送設定の中の旧URL：転送元として残す（消すと旧URLの来訪者が404になる）
「同じ文字列でも役割が違う」箇所があるので、一括置換の前に一覧を目で確認します。8か所程度なら数分です。
4. 検証する
置換後は、次の4点を確認します。
| 確認 | 方法 | 合格条件 |
|---|---|---|
| 旧URLの残存 | 旧パスで再検索 | 0件 |
| 新URLの件数 | 新パスで検索 | 置換前に数えた件数と一致 |
| 構造化データの構文 | JSON-LDを構文解析（リッチリザルトテストでも可） | 全て正常 |
| リンク先の疎通 | 新URLにHTTPリクエスト | 200 |
構造化データは、置換で引用符や括弧を1文字壊しただけで全体が無効になります。無効になってもページの表示は変わらないので、構文解析で確認する工程を必ず入れます。
5. Googleと共有先に再申告する
サイト側を揃えても、Googleや共有先が持っている古い情報はすぐには入れ替わりません。
- Search Consoleで「インデックス登録をリクエスト」を打ち直す。以前にリクエスト済みでも、Googleがリクエスト時点の版を保持したままになることがあります。構造化データを直した後にリクエストし直さないと、古い版の判定（エラーや旧URL）が残り続けるおそれがあります
- サイトマップを更新し、旧URLを外して新URLを載せる
- 旧URLから新URLへ301転送を設定する。転送の判断基準は使わなくなったページを消すときの正しい手順にまとめています
- 共有カードのキャッシュは、Facebookならシェアデバッガーで再取得できます。手動で再取得させる手段がないサービスもあり、その場合は時間経過を待ちます。共有画像が出ないときの確認順はSNSでシェアしても画像が出ないときの確認順で扱っています
反映には数日から数週間かかります。作業完了の報告時に、この前提を先に伝えておくと、「直したのに変わらない」という問い合わせを減らせます。
起こりうる食い違いと予防
リンク先の変更に限らず、見えない場所のURLが食い違う事故にはいくつかの型があります。
| 起こりうる状態 | 表面化のしかた | 予防 |
|---|---|---|
| 可視リンクは新URL、構造化データは旧URL | リッチリザルトや関連リンクが旧URLを案内する | 文字列検索で可視・不可視を同時に洗い出す |
| テンプレを流用した新ページのhead（title・canonical・OGP・構造化データ）が別ページの値のまま | 検索結果に別ページの説明文が出る | 新ページ作成時にheadを専用ファイルとしてセットで作り、公開前にcurlでtitleとcanonicalを確認する |
| 全ページ共通の処理がog:urlをトップ固定で出力 | どの記事を共有してもカードの行き先がトップになる | 記事ページではog:urlをそのページのURLに出し分ける |
| 拡張子なしURLに切り替えたのにcanonicalとog:urlが.html付きのまま | 評価が旧表記に分散する | URL形式の変更時は、可視リンク・canonical・og:url・構造化データ・相互リンクを同時に統一する |
| 資料に書いたURLとHTMLのcanonicalが違う | 配信からのリンクが切れる、または別ページに評価が集まる | 公開前に資料とHTMLのURLを並べて突合する |
2行目の型は、店舗ごとにサイトを量産する構成で起こりやすいものです。弊社が運用している名古屋の美容サロンFC（20店舗以上）の店舗サイトでは、店舗専用のhead情報が無い店舗にはテンプレの値が使われる仕組みになっていました。この構成では、新店舗のheadが既存店舗の値のまま公開されると、検索結果でその店舗のURLに別店舗の説明文が出る形で表面化します。新店舗を追加するときは、設定ファイルだけでなくhead用のファイルもセットで作る運用にすると防げます。
3行目の型は、健康食品ブランドのブログで見られました。全ページ共通の処理が固定のog:urlを出力していたため、記事ページの共有カードもトップページを指す状態でした。記事は記事のURL、一覧は一覧のURLと、ページの文脈ごとに出し分ける処理に改修しています。
いずれも画面を見ているだけでは気づけない点が共通しています。確認はcurlで実際に配信されているHTMLを取り、title・canonical・og:url・構造化データのurlを並べて読むのが確実です。
curl -s https://example.com/page/ | grep -o -E '<link rel="canonical"[^>]*>|<meta property="og:url"[^>]*>'よくある質問
Q. 暫定ページにリンクを差し替えるとき、構造化データも書き換えるべきですか
暫定ページが正規ページでないなら、構造化データは正規URLのまま据え置くのが妥当です。ただし、その状態を経由すると、最終切り替え時に可視リンクと構造化データで行き先が違う状態になります。最終切り替えのときに、必ず両方を洗い出して揃えてください。
Q. 検索結果の旧URLが消えるまでどのくらいかかりますか
サイト側を揃えてインデックス登録をリクエストしても、反映は数日から数週間です。旧URLを検索結果から消したい場合の手順は消したいURLが検索結果に残るときの手順にまとめています。転送や統合をせずに削除リクエストだけ出しても、消えないものがあります。
Q. ブラウザでは新しいページに飛ぶのに、なぜGoogleは旧URLを見ているのですか
Googleは、a要素だけでなく構造化データやcanonicalに書かれたURLも読みます。ブラウザの動作は可視リンクの結果で、Googleの判定は不可視の情報も含めた結果です。両方が一致していないと、片方だけ正しく見えます。
まとめ
- リンク先を変えたのに旧URLが残る原因は、構造化データ・canonical・og:url・サイトマップ・転送設定など、画面に出ない場所にURLが埋まっているため
- 1つのリンク先を変えると、構造化データの中だけで4〜5か所を書き換えることになる。可視リンクだけ直すと、Googleへの申告は旧URLのまま残る
- 洗い出しは目視ではなく、旧URLのパス文字列でファイル全体（CMSならデータベース全体）を検索する
- 置換後は、旧URL残存0件・新URL件数の一致・構造化データの構文・リンク先200の4点を確認する
- 揃えたあとにSearch Consoleでインデックス登録をリクエストし直す。以前のリクエストは古い版を保持している
- 反映には数日から数週間かかる。作業完了の報告時に先に伝える
リンク先の変更やURL形式の変更で、見えない場所まで含めて揃える作業をご希望の方は、お問い合わせからご相談ください。現在のHTMLとデータベースを検索して、URLが埋まっている箇所の一覧を出すところから対応します。