EmDash移行前のSEO確認票｜URLと公開条件の注意点

こんにちは。Osukeラーニング、運営者の「osuke」です。

EmDashへの移行を考えたとき、記事が移せるかと同じくらい気になるのが、今あるURLや検索流入をどう扱うかですよね。サイトが表示されたり、移行準備が終わったりしても、それだけでSEOの確認まで終わるわけではありません。

この記事は、2026年11月3日に確認したEmDashとGoogleの公式資料をもとに作った調査記事です。実サイトの移行やSEO設定、検索順位の検証は行っていません。旧URLから新URLへの対応案、公開条件、canonical、サイトマップを、操作の前に整理できる確認票としてまとめます。

記事のポイント

• 旧URLと移行先候補を対応づける際の注意点
• 公開状態・認証・検索への掲載を分ける考え方
• 公式仕様と実サイトの出力を区別する確認票
• 担当と未確認を残す架空のURL対応例

EmDash移行前のSEO確認項目

最初に、何を残したいのかをはっきりさせます。記事本文だけでなく、読者がたどるURL、画像、関連記事への経路も確認対象に入れると、移行先に求める条件が見えやすくなります。

旧URLと対象ページを洗い出す

移行前の一覧は、投稿タイトルだけで作らず、旧URLを1行ずつ並べるところから考えます。同じようなタイトルでも、公開中の記事、カテゴリ一覧、固定ページでは役割が違うためです。たとえば「始め方」という記事と「初心者向け記事の一覧」を同じ移行先にまとめると、読者が期待した内容へ着けない可能性があります。まずは手元の公開履歴や既存資料から分かる範囲を記入し、取得していないURLの種類を別欄に残す方法が取り組みやすいと思います。

仮に記事が30本あるなら、「記事30本を書き出せた」と「サイト内の確認対象をすべて把握した」は分けて記録します。画像ファイル、PDF、カテゴリ、過去に外部から紹介されたページなどが、記事一覧の外にあるかもしれません。数を早くそろえるより、一覧の出どころと対象範囲を添えることが大切です。「管理用の公開記事一覧をもとに作成。添付ファイルと旧URLの別表は未確認」と書いておけば、次に誰が何を補うのかが明確になります。

優先順位は、残したい読者の行動から決めます。資料で流入や被リンクを確認できるページ、問い合わせに使う固定ページ、主要記事から案内しているページなどを先に見ます。計測資料がなければ、流入の少ないページだと決めつけず「重要度未判定」にします。移行先の比較自体がまだなら、EmDashとWordPressの比較記事も判断材料になります。この段階の成果は、移行の可否や完了数ではなく、確認すべき対象を説明できる一覧です。

URLの対応案に未確認を残す

旧URLと新URLの表は、最初から「設定済みの転送一覧」と呼ばず、対応案として作ります。移行先のページ名が決まっていても、そのURLで同じ内容が公開されるかは別の確認だからです。たとえば旧記事が日付入りURLで、新しい案が短い英字のパスなら、文字列の置き換えだけでなく、本文の対象や公開予定も合わせて見ます。担当者に渡すときも「この表どおりにすべて転送してよい」と受け取られないよう、案の段階であることを表題へ入れます。

対応先が不明な行は空欄にせず、「未定・内容の対応確認待ち」と書くのがおすすめです。空欄は、未入力なのか、意図的な削除なのか、移行不要なのかが読み手によって変わります。架空の旧URL「example.com/2025/guide/」に対し「example.net/articles/guide/」を候補にするなら、同じ記事が載る予定か、統合後の記事へ案内するのかを短く添えます。末尾のスラッシュ、数字のID、日本語パスなども、表記の違いを勝手に同一扱いせず確認事項にします。

すべての旧URLを新しいトップページへ向ける案には、内容の対応という観点から立ち止まりたいところです。読者は特定の答えを探して旧記事を開いているかもしれません。削除する記事、別記事に統合する記事、同じ内容を引き継ぐ記事を分けると、担当者へ質問しやすくなります。Googleのサイト移転ガイドも、URL対応表を移転準備の一部として扱っています。表を作っただけで転送や評価の引き継ぎが成立したとは考えず、実装後に確認する条件まで書いておきます。

公開状態と認証を分けて考える

「公開しない」という言葉には、記事を下書きにする、認証した人だけが閲覧できるようにする、検索結果に掲載させない、といった異なる意味が混ざりがちです。確認票では、この3つを別の欄にします。記事の状態が公開でも、サイト入口に認証があれば通常の読者が本文まで進めない場合があります。反対に、検索結果へ出したくない設定にしたつもりでも、URLを知る人が直接読めるかどうかは別の話です。公開範囲の希望を先に言葉にしておくことが大切ですね。

Googleのnoindexの説明では、Googlebotがその指示を読めることが前提です。noindexは閲覧者の本人確認ではありません。この違いを踏まえ、架空の検証ページなら「本人だけ閲覧可能にしたい」、公開予定の記事なら「一般読者が読めて検索対象にもしたい」と目的を別々に記入します。ここで認証を解除したり、検索設定を変えたりする必要はありません。現在の状態が不明なら、希望と実際の確認結果を分けて、実際の欄には未確認と書きます。

移行先を見られた人が管理者だけだった場合も、「公開確認済み」の対象を管理者のログイン状態に限定して記録します。一般閲覧の可否まで確認したことにはなりません。公開前の判断を急ぐと、本人には見えているため問題に気づきにくい場面も考えられます。確認票には「誰として」「どの入口から」「本文まで見えたか」という観点を用意しておくと、後で検証を依頼しやすくなります。特に個人情報を含む原稿では、検索に出ないことを秘密保持の根拠にせず、公開範囲の担当者へ確認する条件を残します。

canonicalとサイトマップの役割

canonicalは、同じ内容や似た内容のURLが複数あるとき、どれを代表として扱ってほしいかを伝えるためのものです。サイトマップは、検索エンジンに把握してほしいURLを知らせる役割があります。Googleの正規URLの説明を踏まえると、どちらかを入れれば必ず希望どおりに検索結果が変わる、と考えるのは避けたいところです。確認票では、代表URLの希望と、ページや一覧に実際に書き出されるURLを並べます。

架空の公開予定が「example.net/articles/guide/」なのに、canonicalの候補が旧ドメイン、サイトマップの候補が本人限定の検証ドメインなら、3つの説明が食い違っています。まだ実サイトを見ていなくても、設計資料の段階でこの不整合には気づけます。逆に、資料上の3つがそろっていても、実際のHTMLやXMLが同じとは限りません。「方針一致」と「実出力一致」を分ければ、資料作成が終わったことを、SEO設定の検証完了へ読み替えずに済みます。

下の表は、調べる対象を混同しないための整理です。入力画面の有無を数えるより、何が出ていれば予定と一致するのかを書くほうが、後から確認する人の助けになります。たとえば「canonical確認」とだけ依頼するより、「公開予定URLと一致し、旧ドメインや検証用ドメインが混ざっていないこと」と書きます。サイトマップも、取得できることと対象ページが載ることを分けます。掲載自体を、インデックスや順位の保証として扱わない点も、確認票に一緒に残したいですね。

画像と内部リンクの確認対象

記事本文のURLだけをそろえても、本文の画像や関連記事へのリンクが旧サイトに依存したままなら、読者の経路は途中で途切れるかもしれません。資料を作るときは、本文ページとは別に「画像の参照先」「記事から出ていく内部リンク」「他の記事から入ってくるリンク」を確認対象にします。記事が読めることと、記事の中で案内した先まで使えることを分けるイメージです。すべてを今すぐ検査するのではなく、対象の抜けを減らす一覧を先に用意します。

架空の例では、新記事のURLを決めた一方、本文内の画像だけ「example.com/uploads/photo.jpg」のまま、関連記事も旧URLのままというケースが考えられます。この場合、「旧サイトを残す期間」「画像の新しい保存先の案」「リンク差し替えの担当」が未定なら、そのまま記録します。画像が画面に一度表示されたとしても、旧配信元の継続性や別の利用者からの閲覧まで分かるとは限りません。元データがあるか、参照先が変わるか、公開後も利用できる条件かを、別々の質問にするのが実用的です。

移行対象が多いときは、画像のある記事、画像のない記事、複数の関連記事へ案内する記事など、性質の違うページを確認候補にします。代表例が数件動いても全件の確認とはしませんが、どの種類をまだ見ていないかが分かれば、依頼内容を絞れます。バックアップの保存先や復元の考え方はEmDashのバックアップと更新の注意点で別に整理しています。ここではデータ移行の実作業へ踏み込まず、公開URLと素材・関連記事のつながりを説明できる状態を目指します。

EmDash移行前のSEO確認票

ここからは、公式資料を読んで分かったことと、実際のサイトで後から確認することを分けます。担当が決まっていない欄や証拠がない欄を、無理に「完了」で埋めない使い方が前提です。

公式仕様と実サイト出力を分ける

EmDashの公式SEOガイドには、コレクションのSEO有効化やページ側のEmDashHeadの組み込みなど、機能を利用する前提が説明されています。機能が用意されていることを、そのまま自分の導入版やテーマに適用済みと読むのは避けたいですね。「資料ではできる」と「このサイトで出ている」の間に確認欄を置きます。特に、すでに作られたサイトを引き継ぐ場合は、採用した構成や更新時点を資料と照合する作業が残ります。

もう一つ気をつけたいのが、取り込んだSEO用の値と、ページに反映される値の違いです。公式ガイドは、WordPressから取り込む一部のSEOデータが通常のコンテンツフィールドであり、SEOパネルとは別である点を説明しています。したがって、管理用の一覧に説明文が見つかっただけで、公開ページの説明文まで正しく出ているとは言えません。確認票では「値の存在」「どこで使う予定か」「出力の確認結果」の3段階に分け、移行した項目名だけを完成の証拠にしません。

この区分なら、実サイトを動かせない段階にも意味があります。公式資料のURLと確認日を添え、導入版の対応状況、テーマでの利用箇所、実出力の3点を未確認として引き継げるからです。「何も分からない」と止める必要も、「標準機能だから大丈夫」と結論を急ぐ必要もありません。下の表は記入用の枠であり、EmDashで実際に確認できた結果ではありません。担当者に渡す際は、資料調査だけ済んだ項目の状態を「仕様確認」にとどめると、次の検証の範囲が伝わりやすくなります。

リダイレクトの担当と検証条件

リダイレクトは、誰がどの入口の応答を管理するかまで決めておきたい項目です。旧ドメイン側、新サイト側、配信基盤側のどこに責任があるか分からないままでは、URL対応案ができても実装の依頼先が決まりません。特にドメインを変える場合、新サイトに機能があるという説明だけで、旧ドメインへ来たアクセスの行き先まで決まったことにはなりません。確認票に旧入口の管理者と予定する担当を分けて書くと、必要な質問を絞れます。

Googleのリダイレクトの説明では、恒久的な移動と一時的な移動を区別しています。ここでは設定値を変更せず、移行の意図と期待する応答を担当者へ確認する欄を用意します。たとえば「記事Aを恒久的に新記事Aへ案内したい」という要望に対して、旧URLから最終的な新URLへ到達するか、途中で別のURLを経由するか、内容が対応するかを確認条件にします。数字のコードだけ合っていても、別記事へ着いてしまえば読者の目的は満たせません。

依頼書には、対象となる旧URL、新URL案、恒久か一時かの意図、実装担当、検証する人、判定材料を残します。「転送OK」という一言より、「この旧URLからこの新記事へ到達し、途中経路と本文を確認した」と書ける証拠の形を決めておくほうが役立ちます。まだ担当がいないなら、実装時期を決めず「担当未定につき切替判断を保留」と記録します。設定例のコピーや本番切替をこの確認票だけで進めず、変更する範囲の説明と許可を先に整えることが、管理を引き継ぐ場面でも大切です。

架空の対応表で不足を見つける

下の3行は、書き方を示すための架空例です。example.comとexample.netは例示用であり、実在サイトの移行結果や設定指示ではありません。「同じ記事を引き継ぐ」「複数記事を統合する」「移行先が決まらない」という異なる場面を並べています。表の目的は、見た目を完成させることより、判断材料が足りない行を見つけることです。候補URLを記入できても、内容の対応や公開範囲、担当が未定なら、実装へ進める条件がそろったとは扱いません。

1行目なら、同じガイドを載せる案まではありますが、実際にそのページが存在し、予定した内容が表示されるかは未確認です。2行目は統合案なので、旧記事で答えていた疑問が新記事にも残るかという編集上の確認が必要です。3行目は、行き先を埋めるより先に、そのページを残すのか、削除するのかを決める必要があります。このように「案あり」「編集判断待ち」「方針未定」を区別すれば、全体をひとまとめに移行完了と呼ぶことを防げます。

実際に使う場合は、確認日と確認者、根拠となる資料の場所も追記します。私なら、URLの対応、公開条件、実応答、検索の観測を別々の状態で管理します。たとえば対応案だけ承認された行は「案承認・実装前」とし、実応答の欄は未確認のまま残します。作業を依頼する相手が変わっても、どこまで終わっているかが読み取れるためです。表を共有する前には、管理用URLや認証情報、非公開原稿などが混ざっていないかも確認し、必要な判断材料だけを渡すようにします。

検索維持を保証しない観測計画

URLや表示を確認できたとしても、検索順位や流入の維持まで同時に分かるわけではありません。観測計画は、移行前の基準を残すところから用意します。既存の計測資料があるなら、期間、対象ページ、指標の定義をそろえます。資料がなければ、比較基準がないと記録します。公開直後にアクセスが少ないという一点だけで失敗と決めたり、数件の訪問だけで成功と決めたりしないように、何をもとに判断するのかを先に決めておきたいですね。

たとえば、移行前の28日間を基準候補にするのは当サイトからの管理例であり、Googleが定める完了期限ではありません。季節性、記事の追加、告知の有無などで比較条件も変わります。移行後は、URLへ着けるか、意図したページが検索対象になっているか、検索経由の表示やクリックにどのような変化があるかを順に見る計画にします。指標を取得できなかった日は「0」ではなく「未取得」です。検索エンジンによる処理を、記事公開時刻と同じ時計で完了扱いにしないことが大切です。

Xでは、自社サイトの移行準備を報告する投稿や、開発中のWordPress移行経路に触れた投稿を確認しました。ただし、これらは投稿者の申告で、検索順位の維持を裏づける検証ではありません。前者の可視の会話には保守する人への懸念もありました。こうした期待と不安を踏まえても、他者の準備報告を自分のサイトの成果予測へ置き換えず、担当と観測条件を用意する姿勢が役立つと思います。今回、動画や実サイトでの移行成績は確認していません。

EmDash移行前のSEO確認まとめ

EmDash移行前のSEO確認票で最初にそろえたいのは、旧URL、対応する新URL案、公開したい範囲、担当、未確認事項です。機能の名前を並べるだけでは、誰が何を確認すれば切替の判断に進めるのかが残りません。「資料で確認した仕様」「このサイトで採用する方針」「実際の出力」「公開後の観測」という4段階に分けると、今できる準備と、まだ根拠がない部分を説明しやすくなります。小さなサイトでも、この区分は引き継ぎの助けになると思います。

まずは主要な3ページを例として票に書き、同じ記事を残す行、統合する行、行き先未定の行で、何が不足するかを見てみてください。この3ページは確認票を試すための件数例であり、全サイトの安全を判定する基準ではありません。未確認が多くても、埋めるべき質問が見えたなら準備は進んでいます。一方、記入欄を埋めたことを実装や検証の完了数に数えないようにします。実サイトを動かす段階では、対象と変更範囲をあらためて決め、必要な許可を得たうえで確認します。

この記事では、実サイトの設定変更、移行データの投入、リダイレクトの実装、検索結果の改善検証は行っていません。参照した公式資料は2026年11月3日の確認時点であり、利用する版やテーマによって照合が必要です。表示や公開経路で困った場合の論点は、EmDashのトラブルを切り分ける記事にも整理しています。まずは手元の資料で確認票を作り、分からない欄に担当と次の質問を書き足す。その状態を起点にすれば、移行への期待を保ちながら、根拠のない完了判断を減らせます。

制作上の補足：構成と確認票の整理にはAIを活用しています。架空例は説明用に作成したもので、実際の移行・設定・検索改善の実績ではありません。