URLを変えたとき、検索結果にはどちらのURLが出るのでしょうか。Googleの公式ページ「Redirects and Google Search」は、この疑問に答えます。
この記事では、そのページを英語版の原文から読み、リダイレクトの種類ごとにGoogleの扱いがどう違うかを整理します。2026年春に文面が変わった点も、過去の保存版と比べて確かめました。
合同会社謙虚は、3つのドメインを並行して運用し、何を変えると数字が動くかを測り続けています。URLを変える作業は数字の動きを読み違えやすい場面なので、先に公式の説明を押さえておく意味があります。
結論：3行で言うと
- 検索結果に新しいURLを出したいなら永続的リダイレクト（301・308）、元のURLを残したいなら一時的リダイレクト（302・303・307）を選びます
- 方法はサーバー側の設定が最優先です。その次がmeta refresh、さらにJavaScript、リンクでの案内の順に、Googleが正しく読み取れる可能性が下がります
- 2026年春（最終更新日は4月14日）の更新で、一時的リダイレクトは「弱いシグナル」という書き方から、「正規版を決めるシグナルには使わない」という書き方に変わりました
このページの基本情報
| 項目 | 内容 |
|---|---|
| 原題（英語） | Redirects and Google Search |
| 日本語版の題名 | リダイレクトと Google 検索 |
| 英語版の最終更新日 | 2026-04-14 |
| 日本語版の最終更新日 | 2026-04-17 |
| Google検索セントラルの中の位置（章） | Crawling and indexing の中の Site moves and changes（サイトの移転・変更の節） |
| 直近の主な更新 | 2026-04-14。変更履歴に対応する項目は見つからず、保存版との比較で、シグナルの強弱を表す言葉が変わったことを確認しました |
Googleがこのページで言っていること
リダイレクトが役に立つ場面
ページは、リダイレクトが役に立つ場面を4つ挙げています。
- サイトを新しいドメインに移し、できるだけ滑らかに移行したいとき
- 同じページに複数のURLでたどり着けるとき。1つを優先する正規のURLに決め、残りをそこへ転送します
- 2つのサイトを1つにまとめ、古いURLへのリンクを正しいページへ送りたいとき
- ページを削除し、訪問者を新しいページへ案内したいとき
種類と、検索結果への効き方
訪問者には種類の違いがほとんど見えませんが、Googleは種類によって扱いを変えます。決め手は、転送を置く期間と、検索結果に出したいページです。
| 種類 | 方法 | Googleの扱い |
|---|---|---|
| 永続的 | 301、308、meta refresh（0秒）、HTTP refresh（0秒）、JavaScriptのlocation、crypto リダイレクト | Googlebotは転送を追跡し、インデックス登録の過程で「転送先が正規版」というシグナルに使います。検索結果には新しいURLが出ます。元に戻す予定がないときに使います |
| 一時的 | 302、303、307、meta refresh（0秒超）、HTTP refresh（0秒超） | 転送は追跡します。ただ、「転送先が正規版」というシグナルの対象外です。ほかの正規化のシグナルがあれば、転送先がインデックスに入ることもあります。検索結果には元のページが出ます |
ページの表は、Googleが正しく読み取れる可能性が高い順に並んでいます。
永続的の行では、サーバー側のリダイレクトが最も高く、meta refresh、JavaScript、crypto リダイレクトの順に低くなります。
サーバー側のリダイレクト
サーバー側の設定は、サーバーの設定ファイル（Apacheの .htaccess など）を触るか、PHPなどのスクリプトでヘッダーを送って行います。
検索結果に出るURLを変えたいときは、可能な限りサーバー側の永続的リダイレクトを使うよう、ページは勧めています。
301と308が「ページが完全に移転した」ことを表すステータスコードです。
一時的に別のページへ送りたいだけなら、一時的リダイレクトを使います。サービスが一時的に使えないとき、事情を説明するページへ送りながら、元のURLを検索結果に残せる、というのが原文の例です。
原文には、PHP、Apache、別系統のウェブサーバーでの書き方の例も載っています。
meta refreshとHTTPヘッダーの同等の方法
サーバー側の転送が難しい環境では、meta refreshが代わりになることがあります。
Googleは2種類を区別します。読み込み直後に動く「即時」は永続的、秒数を置いて動く「遅延」は一時的です。
JavaScriptのlocationによる転送
Googleは、URLのクロールが終わったあとに、ウェブレンダリングサービスでJavaScriptを実行します。
ただし、描画はさまざまな理由で失敗することがあります。失敗すると、JavaScriptで書いた転送がGoogleに見られないままになる可能性があります。
そのためページは、サーバー側もmeta refreshもできない場合に限って使うよう求めています。
crypto リダイレクト
どの方法も使えない場合でも、ページやコンテンツが移転したことは訪問者に伝えるべきだと、ページは述べています。
いちばん簡単なのは、新しいページへのリンクと短い説明を置くことです。
Googleがこれを crypto リダイレクトとして理解することもありますが、検索エンジンによっては、公式の転送として扱われない場合があります。
ほかに手段がある限り、これに頼らず、先にホスティング事業者へ相談するようにと書かれています。
URLの代替バージョン
リダイレクトすると、Googleは元のURLと転送先のURLの両方を記録します。
どちらか一方が正規版になり、もう一方は「代替名」になります。決め手は、転送が一時的か永続的かといったシグナルです。
代替名は、訪問者がより信頼しているかもしれないURLのことです。クエリから見て古いURLのほうが信頼されていそうなとき、検索結果に代替名が出ることがあります。
ドメインを移転した場合は、新しいURLが登録済みでも、古いURLがときどき表示され続ける可能性が高い、とページは書いています。
これは正常な動きで、訪問者が新しいドメイン名に慣れるにつれて、何もしなくても代替名は出なくなる、という説明です。
英語版と日本語版の違い
英語版は2026-04-14、日本語版は2026-04-17の更新で、日本語版が3日新しい状態です。
見出し・小見出し・表・コード例・リンクの数は両版で一致しました。内容を変える差は見つからず、あったのは次の5点の訳の濃淡です。
| 箇所 | 英語版 | 日本語版 | 読み取り |
|---|---|---|---|
| crypto リダイレクト | Googleがそれを crypto リダイレクトと理解するかもしれない（may） | 「crypto リダイレクトとして認識できるようになります」と、可能性を示す語がありません | 英語版は「そう理解されることがある」程度の書き方です |
| サーバー設定の例の前置き（2つ目のウェブサーバー） | For example（たとえば） | 「たとえば、次のようなリンクです」 | 直後に続くのはリンクではなくコード例なので、訳のずれとみられます |
| 代替名の最後の1文 | alternate names（代替名）が出なくなる | 「代替ドメイン名」が非表示になる | 原文の語は「ドメイン名」に限っていません |
| 代替名の定義 | 訪問者がより認知し、信頼しているかもしれない（might）バージョン | 「ユーザーの認知度や信頼性が高い」と、可能性を示す語がありません | 英語版は「そうかもしれない」程度の書き方です |
| ドメイン移転後の旧URL | 古いURLが引き続きときどき表示される可能性が非常に高い（very likely） | 「引き続き古い URL を表示することがあります」 | 日本語版のほうが弱い書き方です。この記事は英語版に沿って書いています |
更新の経緯
変更履歴（2026-10-01更新の版）で、このページに触れていたのは、2021年6月29日の1件だけでした。
2026年4月14日の更新に対応する項目は、変更履歴にありませんでした。
そこでInternet Archiveの保存版を比べました。
2022年9月16日の版と、2026年1月1日・2月9日・3月2日・3月15日の版は、「>0」と「more than 0」の表記を除けば同じ文面でした。
2026年4月23日の版は現在の英語版と本文が一致し、更新日の表示も2026-04-14でした。変わったのは次の5か所で、変更は3月15日から4月23日の間に入っています。
| 箇所 | 以前の文面（2026年3月15日の版まで） | 現在の文面 |
|---|---|---|
| 種類の概要 | リダイレクトを「強いシグナルまたは弱いシグナル」として使う | 「特定の種類のリダイレクト」をシグナルとして使う |
| 永続的の説明 | 転送先が正規版であることの「強いシグナル」として使う | 転送先が正規版であることの「シグナル」として使う |
| 一時的の説明 | 「弱いシグナル」として使う | シグナルとしては使わない。ほかの正規化のシグナルがあれば、転送先がインデックスに入ることもある（この一文が追加） |
| サーバー側の一時的リダイレクト | Googleが古いURLを結果に「より長く」残す | Googleがリダイレクトの影響を受けず、古いURLを検索結果に残す助けになりうる |
| crypto リダイレクトの前後 | 「従来の（traditional）」転送方法 | 「ほかの（other）」転送方法 |
このページから、言えること・言えないこと
| 言えること | 言えないこと（よくある誤解） |
|---|---|
| 永続的リダイレクトは、転送先を正規版とするシグナルとして使われる | 「301なら必ず新しいURLだけが出る」という読み方は、原文から外れます。正規版はほかのシグナルとも合わせて決まります。正規化のページ（英語版）は、リダイレクトを含む指定を「ヒントであり、規則ではない」と説明しています |
| 一時的リダイレクトは、転送先を正規版とするシグナルには使われない | 「一時的リダイレクトは弱く効く」という読み方は、現在の文面から外れます。以前の「弱いシグナル」という言葉は消えています |
| サーバー側の転送が、最も正しく読み取られやすい | 「JavaScriptの転送もサーバー側と同じ」という読み方は、原文から外れます。描画に失敗すると、Googleに見られない可能性があります |
| このページの記述は、転送の種類と、検索結果に出るURLの関係までである | 「転送を1回挟むと評価が減る」という根拠や、連鎖への言及は、このページの外で探すことになります。移転の手順のページ（英語版、2026-08-20更新）には、301などの永続的リダイレクトでPageRankは失われないこと、連鎖は避けること（Googlebotは最大10回まで追えるが、3回以内が望ましく5回未満）が書かれています |
| 転送を残す期間の目安は、移転の手順のページにある | 期間は、このページから読み取れる情報の外です。移転の手順のページは「できるだけ長く、一般には少なくとも1年」と書いています |
連鎖の回数と1年の目安は、移転の手順のページ（英語版）を開いて確かめた記述です。リダイレクトを含む正規化の考え方は正規化のページ（英語版）にあります。
中小企業の視点で、どう受け取るか
ここからはGoogleの説明とは別の、私の読み取りです。
1. 「戻す予定があるか」で種類を決める
ドメインの移転、URLの変更、サイトの統合は、元に戻さない前提の作業です。永続的（301か308）を選びます。
工事中や在庫切れで数日だけ別のページへ送る場合は、一時的（302など）が合います。
見落としやすいのは、一時的で始めた転送を、移行が終わってもそのままにしている状態です。検索結果に元のURLが残り続ける原因になりえます。
2. 手段は、上から順に当たる
順番は、ページの表と同じです。まずホスティングの管理画面に、リダイレクトの設定項目があるかを見ます。
次に、WordPressで転送を扱うプラグインや.htaccessを使えるかを確かめます。プラグインを使う場合も、中身がサーバー側の301になっているかを、次の手順で確認します。
それでも難しいときに、即時のmeta refresh、JavaScript、リンクでの案内の順に進みます。
3. 設定したら、外から確かめる
ブラウザには転送後の画面だけが表示されるため、転送の種類は見た目から判別しにくいものです。
旧URLに対して curl -sI https://example.com/old-page/ を実行し、1行目が 301 か 308 になっているか、location の行が新しいURLになっているかを見ます。
Search Consoleの「URL検査」でも、旧URLがどう扱われているかを見られます。画面の名前は変わることがあり、今回の作業で画面は未確認です。
原文のコード例は、考え方を示す見本です。原文の return の例には行末のセミコロンがないので、そのまま貼らず、ホスティング事業者の手順で書き直します。
4. 旧URLが検索結果に残っても、慌てない
ドメインを移転した直後は、新しいURLが登録済みでも旧URLが出ることがあります。ページはこれを正常な動きと説明しています。
慌てて設定をいじる前に、旧URLが意図した種類の転送になっているかを、前の手順で確かめます。
実務の手順は既存記事にあります。
転送の対応表を作り直しの前に決める話はホームページを作り直しても問い合わせが増えない本当の理由と直す順番で、リニューアルで301の設定漏れが起きる失敗はBtoBサイトの設計の記事で扱っています。
弊社のサイトで確かめたこと
2026年10月8日に、kenkyo.ai に対してコマンドを実行しました。
確認できるのは、サーバーが返すステータスコードとHTMLの中身までです。Googleの検索結果での見え方は、未確認です。
- www付きのURL：
curl -sI https://www.kenkyo.ai/の結果は301で、locationは https://kenkyo.ai/ でした。x-redirect-by: WordPressの行があり、転送しているのはWordPressです - 転送の回数：
curl -sL -o /dev/null -w "%{num_redirects}" https://www.kenkyo.ai/は、1回で https://kenkyo.ai/ に着き、最終のステータスは200でした - 末尾のスラッシュなしの記事URL：
curl -sI https://kenkyo.ai/site-structure-saitekikaは、301でスラッシュ付きのURLへ転送され、最終は200でした - 存在しないURL：実在しない記事のURLを
curl -sIで指定すると404で、トップページへの転送は起きませんでした - トップページのHTML：
curl -sL https://kenkyo.ai/の中身を検索し、meta refreshは0件、canonicalは自分自身（https://kenkyo.ai/）でした。window.locationは3か所ありましたが、どれもURLの値を読む処理で、ページを移動させる命令ではありませんでした
ここから分かるのは、別の入口（www付き、スラッシュなし）が、サーバー側の301で1回の転送で正規のURLに集まっていることです。
今回の確認の範囲では、302の応答も、meta refreshやJavaScriptの転送も見つかりませんでした。
よくある質問
301リダイレクトと302リダイレクトで、Google検索の結果は変わりますか？
公式ページの説明では、変わります。
永続的（301・308）は検索結果に新しいURLを出し、一時的（302・303・307）は元のページを出す、という整理です。
ただし、ほかのシグナルがあれば、一時的でも転送先がインデックスに入ることがあると、ページ自身が書いています。
meta refreshやJavaScriptのリダイレクトは、301の代わりに使えますか？
サーバー側の転送ができないときの代わりにはなります。即時（0秒）のmeta refreshは永続的、遅延のmeta refreshは一時的として読まれます。
JavaScriptは、描画に失敗すると見られない可能性があるため、ページは最後の手段に近い扱いにしています。
リダイレクトを設定したのに、古いURLが検索結果に出続けるのはなぜですか？
ページの説明から考えられるのは、元のURLが「代替名」として記録されているためです。訪問者がその名前を信頼していそうなクエリのとき、代替名が出ることがあります。
まず、旧URLが意図した種類の転送（永続なら301か308）になっているかを確かめます。出続ける期間の目安は、このページに書かれた範囲の外です。
まとめ：今日できる1つのこと
自社の旧URLを1本選び、curl -sI で1行目が301か308になっているかを確かめてください。
一時的な転送のまま残っているURLが見つかれば、それが今日直せる1件です。
この記事は、Google検索セントラル解説の一覧の一本です。ほかのページの解説も、順次公開しています。
この記事に書いたことを、そのまま御社のページに
生成AIに引用されるページを、お話しいただくだけでお作りします。お時間をいただくのは初回15分のヒアリングだけです。まず1ページ、無料でお作りします。
OKが出るまで、何度でも直します。事実が違う、言い回しが硬い、この話は入れないでほしい。どれも遠慮なくおっしゃってください。何度お直ししても、追加の料金はいただきません。
これまでに127社にご利用いただきました。毎月ご依頼いただいている方の6割以上が、月10ページを選ばれています。料金はページに掲載しています。
ページを増やしても問い合わせが来ないなら、原因はページの外にあります。その場合は、下の入口からご相談ください。
自社のマーケティング課題を根本から解決しませんか？
ウェブサイトから要素を引き算し、訪れた人が迷わず次の一歩に進む形へ組み直す。初回60分のオンラインで御社のサイトを一緒に読み、どこから直すべきかをお伝えします。手順をまとめた無料の診断と解説動画もご用意しています。
初回は無料・60分・オンライン完結・その場で契約のお願いはいたしません
