【URL】wwwあり/なしURLの統一、どうしてる？ curlで探る政府サイトのリダイレクト設定なのだ

デジタル庁は理想的、総務省は…？ wwwリダイレクト設定から見る各省庁サイトの現状

きっかけ：総務省サイトの分かりにくいURL

最初のきっかけは、総務省の英語資料から日本語版を探そうとしたことだったのだ。

• 英語版: .../eng/WP2019/chapter-1.pdf

• 日本語版: .../ja/r01/pdf/n1100000.pdf

年号表記（WP2019 vs r01）とファイル名（chapter-1.pdf vs n1100000.pdf）がバラバラで、片方のURLからもう片方を推測することが不可能だったのだ（一貫性の欠如）。

このURL設計は、ユーザーにとって非常に不親切な例だと思ったのだ。

参考：詳しくは前回の記事にあるのだ
https://zenn.dev/hamuziro/articles/1fe31e16c434ce

そこでやっぱり気になる他の部分のURL設計

Websiteの基本的な「おもてなし」である、wwwなしのURLからwwwありのURLへの転送（リダイレクト）設定を興味本位から調査してみることにしたのだ^[1]。

MDN Web Docs は、どちらか一方を「canonical（正規）」と定め、もう一方から HTTP 301 リダイレクトを設定して正規 URL へ常に誘導する手法を推奨している。

検証方法

今回の検証では、curl -I コマンド^[2][3]をつかうのだ。

例：

curl -I https://example.com/

このコマンドで、wwwなしのURLにアクセスした時のサーバーの応答（ステータスコード）を確認していくのだ。

検証前にどんなステータスコード^[4]が期待されるか調べておくのだ。

200 OK

• これは「アクセス成功」を意味するのだ。

• しかし、wwwありとwwwなしの両方が200を返すと、同じ内容のページが2つの住所に存在することになり、検索エンジンの評価が分散してしまう可能性があるのだ。

301 Moved Permanently

• これがベストプラクティス^[5]と言われているのだ。
• 「恒久的に引っ越しました」という意味で、wwwなしのURLが持つ評価を、すべてwwwありのURLに引き継いでくれるのだ。
• ユーザーにも検索エンジンにも最も親切な設定なのだ。

302 Found

• これは「一時的に見つかりました」という意味なのだ。
• ユーザーは転送されるけれど、検索エンジンは「元の住所もまだ使うんだな」と判断してしまうため、恒久的なwwwの統一には不向きなのだ。

接続拒否や 404 Not Found

• これは「サーバーが見つからない」または「ページが存在しない」という意味で、ユーザーを迷わせてしまう最悪のパターンなのだ。

なお、wwwありのURLは当然200が返ってくることを期待しているので今回の調査記録には特に理由がなければ残さないのだ。

調査：各サイトの対応

総務省 (soumu.go.jp)

curl -I https://soumu.go.jp/

curl: (6) Could not resolve host: soumu.go.jp

wwwなしのURLにアクセスすると、転送するどころか接続自体ができなかったのだ。

これはユーザーを迷わせてしまう、最も避けるべき設定の例なのだ..。

最初から幸先が悪いけれど元々URLパス周りの設計も疑問があったので仕方なし（？）なのだ。

結果: 不親切な設定（接続拒否）

首相官邸 (kantei.go.jp)

気持ち切り替えて次に首相官邸のHPをみてみることにしたのだ。

curl -I https://kantei.go.jp/

HTTP/2 302 
server: CloudFront
date: Sun, 13 Jul 2025 18:20:29 GMT
content-length: 0
location: https://www.kantei.go.jp/
...

転送はしてくれるものの、その方法が「一時的な（302）」転送だったのだ。

ユーザー体験としては問題ないけれど、恒久的な設定としては301を使うのが望ましく、少しだけ改善の余地があるのだ。

結果: 少し惜しい設定 (302)

デジタル庁 (digital.go.jp)

curl -I https://digital.go.jp/
HTTP/2 301 
date: Sun, 13 Jul 2025 19:18:43 GMT
content-type: text/html
location: https://www.digital.go.jp/
...

wwwなしにアクセスすると、「恒久的に（301）」wwwありの正しいURLへ転送してくれたのだ。
これはユーザーにも検索エンジンにも最も親切で、ウェブのベストプラクティスと言えるのだ^[6]。

結果: 理想的な設定 (301)

スウェーデン政府(government.se)

wwwなしのURLで応答確認

curl -I https://government.se/

HTTP/2 403 
date: Sun, 13 Jul 2025 20:33:27 GMT
...
server: cloudflare

wwwありのURLでも応答確認してみるのだ

curl -I https://www.government.se/
HTTP/2 403 
date: Sun, 13 Jul 2025 20:49:59 GMT
...
server: cloudflare

スウェーデン政府^[7]のサイトの調査は予想に反して複雑だったのだ。

まず、curlでアクセスすると、Cloudflareのセキュリティ設定^[8]によって（？）403 Forbidden（アクセス拒否）が返され、サーバーの本当の挙動を確認できなかったのだ。

そこでブラウザで直接確認したところ、wwwあり・なしのどちらのURLもリダイレクトされず、それぞれ200 OKでページが表示されることが判明したのだ^[9]。

wwwありのページとwwwありのページ両方アクセスできる状態なのでもうちょっと状況を調査してみることにした。どうも、webページのソースコードの中に rel="canonical"タグを設定していればそこで「このページの正式なURLは https://www.government.se/ ですよ」みたく宣言できるそうだからだ。

https://developer.mozilla.org/en-US/docs/Web/URI/Guides/Choosing_between_www_and_non-www_URLs#using_link_relcanonical

しかしソースコードを確認した結果は、wwwありのページはwwwありのURLを、wwwなしのページはwwwなしのURLを、それぞれ「canonical（正規）」として宣言するrel="canonical"タグを設定していたのだ。

これは意図的に重複コンテンツを作り出してしまうため、SEOの観点からは「欠陥のある設計」と言えるのだ。

任天堂 (nintendo.com)

..以上、行政の website を中心とした調査結果だったけれど、最後に行政ではなく民間のサービスを見てみようと思うのだ。

ということで、任天堂^[10]の公式サイトで検証してみるのだ。

curl -I https://nintendo.com/jp/index.html

HTTP/1.1 301 Moved Permanently
Date: Sun, 13 Jul 2025 18:43:11 GMT
Server: Apache/2.4.62
Location: https://www.nintendo.com/jp/index.html
...

流石なのだ。

結果: 理想的な設定 (301)

調査結果

サイト名	wwwなしURLの挙動	評価
総務省	接続拒否	不親切
首相官邸	302 (一時的な転送)	△ 少し惜しい
デジタル庁	301 (恒久的な転送)	◎ 理想的
スウェーデン政府	自己参照Canonical (重複)	SEO的に欠陥あり
任天堂	301 (恒久的な転送)	◎ 理想的

P.S.

記事を投稿してから「おや。ZennはwwwなしのパターンのURLを使っているのだ。」と気付いたので、試しにwwwありのほうのURLをcurlで検証してみたのだ。

curl -I https://www.zenn.dev/ 
curl: (6) Could not resolve host: www.zenn.dev

おや..。期待と違ったのだ。

ということで追加で他サービス Quiota でも検証してみたのだ。
quiotaも www なしの URL を使っていることが今回わかったのだ（覚えやすいメリットはあるのだ）。

% curl -I https://www.quiota.com/
HTTP/2 301 
content-type: text/html; charset=UTF-8
location: https://quiota.com/
...

こちらは期待通り https://quiota.com/ にリダイレクトされているし status code も 301 なのだ。

念の為..他のサイトも検証してみよう、、ということで最近話題の Anthropic 社のHP（ https://www.anthropic.com/ ） で検証してみたのだ。

% curl -I https://anthropic.com/ 
HTTP/2 302 
date: Sun, 13 Jul 2025 22:51:08 GMT
content-type: text/html
content-length: 143
location: https://www.anthropic.com/

wwwありのURLにリダイレクト設定はされているものの status code は 302 だったのだ。

こちらもちょっと予想外。

じゃあ最後に..お世話になっている React のサイト（ https://react.dev/ ）でみてみることにしたのだ。wwwないパターンなのだ。

curl -I https://www.react.dev/
HTTP/2 308 
cache-control: public, max-age=0, must-revalidate
content-type: text/plain
date: Sun, 13 Jul 2025 22:57:22 GMT
location: https://react.dev/
...

わぁ..リダイレクト設定はこちらもされているけれど status code が 308。
ぼくこの status code はじめましてなのだ..。
また今度調べることにするのだ。
→ この status code 308 とは何なのかの記事はこちらなのだ
https://zenn.dev/hamuziro/articles/619b20edc79939

脚注

1. 現代においてwwwあるなしは好みの問題。なので、wwwがないURLでも問題はない。ただしSEO的には統一した方がいいと言われ、どちらか一方のURLを正規URLとし、片方を正規の方にリダイレクトする設計が多い。なお、SEOの観点ではサブドメインの www の有無はどっちかに統一さえされていれば関係ないが、CDNの観点では www ありの方がよさそうなのだ（参考：WWW vs. Non-WWW URL | Which One Is Better for SEO? ）

2. レスポンスヘッダーだけを表示して、本文（HTMLなど）は表示しないので見やすく、一方でリダイレクトをチェックできるのでステータスコードをチェックしたいときには便利なのだ。

3. ちなみにcurlのオプションは大文字小文字で異なる挙動をするのだ。歴史的にUNIX伝統のCLIツールに多いのだ。一方、モダンCLIでは「ぱっと見で意味がわかる」ように設計されているようなのだ。

4. 「先輩に学ぶ HTTP Status Code」というのを昔会社の人に教えてもらったのだ。他にもこの手のネタだと「告白に学ぶ HTTP Status Code」とかもあってとっても面白いのだ。

5. MDN Web Docs でも 301 のstatus codeが紹介されているのだ。

6. さすがと言えるところだけれど、デジタル庁の活動は他の省庁のURL設計にも生かされてこそ意味のある活動だと思うので頑張ってほしいのだ。

7. 去年、スウェーデンに数ヶ月滞在してから大好きになった彼らの行政サービス。スマホ一台でほとんどあらゆる行政手続きが終わるようにシステム設計されていてびっくりしたのだ。今回の調査結果は期待と反していたが調査記録は割愛せず乗せておくことにした。ちなみに、curlの開発者も Daniel Stenberg というスウェーデン在住の方なのだ！スウェーデンにまつわる話色々あるのでいつかまた記事にしたいのだ。

8. Cloudflareのセキュリティ設定として例えば Super Bot Fight Mode があり curl などからのリクエストをブロックできるそうなのだ（他にもWAF (Web Application Firewall)などの設定が考えられるかもしれないのだ）。参考：Super Bot Fight Mode blocking curl requests from web server and Facebook bots

9. curlが普通のブラウザのフリをするように、User-Agentを偽装してみたら（curl -I --user-agent "Mozilla/5.0 (..." https://government.se/）、ステータスコードは200 OKとなった。

10. さっきまでOvercooked 2というゲームをしていたのだ。ぼくは今一人でやってるのだけれど各ステージで４つめの星を集めることに今挑戦中なのだ。このゲームは学べることが多いのだ。例えば使ったものは元の場所に戻すのがいいとか。あとですぐ使うから..って側においておくと結局それが他の作業の邪魔をしてパフォーマンスが落ちるのだ。