---

存在しないURLが404ではなく500になる怪現象

親WordPressの転送ルール継承という盲点

まず最初に解明したのは、「なぜ削除した古いページや打ち間違いの URL にアクセスした時、通常の 404 Not Found ではなく 500 Internal Server Error が返っていたのか？」という謎です。

原因は、レンタルサーバーにおけるサブドメインの物理フォルダ配置にありました。たとえば親ドメイン（example.com）の直下で従来の WordPress が動いており、新しく作ったサブドメイン（lab.example.com 等）の公開フォルダがその配下のサブディレクトリ（public_html/lab.example.com/）に作られているケースです。

このとき、親フォルダ（public_html/.htaccess）には WordPress 定番の次の転送ルールが書かれています。

# 親ディレクトリ（WordPress側）にある定番ルール
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

もし子ディレクトリ（Astro 静的サイト側）に独自の RewriteEngine On を持たないまま放置すると、Apache の仕様によって 親ディレクトリの RewriteRule . /index.php [L] が子サイトにも継承 されます。すると、子サイト上で存在しない URL が叩かれた瞬間、「ファイルが無いなら /index.php へ内部転送せよ！ → しかし静的サイトだから index.php なんて存在しない！ → 存在しないからまた /index.php へ転送せよ！」という 無限内部リダイレクト（Internal Recursion Limit 超過） が発生し、Apache が強制ブレーキをかけて 500 Internal Server Error を吐き出していたのです。

子ディレクトリの.htaccessでループを断つ方法

解決策は驚くほどシンプルです。Astro プロジェクトの public/.htaccess（ビルド時にそのまま公開ルート直下へ出力されるファイル）に RewriteEngine On と ErrorDocument 404 /404.html を明記し、src/pages/404.astro で案内用のカスタム 404 ページを作っておくだけです。

Apache では、子ディレクトリ側で RewriteEngine On を宣言すると（RewriteOptions Inherit を明示しない限り）親ディレクトリの RewriteRule 継承がそこで完全に遮断 されます。これだけで、存在しない URL には正しく HTTP ステータス 404 が返り、500 ループは瞬時に消滅します。

---

mod_rewrite日本語リダイレクトの2大トラップ

%20の%2が消滅する後方参照バグと解決の鉄則

500 エラーを止めたら、次は旧記事スラッグや表記揺れしていた日本語カテゴリー URL（例：第01部：... → 第 1 部：...）を正規 URL へ 301 リダイレクトさせて検索評価を引き継ぎます。ところが、ここで多くのエンジニアが一度は徹夜する Apache mod_rewrite 最大の罠 に遭遇しました。

「URL に日本語や半角スペースが含まれるから、丁寧にパーセントエンコード（%20 や %E7%AC%AC...）して右辺に書こう！」と思って以下のように書くと、文字が無残に壊れます。

# 正解例：日本語と半角スペースを含む正規カテゴリーURLへの安全な301リダイレクト
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^categories/第\ *0?1\ *部(?:：|:).*$ "/categories/第 1 部：深掘り分析室/" [R=301,L]

ソフト404を防ぐ移転先ファイルの実在確認条件

さらに、ディレクトリ構造を整理した際（たとえば /blog/review/<slug>/ から /blog/review-old/<slug>/ へ過去記事を移動した際）、無条件にワイルドカードで転送してしまうと、「最初から存在しないデタラメな URL」まで移転先へ 301 転送された挙げ句に 404 になる（2 段ホップの悪質リダイレクトやソフト 404 判定） を招きます。

これを防ぐため、自動リダイレクトルールには必ず RewriteCond %{DOCUMENT_ROOT}/移転先/$1/index.html -f（移転先に本当に HTML 実体ファイルが存在する場合のみ 301 転送する） という実在ガード条件を付けました。

# 移転先に実体ファイル（index.html）が存在する場合のみ 301 転送し、無ければ素直に 404 へ落とす
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{DOCUMENT_ROOT}/blog/review-old/$1/index.html -f
RewriteRule ^blog/review/([a-zA-Z0-9_-]+)/?$ /blog/review-old/$1/ [R=301,L]

---

XPageSpeed解除とWebP1年キャッシュ最適化

重複URLを量産するXPageSpeedの落とし穴

続いて Search Console を汚していた 2 つ目の黒幕が、末尾に ?PageSpeed=noscript が付いた 400 件超の重複 URL でした。

これはエックスサーバーの高速化機能 「XPageSpeed」 を ON にしていると、サーバー側が配信時の全 HTML を自動書き換えし、<noscript> タグ内に ?PageSpeed=noscript 付きのリンクを勝手に埋め込むために発生します。すでに Astro 側で全画像を軽量な WebP 化し CSS も最小化している静的サイトにとって、XPageSpeed の HTML 書き換えは百害あって一利なしです。

ここで 絶対にやってはいけない注意点 があります。ネット上の古い記事を見て .htaccess に ModPagespeed Off と書き込むと、エックスサーバーでは許可されていないディレクティブのため 全ページが一瞬で 500 エラー になります！必ず エックスサーバーの「サーバーパネル」→「XPageSpeed設定」から OFF に切り替えてください。

そして、過去にクローラーが覚えてしまった ?PageSpeed=... 付き URL へのアクセスは、日本語パスでも文字化け（二重エンコード）しないよう %{THE_REQUEST} からエンコード済みパスだけを抜き出して正規 URL へ 301 統合します。

# 旧 XPageSpeed が生成した ?PageSpeed=... 付きURLを二重エンコードせず正規URLへ 301 統合
RewriteCond %{QUERY_STRING} (?:^|&)PageSpeed=[^&]* [NC]
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ (/[^\ ?]*)\?
RewriteRule ^ %1? [R=301,L,NE]

WebP1秒キャッシュ問題とnoindex競合の解消

Astro でビルドした画像や CSS・JS には /_astro/hero.BE5xhk39.webp のように 中身が変わると自動で変わるハッシュ値 が付きます。そのため、アセット類は思い切って 「1 年間キャッシュ（1 year）」 にし、逆に記事本文の HTML やサイトマップ・llms.txt はデプロイした瞬間にタイムラグゼロで切り替わるよう 「0 秒キャッシュ（0 seconds）」 に設定するのが最強の組み合わせです。

ファイル種別	mod_expires 設定値	狙いと効果
HTML・XML・TXT・JSON	access plus 0 seconds	記事を修正・公開した瞬間に、古いキャッシュが残らず 0 秒で最新内容が読者と AI に届く。
WebP画像・CSS・JS・フォント	access plus 1 year	ハッシュ付きファイルのため差し替え事故ゼロで 1 年間ブラウザキャッシュが効き、2 ページ目以降の遷移が瞬時に終わる。

最後に、Search Console 周りでもう 1 つ大切な仕上げを行いました。タグ一覧ページ（/tags/）など HTML 側に <meta name="robots" content="noindex, follow"> を入れているページに対して、robots.txt で Disallow: /tags/ を書いてブロックしてしまうと、Googlebot がページを開けず noindex タグを読み取れないため、いつまでも警告リストに残り続ける という競合が起きます。noindex を見せるページと、.htaccess で 301 正規化を通したい URL は、robots.txt で塞がずクローラーを通して正しく結果を伝えるのが鉄則です。

---

まとめ：レンタルサーバーの癖を知れば静的配信は無敵

専用クラウドではなく使い慣れた国内レンタルサーバー（Xserver 等）であっても、裏側の Apache とフロントエンドキャッシュの癖さえ正しく押さえれば、Astro 静的サイトは驚くほど堅牢かつ爆速に動いてくれます。

1. サブディレクトリ運用の子サイトには必ず独自の RewriteEngine On と ErrorDocument 404 を置き、親 WordPress のルール継承による 500 ループを遮断する
2. mod_rewrite で日本語 URL へ転送する際は %20 等を手書きせず、ダブルクォート囲み生 UTF-8 ＋ [R=301,L] でサーバー標準エスケープに任せる
3. 静的サイトでは「XPageSpeed」をサーバーパネルから OFF にし、mod_expires で「HTML は 0 秒即時反映・WebP や CSS は 1 年キャッシュ」へ最適化する

移行後の Search Console エラーでお困りの方は、ぜひ一度 .htaccess と通信ヘッダーを点検してみてください！