UrlEdge
ブログに戻る
2026年5月17日 UrlEdge Editorial3 min read

www、apex、wildcard forwardingでSEOを壊さないための設計

host normalization は小さな設定に見えますが、apex、www、subdomain、path、query が別々に動くと redirect chain になります。canonical host を先に決めることが重要です。

apex、www、wildcard subdomain が canonical host にまとまる host normalization map

host normalization は DNS の小さな作業に見えます。ところが migration や rebrand で実トラフィックを扱うと、すぐ URL policy の問題になります。

ブランドは apex domain を使いたい。古い site は www を使っている。docs や campaign は subdomain にある。agency は wildcard forwarding を入れたい。広告リンクは path と UTM を保持したい。これらを別々に決めると、たいてい redirect chain ができます。

大事なのは www と apex のどちらが常に正しいかではありません。どの host を canonical にし、他の variant をどう従わせるかです。

大きな migration の一部なら、まず Website Migration Redirect Checklist を確認してください。この記事は host layer に絞ります。

host は URL policy の一部

example.jp、www.example.jp、*.example.jp は運用上同じではありません。

  • apex は marketing 上すっきり見えることがあります。
  • www は古い stack で自然な場合があります。
  • subdomain は product、docs、support、shop かもしれません。
  • wildcard は多くの host を同じ rule で扱うときに便利です。

重要なのは、これを偶然に任せないことです。

Host normalization map for apex, www, and wildcard subdomains

launch 前に canonical host を決める

早めに決めるべきこと:

QuestionWhy it matters
公開 site は apex か www かユーザーに見える canonical URL が決まる
どの subdomain が alias かすべてを統合してよいわけではない
path を保持するかSEO、bookmark、deep link に関わる
query string を保持するかUTM、coupon、ID が消えることがある
temporary exception があるかcampaign や launch は別 rule が必要な場合がある

ここが曖昧だと、複数の layer が同時に「親切な」redirect を追加します。

DNS だけでは足りない

DNS は traffic の向き先を決めます。表示される URL の変更までは決めません。

良い形:

http://www.old-brand.example/pricing?utm_source=email
  -> https://new-brand.example/pricing?utm_source=email

悪い形:

http://www.old-brand.example/pricing
  -> https://www.old-brand.example/pricing
  -> https://old-brand.example/pricing
  -> https://new-brand.example/pricing

1 hop のほうがテストしやすく、あとから説明もしやすいです。

wildcard forwarding は構造が残るときに効く

path 構造が大きく変わらないなら、wildcard rule は便利です。

old.example.jp/* -> new.example.jp/$1

向いているケース:

  • 旧 URL が大量にある
  • path 構造がほぼ同じ
  • 1ページずつ rule を書きたくない
  • 古い subdomain が alias として扱える

情報設計が大きく変わるなら、重要 URL は明示的に mapping するほうが安全です。

path と query を残す

host を変えるだけで、request の文脈を消してはいけません。

http://old.example.jp/docs/api?ref=partner&utm_source=newsletter

構造が合うなら、次のように終わるべきです。

https://new.example.jp/docs/api?ref=partner&utm_source=newsletter

これは次に効きます。

  • SEO page
  • documentation
  • paid campaign
  • affiliate link
  • bookmark

path や query が消えると、技術的には redirect していても価値が落ちます。

chain を避ける

よくある失敗:

  • HTTP to HTTPS が別 layer
  • www to apex が別 layer
  • domain migration が CDN や hosting
  • app が canonical rule を追加

結果は http -> https -> www -> final です。

今の stack がこの形なら、Redirect Chains and Loops も確認してください。

launch matrix をテストする

公開前に実際の variant を試します。

TestExample
Apex roothttps://example.jp/
www roothttps://www.example.jp/
Deep pathhttps://example.jp/pricing
Deep path with queryhttps://example.jp/pricing?utm_source=email
Old host with pathhttps://old.example.jp/blog/post-1
Wildcard subdomainhttps://docs.example.jp/guide

Launch QA matrix for canonical host, path preservation, query preservation, and redirect hops

確認すること:

  • final host が意図通り
  • path が残る
  • query が残る
  • status code が意図に合う
  • extra hop がない

UrlEdge が向いている場面

UrlEdge は、host normalization を server snippet ではなく routing policy として管理したいときに向いています。

canonical host、variant、path、query、status code を一箇所で扱えることが価値です。

FAQ

apex を常に使うべきですか？

いいえ。apex も www も使えます。重要なのは canonical host を選び、他の variant をきれいに従わせることです。

wildcard subdomain を1つの rule で扱えますか？

構造が揃っていれば可能です。大きく変わった場合は重要 URL を明示的に mapping します。

DNS だけで足りますか？

いいえ。DNS はユーザーに見える HTTP redirect policy の代替ではありません。

campaign parameter は残すべきですか？

通常は残すべきです。失った attribution を後から復元するのは難しいです。

参考

canonical host を一度で決める

root、www、wildcard subdomain を HTTPS、path preservation、query preservation と合わせて整理します。

Free Redirect Serviceを試す

関連記事

すべて見る