サイト移行で検索順位を守る鍵は、301リダイレクト・XMLサイトマップ・公開前のnoindexの3点。ただし新規立ち上げならリダイレクトは不要。自分のケースの見極め方を実体験から解説します。
結論：サイトを移行するとき検索順位を落とさないために重要なのは、(1)旧URLから新URLへの「301リダイレクト」、(2)新しい「XMLサイトマップ」のGoogleへの送信、(3)公開前の「noindex／パスワード保護」、この3つです。ただし、ゼロから立ち上げる新規サイトの場合は、引き継ぐ旧URLが存在しないため、移行用のリダイレクトは不要です。
検索順位は「URL」に紐づいて積み上がっています。URLが変わったのにGoogleへ正しく伝えないと、それまでの評価がリセットされたり、公開前の未完成ページが検索結果に出てしまったりします。この記事では、AIテックベースの立ち上げと、その後に実際に行った「61ページのURL変更」の経験をもとに、何を・どの順番で・どこまでやれば十分なのかを、非エンジニアの視点で整理します。
1. 301リダイレクト：旧URLの評価を新URLへ引き継ぐ
結論：既存サイトを移行してURLが変わる場合は、旧URLから新URLへ「301リダイレクト」を設定します。
301リダイレクトは、「このページは新しい住所へ恒久的に引っ越しました」という宣言です。Googleは301を見ると、新しいURLを正式なURLとして扱い、旧URLに積み上がっていた評価（被リンクなど）を新URLへまとめます。これをやらずにURLだけ変えると、旧URLは「404（ページが見つかりません）」になり、これまでの順位や、他サイトからのリンクの効果が失われます。
種類 | 意味 | 移行での扱い |
|---|---|---|
301（恒久的な移転） | URLが永久に変わったとき | 移行では基本これを使う（308も同じ扱い） |
302（一時的な移転） | メンテナンス中など一時的な転送 | 「いずれ元に戻る」という合図になるため、移行には使わない |
以前は「302では評価が引き継がれない」と言われていましたが、Googleの担当者は2016年に、302を含むどの種類の転送でも評価（PageRank）は失われないと発言しています。Googleの公式の説明で示されている違いは、転送先を「正式なURL」とみなすかどうかです。302だと、Googleは旧URLを正式なまま残そうとすることがあります。恒久的な移転なら301を使う、という原則は変わりません。
リダイレクトの基本ルールは次のとおりです。
- 旧ページと内容が対応する新ページへ、1対1で転送する
- 転送が何段も連鎖（A→B→C）しないようにする。過去に転送を設定したことがあれば、古いURLも最終的な転送先へ直接向け直す
- サイト内のリンクも新しいURLに書き換える（転送に頼りきりにしない）
- 転送は少なくとも1年は残す。Googleは最低1年の維持を勧めており、他サイトからのリンクがある限り、できれば残し続けるのが安全
ドメインそのものを変える場合（例：旧ドメインから新ドメインへ）は、301の設定に加えて、Search Consoleの「アドレス変更ツール」でGoogleに引っ越しを知らせます。
2. 新規立ち上げならリダイレクトは不要。ただしURLを変えたら必要になる
結論：引き継ぐ旧URLが存在しない「新規立ち上げ」では、移行用の301リダイレクトは不要です。ただし、公開後にURLを変えたら、その時点で必要になります。
AIテックベースは、WordPressから静的サイトの構成（Astro＋microCMS＋Cloudflare® Pages）へ作り替えたプロジェクトでした。サイト構成とURL設計を新しく組み直したため、立ち上げの時点では、旧URLを個別に転送する作業は発生しませんでした。
ところが公開から約2か月半後の2026年9月、記事のURLを「20260915_5」のような日付と番号の形式から、「claude-md-operation-guide」のような内容が分かる英語の形式に変更しました。URLに記事の内容を表す言葉が入っていると、読者がリンクを見ただけで中身を想像しやすくなるためです。このとき、変更した61ページすべてについて、旧URLから新URLへの301リダイレクトを1対1で設定しました。
Cloudflare Pagesでは、「_redirects」という名前のファイルに「旧URL 新URL 301」と1行ずつ書くだけで転送を設定できます。末尾に「/」があるURLとないURLの両方を書いておくと、転送漏れを防げます。「移行＝必ずリダイレクト」でも、「新規だから一生不要」でもなく、URLが変わるたびに必要になる、と覚えておくのが正確です。
3. よくある誤解：「全部トップページへ転送すればいい」ではない
結論：サイト全体をトップページへ1本で転送する方法では不十分です。ページ単位で1対1に対応させる必要があります。
「とりあえず全部トップページに転送しておけば安全だろう」という考え方は、よくある落とし穴です。Googleは、内容の対応しないページへの大量の転送を「実質的には存在しないページ（ソフト404）」として扱うことがあり、個別ページの評価はほとんど引き継がれません。読者にとっても、目的の記事を探していたのに突然トップページへ飛ばされると、「壊れたサイト」という印象を持たれかねません。
ページ数が多いサイトでは、旧URLと新URLの対応表を表計算ソフトで作り、そこから機械的に設定するのが確実です。本当に対応するページがない場合は、無理に転送せず、404を返すほうが適切です。
4. サイトマップ：新しいサイトの地図をGoogleに渡す
結論：サイトの全ページの一覧である「XMLサイトマップ」を用意し、Google Search Consoleから送信します。
サイトマップは、Googleに「このサイトにはこういうページがあります」と地図を渡す行為です。特に立ち上げ直後や移行直後は、Googleがまだサイトの全体像を把握していないため、地図を渡すことで発見と登録（インデックス）が早く、漏れなく進みます。
Astroのような静的サイトの仕組みでは、サイトを組み立てる（ビルドする）ときにサイトマップを自動で作れます。AIテックベースでは、microCMSで記事を公開するとサイトが自動で組み立て直されるため、サイトマップも公開のたびに最新になります。WordPressでも、SEOプラグインの多くがサイトマップを自動で作ります。大切なのは、それを実際にSearch Consoleへ送信し、正しく読み込まれているかを確認することです。
見落としがちな点として、サイトマップには「転送元の旧URL」ではなく「新しいURL」だけを載せます。AIテックベースでも、サイトマップに載っている記事のURLが、実際に読者が開くURLではなく管理用の番号の形式になっていたのに気づき、修正したことがありました。サイトマップの中身は、公開後に一度は自分の目で開いて確かめておきましょう。
5. 公開前のnoindex／パスワード保護：未完成ページを検索に出さない
結論：制作途中・確認用のサイトは、検索結果に出ないよう「noindex」または「パスワード保護」をかけてから作業します。
未完成のページや確認用のURLがGoogleに拾われると、中途半端な内容が検索結果に表示されたり、本番のURLと内容が重複していると見なされたりする恐れがあります。AIテックベースでも、公開前はCloudflare Pages側でパスワードをかけ、関係者だけが見られる状態で確認しました。
方法 | 内容 | 向いている場面 |
|---|---|---|
noindex | ページに「検索結果に載せないで」と指示するタグを入れる。閲覧はできる | 公開予定だが、今は検索に載せたくないページ |
パスワード保護（Basic認証など） | IDとパスワードを知る人だけが閲覧できる。Googleも入れない | 関係者だけで確認する制作中のサイト全体 |
よくある勘違いが、「robots.txtでGoogleの巡回を禁止すれば検索に出ない」というものです。robots.txtで巡回を禁止すると、Googleはページの中のnoindexの指示も読めなくなります。その結果、他サイトからリンクされていると、中身のないままURLだけが検索結果に出ることがあります。検索に出したくないページは、巡回は許可したうえでnoindexを付けるか、パスワードで保護します。
そして公開時には、noindexやパスワード保護を必ず外します。外し忘れると、いつまで経っても検索結果に出てこない、という事故が起こります。公開日をカレンダーに入れるのと同時に、「noindex解除の確認」もタスクとして登録しておくと安全です。
6. Search Console：移行・公開後の必須ツール
結論：Google Search Console（無料）に登録し、サイトマップの送信とインデックス状況の確認を行います。
Search Consoleは、「Googleから見て自分のサイトがどう見えているか」を確認できる公式ツールです。推測ではなく事実で状況を把握できます。
- サイトマップの送信と、読み込み状況の確認
- 各ページがインデックス（検索登録）されているかの確認
- URL検査ツールで、特定のページの登録を個別にリクエスト
- 移行時のエラー（404の急増など）の検知
URL変更の直後は、検索結果に旧URLと新URLが一時的に混在したり、順位が揺れたりすることがあります。これは、Googleが新しいURLを巡回し直すまでの一時的な現象であることが多く、Googleの説明では、中規模のサイトで数週間以上、大規模なサイトではさらに長くかかり、順位の揺れは時間とともに落ち着くとされています。慌ててさらに設定を変えるより、数日おきにエラーが増えていないかを確認するほうが大切です。旧サイトがある場合は、移行前の数週間分の「検索パフォーマンス」のデータを保存しておくと、移行後に順位が落ちたページを見つけたときの比較材料になります。
7. 静的サイトとSEOの関係
結論：静的サイト（Astroなど）は表示が速く、構造がシンプルなぶん、SEOの土台として扱いやすい構成です。ただし、速さだけで順位が決まるわけではありません。
静的サイトは「あらかじめ完成したページを返すだけ」なので高速です。表示の速さや操作への反応の良さは、Googleがページの使いやすさとして見ている要素の一つです。加えて、管理画面・プラグイン・データベースといった攻撃されやすい部分がないぶん、セキュリティ面でも有利です。
一方でGoogleは、ページの使いやすさが多少劣っていても、最も関連性の高い内容を優先して表示するとしています。静的サイトにしただけで順位が上がるわけではなく、「速くて安全な土台の上に、読者の役に立つ記事を積み上げる」と捉えるのが実態に近いでしょう。
8. 中小企業がひとりで移行するときの進め方
専任のSEO担当者や制作会社がいない中小企業でも、次の順番で進めれば大きな事故は避けられます。
- 移行が「URLを引き継ぐ移行」か「新規立ち上げ」かを確定する
- 引き継ぐ場合は、旧URLと新URLの対応表を作る
- 公開前は、noindexかパスワード保護をかける
- 公開と同時に、301リダイレクトを有効にし、noindexを解除する
- Search Consoleにサイトマップを送信する
- 公開後1〜2週間は、検索パフォーマンスとエラーを定期的に確認する
- 転送は少なくとも1年は残す
作業の中で試行錯誤が起きたときは、「原因らしきものを片っ端から試す」のではなく、先に環境の仕様を確かめることが近道です。AIテックベースの移行では、自動公開の設定で半日つまずきましたが、原因はサーバー会社のセキュリティ設定でした（くわしくは関連記事で紹介しています）。旧サイトのページ数が数百を超えるような規模なら、対応表の作成やリダイレクトの実装だけでも、専門家に部分的に依頼する価値があります。目的はすべてを自社で完結させることではなく、「事故を起こさずに移行を終える」ことです。
9. まとめ
- URLが変わるときは、旧URL→新URLへ301リダイレクトを1対1で設定する。302は「一時的」の合図なので移行には使わない
- 新規立ち上げなら移行用のリダイレクトは不要。ただし公開後にURLを変えたら、その時点で必要になる（AIテックベースでは61ページで実施）
- 全部をトップページへ転送すると、ソフト404として扱われ、評価が引き継がれない恐れがある。転送は少なくとも1年維持する
- XMLサイトマップには新しいURLだけを載せ、Search Consoleから送信する
- 公開前はnoindexかパスワード保護。robots.txtで巡回を禁止するだけでは検索から隠しきれない。公開時に必ず解除する
- Search Consoleで登録状況とエラーを事実で確認し、一時的な順位の揺れには慌てない
CloudflareおよびCloudflare Pagesなどのサービス名は、Cloudflare, Inc.の商標または登録商標です。
