301リダイレクトが使えないときの転送手順と優先順位
無料ブログのサービスには、サーバーの設定ファイルを触る手段がありません。だから301リダイレクト（永久にURLが変わったことを転送で伝えるサーバー側の設定）が設定できない。——それでも打つ手はあります。
Google の公式ドキュメントは、転送の手段に優先順位を付けています。サーバー側の転送が第一。それが不可能な場合は、恒久的な転送なら待ち時間0秒の meta refresh（HTMLに書く自動転送のタグ）、一時的な転送ならもっと長い待ち時間。JavaScript による転送は「最後の手段」として挙げられています。
つまり、選択肢がないのではなく、順番があるということです。
公式が挙げる転送手段の順番
| 手段 | 公式ドキュメントでの位置づけ | 選ぶ場面 |
|---|---|---|
| サーバー側の転送 | 推奨（恒久は301/308、一時は302/303/307） | サーバー設定やCMSの転送機能を触れる |
| 待ち時間0秒の meta refresh | サーバー側が不可能な場合の、恒久的な転送 | HTMLの<head>を編集できる |
| 待ち時間の長い meta refresh | サーバー側が不可能な場合の、一時的な転送 | 期間限定で別ページへ寄せたい |
| JavaScript による転送 | 最後の手段 | <head>も触れず、本文にコードしか置けない |
一段ずつ下りていくのがこの表の読み方です。まず、契約しているサービスに転送機能がないか探す。無ければ <head> を編集できるかを見る。それも無理なら、記事本文にスクリプトを埋め込めるかを確かめる。上の段が使えるのに下の段を選ぶ理由はありません。
meta refresh はどこに書くか
公式ドキュメントは、meta refresh を HTML の <head> 要素の中か、サーバー側のコードで HTTP ヘッダーとして 置くように書いています。恒久的な転送として使うなら、待ち時間は0秒です。
<!doctype html>
<html>
<head>
<meta http-equiv="refresh" content="0; url=https://example.com/new-page">
</head>
</html>
待ち時間を5秒にした書き方も公式に例示されています。こちらは一時的な転送の側です。
<meta http-equiv="refresh" content="5; url=https://example.com/newlocation">
ここでつまずきやすいのが、無料ブログの編集画面です。記事本文のHTMLは編集できても、<head> には触れない仕様のサービスがあります。テンプレート編集やカスタムHTMLの設定欄を探して、そこに入れたタグが実際にページの <head> に出ているかを、ブラウザでソースを表示して確かめてください。本文の途中に出力されていたら、意図した場所ではありません。
JavaScript が「最後の手段」に置かれている理由
Google 検索は、クロールが完了したあとに Web Rendering Service を使って JavaScript を解釈・実行します。処理の流れは、クロール、レンダリング（描画）、インデックス登録の順です。
サーバー側の転送との差はここにあります。HTTPの転送はページを取りに行った時点で返ってくる。JavaScriptの転送は、ページを取り終えてから描画の処理を経て、はじめて見つかります。公式ドキュメントには、レンダリングを待っている状態があることも書かれています。
だから、反映までに時間差が出ることがあります。急ぎの移転ほど、上の段の手段を探す価値があります。
robots.txt で旧サイトを塞ぐと、転送そのものが読まれない
引っ越しのときに起きやすい取り違えがあります。「旧サイトを検索結果から早く消したい」と考えて、旧ブログを robots.txt でブロックしてしまうケースです。
公式ドキュメントの説明はこうです。Googlebot はクロールの待ち行列からURLを取り出すと、まずクロールが許可されているかを確認する。robots.txt を読み、そのURLが許可されていなければ、HTTPリクエスト自体を行わずにURLをスキップします。
ページを取りに来ないということは、そのページに書いた転送の指示も届かないということです。meta refresh も JavaScript も、HTMLの中身です。中身を読まれなければ働きません。
消したいなら、まず転送を伝える。塞ぐのはその後の話です。
実際の手順：無料ブログから独自ドメインへ引っ越す
公式ドキュメントは、サイト移転の準備として 旧URLと新URLの対応づけ、内部リンクの更新、新しいサイトマップの作成 を挙げています。サーバー側の転送が使えない場合も、この準備の部分は変わりません。順番に置き換えるとこうなります。
- 旧URLと新URLの対応表を作る。表計算ソフトに2列で並べるだけで足ります。ここを飛ばすと、転送先を1つのトップページにまとめてしまいがちです。記事は記事へ、1対1で対応させてください。
- 新サイト側の内部リンクを新URLに更新する。記事を移すときに本文中のリンクが旧ドメインを向いたままになっていることがあります。移行元の記事から本文をコピーした場合は特に見落とします。
- 新しいサイトマップを作る。新URLの一覧をGoogleに渡す側の準備です。
- 旧記事に転送を入れる。
<head>を編集できるなら待ち時間0秒の meta refresh。編集できないなら、本文に置ける JavaScript による転送を最後の手段として使います。記事数が多いときは、下書き保存して1本で試してから残りに展開すると、取り返しがつきます。 - 転送をテストする。公式ドキュメントは、URLを個別にテストする手段として URL 検査ツール（Search Console の機能）を挙げています。対応表の中から、アクセスの多かった記事を数本選んで確かめてください。
もう一つ、公式が移転の項目として挙げているものがあります。新サイトを早くインデックスさせないために noindex（検索結果に出さないための指定）を入れていた場合、それを外し忘れないこと。準備段階で入れた指定が残っていると、転送は効いているのに新URLが検索結果に出てこない状態になります。
補助として、旧ドメインを site: で検索し、旧URLがまだ検索結果に残っているかを目で見て追う方法もあります。ただしこれは大まかな目安です。個別の判定は URL 検査ツールの結果を見てください。
自分のケースを当てはめる
| 確認すること | はい | いいえ |
|---|---|---|
| サービスに転送機能や独自ドメイン移行機能があるか | それを使う | 次へ |
<head> を編集できるか | 待ち時間0秒の meta refresh | 次へ |
| 記事本文にスクリプトを置けるか | JavaScript による転送（最後の手段） | 次へ |
| 旧記事を編集できないか | 転送は諦め、新サイト側の整備に寄せる | — |
一つめは、意外と見落とされます。無料ブログでも、独自ドメインへの移行メニューを持っているサービスがあります。二つめの <head> 編集は、テンプレート編集権限の有無で決まることが多い。三つめまで下りたら、それが最後の段だという前提で、反映を長めに見ておくのが現実的です。
四つめまで来た場合、旧記事をそのまま残すか消すかで迷うと思います。同じ本文が2か所に残った状態は、こちらの意図どおりに扱われるとは限りません。新サイトの方を出したいなら、旧記事の本文を短い案内文に差し替えて新URLへのリンクだけを残す、という形にできることがあります。この判断は、旧サービスでどこまで編集できるかによります。
転送を入れたあとに見るもの
転送は入れて終わりではありません。旧URLへのアクセスが新URLに届いているか、新URLがインデックスされ始めているかを、しばらく見続ける必要があります。Wemiro は Search Console と GA4 のデータをつないで見せる仕組みなので、移転の前後で「どのページが検索から入られていたか」を並べて確認する用途に使えます。
どの手段を選んだかで、見るべき時間の幅は変わります。サーバー側の転送より、JavaScript による転送のほうが、腰を据えて待つ心づもりが要ります。
301と302のどちらを使うかで迷ったときは301と302の使い分けは検索結果に残すURLで決めるを、サーバー側を触れるリニューアルの全体像はサイト移転でURLが変わるときの301リダイレクト手順を合わせて読んでください。
出典