1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【SEO×開発】URL正規化(canonical・301)の要件定義

1
Posted at

SEO担当としてQiitaの自社メディア記事の作成を行なっています。

今回は、URLの正規化について、エンジニアのみなさんと認識を合わせておきたいポイントをまとめました。

SEOチームとエンジニアの皆さんがスムーズにやり取りできるよう、お互いに理解しておきたい仕様や、実装時につい見落としがちな注意点を共有できればと思います。

なお、本記事は2026年6月時点での勉強中の内容をもとにまとめています。専門的な部分はまだ学習中のため、誤りがある可能性があります。
今後も随時アップデートしていく予定ですので、参考としてお読みください。

はじめに:こんなことがありました

自社メディアにおいて、「/ドメイン/article(スラッシュなし)」と「/ドメイン/article/(スラッシュあり)」の両方のURLでページが表示されてしまう状態でした。

さらに、canonicalタグ(正規URLを示すタグ)が未設定だったため、GoogleがどちらのURLを本物として扱うか迷ってしまい、「同じ内容のページが複数存在している」としてSEO評価が分散してしまうリスクがありました。

エンジニアと事前にすり合わせたい「3つのポイント」

上記の依頼を進めるにあたり、「SEO側はこういう意図を持っているので、システム側でどう実現できそうか」をお互いにすり合わせておくと、開発がよりスムーズに進むポイントを3つご紹介します。

① 「canonical」だけでなく「301リダイレクト」もお願いしたい背景

エンジニア視点だと「canonicalタグを出力すればGoogleには伝わるので、リダイレクト処理(サーバー側の改修)までしなくても良いのでは?」と感じるケースもあるかもしれません。

しかし、SEOの観点では「物理的に1つのURLに統合する(301)」方がGoogleに意図が早く・強く伝わりやすいという事情があります。

canonicalはあくまでGoogleへのヒントに過ぎないため、できれば301リダイレクトで統合したい」という背景を伝えて相談してみるのがおすすめです。

参考

② 「パラメータ」を外すか残すかのルール決め

ここはSEOとシステム間で認識のズレが起きやすいポイントなので、丁寧にすり合わせをしておきたい部分です。

  • ?utm_source=X のような計測用パラメータは、中身の記事が変わらないので、パラメータを外したURLを canonical にしたい。
  • 一方で、?page=2(ページ送り)のように中身が変わるものは、パラメータ付きのURLのまま自己参照にしたい。

こういったSEO側の希望を伝えた上で、「今のシステム構成で、どのパラメータなら除外判定できそうか?」をエンジニアと一緒に検討していくと安心です。

③ サイトマップや内部リンクの統一

301やcanonicalを設定しても、サイト内のリンク(ヘッダーやフッター)や sitemap.xml に「スラッシュなし」の古いURLが残っていると、Googleが「どっちが重要なURLなんだ?」と迷う可能性があります。

そのため、「リダイレクト先」「canonicalのURL」「内部リンク」「サイトマップ」の4つのURL表記をしっかり揃えたい、というゴールを事前に一緒に握っておけると良いかと思います。

📋 【コピペ用】エンジニア依頼用テンプレート

以下は、この課題を解決(URL正規化)するためにエンジニアへ依頼するためのテンプレです。
Markdownでそのままコピーして使えます。

### 目的・背景(Why)
現状、URL正規化が未対応のため、以下の問題が発生しています。
* トレイリングスラッシュ(末尾の `/` )の「あり・なし」の両URLがステータス200で返される
* `canonical` タグが未設定のため、GoogleがどのURLを正規URLとして扱うか不定

これにより、同一コンテンツが複数URLで評価される「重複コンテンツ」のリスクがあるため、評価分散を防ぐ対策をご相談したいです。

### 実現したいこと(What)
SEOの評価を「スラッシュあり」のURLに統合するため、以下の対応をお願いできないでしょうか。

#### 1. 301リダイレクトによる統一
トレイリングスラッシュ「なし」のURLへアクセスされた場合、「あり」のURLへ301リダイレクトさせたいです。
(※その際、付与されているクエリパラメータは保持したままリダイレクトをお願いします)
* 例: `/ドメイン/●●●●●``/ドメイン/●●●●●/`
* 例: `/ドメイン/●●●●●?hoge=fuga``/ドメイン/●●●●●/?hoge=fuga`

#### 2. canonicalタグの出力設定
各ページの `<head>` 内に正規URLを示す `canonical` タグを出力したいです。

* **通常時(自己参照):**
  通常記事ページ、記事一覧ページ(ページネーション含む)は、自分自身のURL(スラッシュあり)を `canonical` に設定。
* **パラメータ付与時(非自己参照):**
  トラッキング等のパラメータ付きURL(例: `?hoge=fuga`)でアクセスされた場合、`canonical` にはパラメータを削除したURL(ベースURL)を指定。
  ※将来的に「絞り込みフィルタ」など、コンテンツの中身が変わるパラメータが登場した場合は、個別に仕様を相談させてください。

#### 3. 内部リンクとSitemap.xmlの書き換え
サイト内のナビゲーションや記事内リンク、および `sitemap.xml` に出力されるURLも、すべて「スラッシュあり」の形式に統一したいです。

### ゴール(Goals)
* [ ] スラッシュなしのURLにアクセスすると、スラッシュありに301リダイレクトされる
* [ ] すべてのページに意図した `canonical` タグが出力されている
* [ ] サイト内のリンクや `sitemap.xml` が「スラッシュあり」に置き換わっている

まとめ

今回の実装を通じて、「URL正規化(canonicalと301)」は、SEOの希望とシステムのルーティング設計が密接に絡む施策だと実感しました。

だからこそ、単に依頼を投げて終わるのではなく、「なぜパラメータを外したURLをcanonicalにしたいのか(SEO視点)」と「システム側でどうルーティングを制御するのが適切か(エンジニア視点)」を、事前にお互いが理解し、相談しながら進めることが何より大切だとわかりました。

この記事のテンプレートが、領域の異なるメンバー同士で実装方針をすり合わせる際の「たたき台」になれば幸いです。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?