URL設計は現状把握から始まる

URL設計というと、「どのURLにするか」という話に見えます。

しかし実際のリニューアルでは、その前に行うべきことがあります。それは、現在どのようなURLが存在しているのかを把握することです。

私たちはリニューアルの初期段階で、Google Search ConsoleやScreaming Frogなどを利用し、現在のサイトの状態を調査します。

URL設計は、新しいURLを決める作業ではありません。現在のサイトがどのような状態になっているのかを理解するところから始まります。

Google Search Consoleで確認すること

Google Search Consoleでは、検索エンジンから見たサイトの状態を確認できます。

• クロール済み - インデックス未登録
• 重複しています
• リダイレクトがあります
• 404
• canonicalが選択されていない
• sitemap送信状況

リニューアル前にこれらを確認することで、現在のサイトが抱えている問題を把握できます。

また、リニューアル後にも継続的に確認することで、新サイトの状態を監視することができます。

Screaming Frogで確認すること

Screaming Frogでは、サイト内のURLを一覧化できます。

• ページ数
• タイトル
• メタディスクリプション
• canonical
• noindex
• ステータスコード

また、存在しないURL、重複URL、リダイレクトチェーン、孤立ページなども発見できます。

リニューアル前には、現在どのURLが存在し、どのURLを引き継ぐべきなのかを整理するために利用します。

よくあるURLの問題

実際のサイトでは、想定していないURLが大量に存在することがあります。

ページャー

/news/page/2/、/news/page/3/、/news/page/4/ のようなページャーURLです。

タグ・タクソノミー

/tag/seo/、/tag/system/、/category/news/ などから大量の一覧ページが生成されることがあります。

これらが検索ユーザーにとって価値のあるページなのか、単なる重複ページなのかを判断する必要があります。

場合によっては、noindex、canonical、サイトマップ除外などの対応を行います。

検索結果ページ

/?s=wordpress のような検索結果ページです。

パラメータURL

/news?id=123 や /news?id=123&utm_source=xxx などです。

これらが適切に整理されていないと、検索エンジンは不要なURLまでクロールすることになります。

noindex・canonical・robots.txt・sitemap.xml

URL設計では、これらを個別ではなく、セットで考える必要があります。

noindex

検索結果へ表示させたくないページに利用します。

canonical

正規URLを指定します。

robots.txt

クロール自体を制御します。

sitemap.xml

検索エンジンへ重要なURLを伝えます。

noindexだけ、canonicalだけ、robots.txtだけではなく、サイト全体の設計として整合性を取ることが重要です。

クロールリソースを浪費しない

検索エンジンは無限にクロールしてくれるわけではありません。

不要なURLが大量に存在すると、本来クロールしてほしいページに十分なリソースが使われなくなることがあります。

• 不要なページャー
• 不要なタクソノミー
• 重複URL
• パラメータURL

そのため私たちは、検索エンジンがサイトを巡回するためのリソース、つまりクロールリソースの使い方も考慮しながらURL設計を行います。

URLを残す・統合する・削除する

リニューアル時には、すべてのURLを残すわけではありません。

残す

• 検索流入がある
• 重要ページ

統合する

• 内容が似ているページ
• 重複コンテンツ

削除する

• 存在価値がなくなったページ
• 古いキャンペーンページ

重要なのは、URL単位ではなく、コンテンツ単位で考えることです。

301・404・410の使い分け

リダイレクト設計では、301だけを使えばよいわけではありません。

301

新しいページへ引き継ぐ場合に利用します。

404

存在しない場合に利用します。

410

意図的に削除した場合に利用します。

リニューアル時には、どのページをどの状態にするのかを整理する必要があります。

Laravel構築時のリダイレクト設計

Laravelで構築する場合、リダイレクトは .htaccess だけではありません。Laravel側のルーティングを利用することもあります。

• 旧URLと新URLの対応表
• 旧IDから新URLへの変換
• カテゴリ変更による転送
• DBを利用した動的リダイレクト

ページ数が多いサイトでは、Laravel側で管理した方が運用しやすいケースもあります。

.htaccessとLaravelルーティングの使い分け

私たちは、どちらか一方を使うわけではありません。

.htaccess

• https統一
• www統一
• index.php除去
• 単純な301

Laravel

• 動的リダイレクト
• DB連携
• 条件分岐
• 旧URL対応表

重要なのは、どの層で処理するのが適切かを判断することです。

動的 sitemap.xml の設計

Laravelでは、sitemap.xml を動的に生成することもあります。

• 記事
• 実績
• カテゴリ
• 固定ページ

これらをDBから取得し、検索エンジンへ送信するURLを生成します。その際、noindexページ、canonical対象外ページ、非公開ページなどを除外します。

sitemap.xmlは単なるURL一覧ではありません。検索エンジンへ、「どのページを見てほしいか」を伝える重要なファイルです。

また、sitemap.xml、canonical、noindexは整合性が重要です。noindexページをサイトマップへ掲載したり、canonical先と異なるURLをサイトマップへ掲載したりすると、検索エンジンに誤ったシグナルを送ることがあります。

そのため、サイトマップだけでなく、サイト全体のURL設計との整合性を確認しながら設計します。

URL設計とデータ移行はセットで考える

URL設計は、データ移行とも密接に関係しています。

• 旧記事ID
• 新記事ID
• 旧URL
• 新URL
• カテゴリ

WordPressからLaravelへの移行や、CMS変更を伴うリニューアルでは、移行プログラムとURL対応表を連携して管理することがあります。

URLだけを後から整理しようとすると、データとの整合性が取れなくなるためです。

公開後もGoogle Search Consoleで確認する

URL設計やリダイレクト設定は、公開して終わりではありません。

公開後には、Google Search Consoleで次のような状態を確認します。

• 404
• リダイレクトあり
• 重複ページ
• canonical不一致
• クロール済み - インデックス未登録

必要に応じて、リダイレクト修正、canonical調整、sitemap更新、robots.txt調整を行います。

Flying High Worksの考え方

私たちはURL設計を、単なるSEO施策とは考えていません。

URLは、ユーザーがページへ到達する入口であり、検索エンジンがページを理解する手がかりであり、長年積み上げた資産であり、リニューアル後の運用基盤です。

リニューアルでは、新しいサイトを作ることだけではなく、今まで蓄積された評価や情報をどう引き継ぐかも重要です。

私たちは、Google Search Console、Screaming Frog、.htaccess、Laravelルーティング、sitemap.xml、canonical、robots.txtなどを組み合わせながら、サイト全体のURL設計を整理しています。

URL設計は目立つ作業ではありません。しかし、ここを丁寧に行うことで、リニューアル後の検索品質や運用安定性は大きく変わります。