SEO・URL・ドメイン更新日
#Studioの動的ページのパスを移管先で再現するには？
移管先でも /posts/記事名 の形をそのまま作れるのでしょうか。Studioの動的ページのURLは、/posts のような固定のパスと、:slug のような差し込み部分でできています。:slug には各CMSアイテムのスラッグが入るため、移管先で同じ固定パスを用意し、旧スラッグを1件ずつ渡せば同じURLになりますね。
この形なら、Studioのときと同じ /posts/旧スラッグ のページが作られます。
ただ、パスとスラッグがそろっていても、ドメインが変わればURLとしては別物です。旧URLを残したいなら、使っていた独自ドメインも移管先へつなぎ直します。
あわせて、サイトマップに全記事のURLが必ず網羅されるとは限らないため、CMSの管理画面やアクセス解析のログと照らし合わせながら、新旧のURL対応表をあらかじめ作成しておきます。
#Studio CMSのスラッグがランダムな文字列のままの場合、移管時にどうすればいいですか？
たとえば記事のURLが /posts/k3x9ab のように、意味のない英数字になっているケースです。Studio CMSのスラッグはアイテムを作ったときに自動で付き、あとから好きな文字列に書き換えられます。作成後に触らずにいると、自動で付いた文字列がそのままURLとして公開されますね。
移管のときの選び方は2つあります。1つ目は、ランダムな文字列をそのまま移管先へ引き継ぐ方法です。見た目としては無機質なURLになりますが、過去に獲得した被リンクや検索エンジンの評価をそのまま保てます。まずはURLを変更せずに移管を完了させ、配信環境が落ち着いてからURLの整理を検討する進め方は理にかなっています。
2つ目は、移管をきっかけとして内容に沿った英単語のスラッグへ付け直す方法です。新しいスラッグは同じモデル内で重複できず、半角英数字・ハイフン・アンダーバーで付けるよう推奨されています。意味の通る単語へ改名すれば訪問者にとっても分かりやすいURLになりますが、アドレスが変わるため転送処理が欠かせません。旧URLへ訪れたユーザーや検索エンジンのクローラーを新しいアドレスへ逃がすため、301などの恒久的リダイレクトを設定して新URLへ誘導します。
なお、Studio上で先に変える場合は、変更前のURLが開けなくなる点に気をつけてください（StudioのSlug変更の手順）。CMSダッシュボードで対象のモデルを開き、Slugのセルをダブルクリックすれば編集できます。公開中の記事は、編集後にもう一度「公開中」へ戻して表示を確認します。外部リンクや訪問者のブックマークが途切れてしまうため、移管先で転送ルールを制御できる準備を整えたうえで切り替えるのが安全です。
#Studioのサイトから旧URLや画像URLの一覧を取得するには？
旧URLの一覧は、どこから取るのが早いでしょうか。ページについては、Studioのサイトマップがいちばん手軽です。パスはどのサイトも /sitemap.xml で、ダッシュボードの設定から［一般］を開き、サイトマップファイルをオンにします（Studioのサイトマップ設定）。非公開のサイトでは、公開したときにURLが有効になります。静的ページもCMSの動的ページも載りますが、モーダルと noindex のページは入りません。サイトマップだけに頼ると一部のページが抜け落ちる恐れがあるため、アクセス解析ツールやGoogle Search Consoleの登録データも併用して、過去にアクセスのあったページを網羅的にリストアップしましょう。
次に、記事内に挿入された画像のURLを収集する場面では、外部のクローラーツールを使うと効率よく作業を進められます。Screaming Frog SEO Spiderでサイトを巡回するとImagesタブに見つかった画像が並び、Bulk Export > Images > All Images から、どのページに載っていた画像かも含めて書き出せます。無料版で巡回できるのは500 URLまでです（Screaming Frogの画像の調べ方）。もしJavaScriptの動作によって後から画面へ読み込まれる画像が含まれている場合は、クローラーの設定をJavaScriptレンダリングに切り替えて走らせる配慮も必要です。
また、画像やURLの控えを取得するタイミングにも注意が要ります。有料プランからFreeプランへ切り替えると、次回更新日にサイトが一度非公開になります（Studioのプラン変更の仕様）。必要なデータや素材の控えは、契約の更新日を迎える前にすべて取得しておきましょう。
#移管で大量に出た404をURL対応の漏れとして修正するには？
移管直後に意図しない404エラーが大量発生してしまうトラブルと、読まれなくなった不要記事を整理して計画的にページを削除したケースとでは、取るべき対処の方向性が大きく分かれます。役目を終えて代替となるコンテンツも存在しない古いページであれば、404を返して検索エンジンのインデックスから自然に消去されるのを待つ形で構いません。しかし、移行先にも同じ内容の記事を引き継いでいるにもかかわらずNotFoundエラーが頻発しているなら、URLの対応付けが漏れている可能性が高いといえます。手を入れるのは、移動しただけのページが転送されていないケースで、こちらは301で新しいURLへ送ります。
最初に、404になっているURLを集めます。Search Consoleのページのインデックス登録レポートで未登録の理由の行をクリックすると、その問題が出ているURLを確認できます（ページのインデックス登録レポート）。
集めたURLは、移管前に作った対応表と照らします。StudioのCMSページは「動的ページのパス＋スラッグ」なので、blog/:slug でスラッグが about なら公開URLは blog/about です。同じパスの下で404がまとまって出ているなら、転送の設定漏れや、リンクの入力間違いを疑います。1件ずつばらばらに出ているなら、そのURLのスラッグの写し方を見直します。
このとき、大量のエラーを手っ取り早く解消しようとして、異なる内容の古いURLをすべて新サイトのトップページへ一括転送するような対応は避けてください。行き先に困ってトップページへ一括で送ると、soft 404として扱われる場合があります。転送先は、対応する新しいページか、内容をまとめたページにしましょう。
さらに、移管前に新サイトへ noindex を入れていたなら、そのルールも外します。こちらは404とは別に、検索結果に出てこない原因。
修正を終えたら、問題の詳細ページで［修正を検証］を押します。結果が出るまでは押し直しません。
こんな聞き方も
- StudioのCMSのパス（/posts/:slug など）を移行先でそのまま再現できますか？
- studio cms パス 再現 /posts/:slug
- Studioの動的ページ（/posts/:slug）のURLを移行先でそのまま再現できますか？
- Studioの動的ページのパスを移行先で再現するには？
- Studioの動的ページのパス（/posts/ など）は移行前に変えるべきですか？
- Studio CMSのスラッグがランダムな文字列のままの場合、移行時にどうすればいいですか？
- Studio CMSのランダムなスラッグは変更できますか？
- Studio CMSのスラッグを一括で変更することはできますか？
- Studioのサイトマップから旧URLの一覧を取得するには？
- サイトの全URLを抽出できるツールは何がありますか？
- 500ページ程度のサイトの全URLを無料で抽出するには？
- Studioサイトの画像URLを一覧にして取得するスクリプトは？
- 移行で大量に出た404をURL対応の漏れとして修正するには？
- 移行時にテスト用のnoindexを外し忘れていないか確認するには？
- Studioが出力するHTMLのクラス名はそのまま再利用できますか？
あわせて知りたい（関連する疑問）
QStudioの動的ページのパスは移管前に変えるべきですか？
移管の前に、Studio側でパスを整えておいたほうがいいのでしょうか。急いで変える必要はありません。
Studioの動的ページは、エディターで指定した固定パスと記事ごとのスラッグが結合してURLを構成しています。固定部分を別の文字列に変更すると、その瞬間に公開中のすべての記事のアドレスが新しいものへ上書きされ、古いURLではページを開けなくなります。Studioのリダイレクトページでは、動的ページを転送先に設定できません（Studioのリダイレクト設定）。つまり、Studioの機能だけで変更前のURLから変更後のURLへ訪問者を自動転送させることができません。
一方で、移管そのものはURLの変更を必要としません。Googleは、利用者に見えるURLを変えないホスティング移行の手順を別に出しています。新しい配信先にコンテンツを置いてテストし、そのあとドメインのDNS設定を新しい環境へ向ける流れです。
変更はひとつずつ進めるようにも勧められています。システムの乗り換えとURLの変更を同時に走らせてしまうと、検索順位の急落やアクセス減少が起きた際に、サーバー環境の影響なのかURL変更のリダイレクト処理に起因するものなのか、原因の切り分けが難しくなってしまいますね。URLの構成自体を変更したい場合でも、移管先でリダイレクトを自由に制御できる環境が整い、サイト全体の動作が安定したことを確認してから着手するとトラブルを避けられます。
QStudioが出力するHTMLのクラス名はそのまま再利用できますか？
Studioの公開ページでソースを表示すると、HTMLもクラス名も読めます。でも、読めることと持ち出せることは別の話です。Studioには、作成したWebサイトのHTML、CSS、JavaScriptをソースコードとして外部へエクスポートする機能が備わっていません。デザインエディタで配置したレイアウト情報はシステム内部で処理され、ブラウザへ向けて自動生成されたコードとして配信されます。デザインやページ情報、ソースコード、Studio CMSのデータは書き出せないため、ほかのサービスへ移すときは移管先で作り直します（Studioから書き出せないデータ）。
クラス名は、CSSがどの要素に見た目を当てるかを決めるための目印です。HTMLの class 属性を手がかりに要素を選び、そこへスタイルを当てます。ブラウザから拾ったクラス名を新しいHTMLに書き写しても、それに対応するCSSが移管先になければ見た目は再現されません。
ちなみに、Studio内でもEmbedボックスやカスタムコードを使えばHTMLやスクリプトを足せます。とはいえ、ページ本体のHTMLに手を入れることも、コードとして出力することもできない仕様です。
過去のコードを流用しようと考えるのではなく、移行先で改めてセマンティックなHTMLとCSSを組み直す前提で計画を立ててください。元のデザインや画面表示をデザインカンプ代わりの見本として参照しながら、新しい環境に適したマークアップをゼロから構築していくほうが手戻りを防げます。
Q移行後のお問い合わせ完了ページでコンバージョンを計測するには？
移管したあとで「お問い合わせの件数がGA4に出てこない」と気づくことがあります。フォームの仕組みや完了画面の遷移方法が変わると、従来の計測タグやトリガー条件が反応しなくなってしまうためです。完了ページのURLを条件に計測していた場合、移管でURLが変わったなら、条件も新しいURLに合わせ直します。
Googleアナリティクス4（GA4）で到達を把握するには、全ページの表示を記録する通常のpage_viewとは別に、完了ページの閲覧だけを特定するカスタムイベントを作成し、それをキーイベントとして登録しましょう。
計測タグの管理にGoogleタグマネージャー（GTM）を使っている場合は、ページビュートリガーを開いてPage URLの配信条件を移管後の完了アドレスへ書き換えます。プレビューモードを使えば、変更を公開する前に動作を試せます。
設定を済ませた後は、実際にフォームからテスト送信を行い、GA4のリアルタイムレポートでキーイベントが記録されるか確かめておきましょう。設定が反映されるまで、数分から数時間かかることもあります。
もうひとつ気をつけたいのが、完了の表示がページではなくモーダルになっているケースです。完了ページへのアクセスで数えるこの方法では、モーダルの完了表示は正しく計測できません。モーダル表示を採用するなら、送信完了時に独自のカスタムイベントを発火させるか、送信ボタンの完了状態を検知するトリガーを別途組み込む必要があります。
QサイトのURLが変わることをお客様に告知する必要はありますか？
URLが変わるとき、お客様へのお知らせまで要るのでしょうか。旧URLから新URLへ301リダイレクトを設定しておけば、旧URLを開いた人は自動で新しいページへ移ります。検索エンジンから個別の記事へ訪れる一般的な読者であれば、転送処理が働いている限り閲覧を遮られることはありません。
それでも、転送だけでは片づかない場所もあります。SNSのプロフィールに載せたリンクは、新しいURLへ書き換えましょう。自社のWebサイトを日常的に利用している取引先やリピーターは、ブラウザにお気に入り登録をしていたり、過去のメール履歴に残っているURLからアクセスしたりすることがあります。すでに送ったメールの本文にあるURLは、あとから差し替えられません。重要な取引先や会員に対しては事前の告知を行っておくのが親切です。
ドメインごと変わる場合は、さらに注意が要ります。Studioのリダイレクトページで転送元にできるのは、そのプロジェクトにつながっているドメインのパスだけです。旧ドメインから新ドメインへの転送はこれだけでは組めないため、旧ドメイン側のプロジェクトを残すか、外部の転送サービスを使います。
ドメインが変わるなら、サイト上のお知らせとSNSで一度伝えておけば、旧URLを控えていた人も迷わずに済みます。
この内容をChatGPTで相談
