RESTとSEOの観点でURLについて考えてみた

はじめに

はじめまして。弁護士ドットコムの開発を行っているpoemnです。
普段はPHPを書いたりたまにJSを書いたりたまにHTMLを書いたりしています。
よろしければ昨日の@ug23さんのEC2と関連付けてざっくり理解するFargateもご覧ください。

本記事は 弁護士ドットコムアドベントカレンダー 24日目の記事です🎅

本記事ではRESTやSEOでの観点で、URLというものについて改めて考えた記事となります。
URL標準についてはURL Standard¹に詳細が記載されていますのでこの記事では割愛します。
また本記事でのSEOはGoogleが提示している内容について触れていきます。

パワーこそ力

プロダクトの開発で大事にすることはなんでしょうか。エンジニアが好き勝手にやりたい機能をやりたいように追加するだけではビジネスは成り立ちません。
Webサイトをより多くの人に見つけて使ってもらうためには、検索サイトでより上位の順位に表示するようにする必要があります。そこで考えるべきものがSearch Engine Optimization（検索エンジン最適化）です。

私はWebサービスを開発していく上で、検索順位が落ちてきたり多方面から降ってくる対応しなければならないものをパワーと呼んでいます。（別にDisってるわけじゃないです）
ビジネス的な事情はしばしば緊急性が高く考慮すべきことも多く、コードやその設計がパワーにより複雑に捻じ曲げられてしまうこともあります。
そんな中で、私たちがWebサービスを開発する上で避けることができないURLに焦点を当てて改めて見つめ直してみようとふと思ったので、本記事ではRESTとSEOという2つの観点で考えてみることにしました。

SEOの観点でのURL

SEOの観点で気をつけるべきことを、Search Engine Optimization (SEO) Starter Guide²からURLについて言及されている箇所を抜粋して紹介します。

• https://を使用することが望ましい
• wwwを含むバージョンとwwwを含まないバージョンのURLを別のものとして扱う
• パス、ファイル名、クエリ文字列大文字小文字が区別される
• ホスト名の後ろにある末尾のスラッシュは省略可能
  • ただし、パスとファイル名については、末尾のスラッシュによって別々の URL と見なされる
• コンテンツの情報を伝えるわかりやすいURLにする
  • URL で単語を使用する
• 不必要なパラメータやセッション ID を含む長い URL を使用しない
• 「page1.html」のような一般的なページ名を選ばない
• 「baseball-cards-baseball-cards-baseballcards.htm」のように過度にキーワードを使用しない。
• 「.../dir1/dir2/dir3/dir4/dir5/dir6/page.html」のようにサブカテゴリを深くネストしない。
• 含まれているコンテンツと関連のないディレクトリ名を使用しない
• ドキュメントに到達する URL のバージョンを 1 つにする
• PCとSPのURLを別々にすべきではない³

RESTの観点でのURL

RESTの観点でのURLについては長くなるので、別の記事にしました。URIに適用されるREST（翻訳）の記事をご覧ください。

Cool URIs don't change

1998年にTim Berners-LeeはCool URIs don't changeという文書を発表しています。

上記の記事でも、URLは永続的であるべきだといった内容が書かれています。またURLに除外すべきものについても言及されており、下記を列挙しています。

• Authors name
• Subject
• Status
• Access
• File name extension
• Software mechanisms

It is the the duty of a Webmaster to allocate URIs which you will be able to stand by in 2 years, in 20 years, in 200 years.

記事中にもある通り、URIが2年経っても、20年経っても、200年経ってもきちんと働くように設定することは、ウェブマスターの義務です。

結局何が言いたかったか

私自身かなり多くの記事でや本で、これがよいと言われているURLにはなんの根拠もないのではないかと疑っています。
実際にURLに /v1/ のようにバージョン番号を含めるのは良いのか、悪いのか。それは人間が見てどう思うか、きれいなURLであるかだけであり、本質的にはどうであるのか。

それを実際にUniform Resource IdentifierのRFC 3986の規定にも関わっているRoy T. Fieldingが発表しているRESTの論文を紐解くとどう見えるだろうかというのを本記事を書く上で考察しました。

SEOというビジネス要件を踏まえた上で、RESTの制約に従ったURLを決定することは競合することではありません。
どちらも正しく理解した上で、URLを決めていくことが大事です。

おわりに

世の中はもうクリスマスイブですね。イルミネーションでもなくクリスマスプレゼントでもなくケーキが食べたいな。できたらモンブランが食べたいな。なんて思いながらこの記事を書いています。

年末にしてはなかなかヘビーな話題に手を付けてしまった自覚もあまりまとまらなかった自覚もありますが、まぁいいでしょう。

つい先日にも、こんなやりとりがTwitterであっており在るべきURLの形については今も議論が続けられています。

って言われたのでじゃあクライアントが管理してるモーダル開閉やアニメーションのステップ管理を全部URLにぶち込んでやるよってクエリパラメータに突っ込んだらサーバーが認識できるURL長超えて動かなくなったことがある https://t.co/eJNqqOfvWr

— OSSタダ乗りおじさん (@mizchi) December 23, 2020

JSのないただのHTMLアプリですら、フォームの状態やフォーカス・スクロールバーの位置など状態は多岐にわたるのですべてURLとして表現できているわけではないのですよね。つまり何を「アプリケーション状態」として捉えるかが大事 https://t.co/3uZBohy5BP

— Toru KAWAMURA (@tkawa) December 23, 2020

明日はいよいよクリスマスですね🎅
最後は @xRx さんです！最後までお楽しみに！

1. URL Standard ↩

2. Search Engine Optimization (SEO) Starter Guide | Google 検索セントラル ↩

3. 別々の URL ↩