wwwあり・なしを301で1つに統一する手順と決め方

example.com でも www.example.com でも、同じトップページが開く。しかも転送されずに、アドレスバーはそのままです。

この状態で罰を受けることはありません。困るのは、リンクの評価とクロールが2つのホストに分かれることです。直し方は単純で、残すほうを1つ決め、もう片方をサーバー側の301リダイレクト（恒久的な転送）で寄せます。

どちらを残すかは、SEOの優劣ではなく運用の都合で決めて構いません。決めたら、どの入口からも転送1回で着くかを curl で実測します。

両方開けても違反ではない。困るのは「分散」です

まず、焦らなくて大丈夫です。

Google 検索セントラルの「URL の正規化とは」は、サイト内にある程度の重複コンテンツがあるのは普通のことで、Google のスパムポリシー違反ではないと書いています。

ただし同じ内容が多くのURLから開ける状態には、2つの問題があるとも述べています。どれが正しいページなのか利用者が迷うこと。そして、検索でのコンテンツの成績を追いにくくなることです。

www の有無は、まさにこの「同じ内容が複数のURLから開ける」状態です。Search Console で片方のホストだけを見ていて、数字が合わない。そんな形で表に出ることがあります。

さらに「重複した URL を統合する」のドキュメントは、正規URL（重複の中から代表として扱うURL）を明示する理由として、次の2つを挙げています。

• 個々のURLが持つシグナル（そのURLへのリンクなど）を、1つの優先URLに統合しやすくする
• 重複版のクロールに時間を使わせず、新しいページや更新したページのクロールに回してもらう

また「URL の正規化とは」は、正規ページはもっとも定期的にクロールされ、重複ページはサイトへの負荷を減らすため低い頻度でクロールされる、と説明しています。

つまり放置した場合の損は、罰ではありません。評価とクロールが割れることです。

寄せる手段は301リダイレクトが本命です

正規化の伝え方は複数あります。「重複した URL を統合する」は、影響の強い順に次のように並べています。

同じドキュメントは、これらの手段は重ねると効果が高まるとも書いています。

既存の重複ページをなくしたいときは、リダイレクトを使う場面だとされています。恒久的なリダイレクトはどの方法でも Google 検索に対して同じ効果を持ちますが、検索エンジンが気づくまでの時間は方法によって違うことがある。最速なのはHTTP（サーバー側）のリダイレクトです。

ドキュメントの例には https://example.com/home・https://home.example.com・https://www.example.com が並びます。そして、そのうち1つを正規URLに選び、ほかはリダイレクトで寄せるよう書かれています。

301か302かも決めておきます。「リダイレクトと Google 検索」は、301と308は恒久的な移動を意味すると説明しています。検索結果に表示されるURLを変えたいなら、恒久的なサーバー側リダイレクトを推奨しています。

また「HTTP ステータス コード…が Google 検索に与える影響」によると、Google は301を「転送先を処理すべき」強いシグナルとして扱います。302は同じ意味の弱いシグナルです。www の統一は一時的な措置ではありません。だから301です。

どちらを残すか：SEOより運用の都合で決める

ここは迷いやすいところです。

抜粋した Google のドキュメントは「どれか1つを選んで、ほかを寄せる」と書くだけです。www ありとなしのどちらを選ぶべきかは書かれていません。なので、運用上の都合で決めて構いません。判断材料を表にまとめます。

上2行が埋まれば、たいていは決まります。下2行は、決め手が無いときの補助です。

手順：example.com に統一するまで

ここからは例として、残すホストを https://example.com（www なし・HTTPS）に決めたとします。

1. 今の状態を4通りで実測する。 http/https と www あり/なしの組み合わせを、curl -sI で1つずつ叩きます。ステータスコードと location ヘッダーを控えます。
2. 残すホストを決める。 前節の表で判断し、社内で1行の決定として残します。
3. サーバー側で301を設定する。 残す1通り以外のすべてを、1回の転送で残すホストへ送る設定にします（設定例は次節）。
4. サイト内の表記を残すホストに揃える。 rel="canonical"・サイトマップ・内部リンクの絶対URLを、すべて https://example.com/... にします。
5. もう一度4通りを実測する。 curl -sIL で転送を最後まで追い、どの入口からでも転送1回で 200 に着くことを確かめます。
6. Search Console で残すホストのURLを検査する。 転送元ではなく、残すほうのURLを検査します（理由は後述）。

手順1の実測は、たとえば次のようになります。

for u in http://example.com/ http://www.example.com/ https://example.com/ https://www.example.com/; do
  echo "== $u"
  curl -sI "$u" | grep -iE '^(HTTP|location)'
done

統一前のよくある結果は、4通りとも HTTP/2 200 が返るか、http から https へだけ転送されている状態です。後者は https://www.example.com/ が 200 のまま残ります。これが「両方開ける」の正体です。

統一後に期待する結果は次の表のとおりです。

ポイントは2行目です。http://www から https://www へ、さらに https://example.com へと2段で転送していないかを見ます。

設定例：転送を1回に収める

「リダイレクトと Google 検索」は、サーバーの設定ファイルを触れるなら、Apache なら .htaccess などのガイドに沿ってルールを書けると案内しています。以下は https://example.com に寄せる場合の一例です。環境に合わせて読み替えてください。

Apache（.htaccess、mod_rewrite が有効な場合）:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

HTTPS でない、または www で始まる、のどちらかに当てはまれば、パスを保ったまま一度で https://example.com へ送ります。HTTPS化の転送と www の転送を別々のルールに分けると、2段の転送になりがちです。

Nginx:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;
    # 証明書は www.example.com も含むものを指定する
    return 301 https://example.com$request_uri;
}

$request_uri でパスとクエリを引き継ぐので、https://www.example.com/blog/a?x=1 は https://example.com/blog/a?x=1 に着きます。トップページへまとめて飛ばすのは避けます。ページ単位の評価を寄せたいからです。

つまずきやすいところ

転送を何段も重ねる。 「HTTP ステータス コード…」によると、Google のクローラは既定で最大10回まで転送を追います。ただ、上限内なら放っておいてよい、という話ではありません。段数が増えるほど設定の見通しも悪くなります。手順5で、どの入口からも1回で着くことを確かめておくのが無難です。

www 側の証明書が無い。 残すのが www なしでも、https://www.example.com/ に来た人を転送するには、www を含む証明書が必要です。証明書が無いと、HTTPの応答より前にブラウザの警告で止まります。curl なら証明書エラーで失敗し、ステータスコードまで届きません。

転送元のURLを検査して戸惑う。 「HTTP ステータス コード…」は、Google の検査ツール（Google Inspection Tools）はリダイレクトを追わないと書いています。そのため転送元のURLを検査しても、転送先の中身までは確認できないことがあります。検査は残すホストのURLで行うのが確実です。

canonical だけで済ませる。 rel="canonical" も強いシグナルですが、www 付きのURLでもページは開いたままです。利用者が迷う状態も残ります。既存の重複をなくしたいなら、リダイレクトを本命にして canonical で補強する組み合わせが素直です。

着手前のチェックリスト

• 4通りの入口を curl -sI で実測し、結果を控えた
• 残すホストを決め、理由を1行で残した
• www を含む証明書が有効か確かめた
• 転送は301で、パスとクエリを引き継ぐ設定にした
• どの入口からも転送1回で 200 に着くことを curl -sIL で確かめた
• canonical・サイトマップ・内部リンクを残すホストのURLに揃えた

ホストの統一が済んだら、同じ考え方でURLの末尾も揃えておくと取りこぼしが減ります。URL末尾のスラッシュ有無を1つに統一する手順 は同じ実測の流れで書いています。301と302で迷ったときは 301と302の使い分け を参照してください。