svgの記述が原因でさくらで500エラーが起きた話

ローカルで構築したワードプレスサイトを本番環境に展開する。
何のトラブルもなくすんなり行くケースの方が稀だと思います。

このサイトも例にもれず、初めてアップした瞬間から500エラーの嵐に見舞われ、すべて解決して無事に公開できたのは翌日でした。

しばらく.htaccessは見たくねえです

「500 Internal Server Error (内部サーバーエラー)」と言えば、サイトの根幹設定を構築する「.htaccess」ファイルや「php.cgi」ファイルなどに原因があることがほとんどで、「ワードプレスサイトの移行時によくあるエラー」を検索してみても「そのあたりの書き方を確認しましょう」と説明する記事がほとんど。

ですが、私のサイトでは思いもよらぬところに原因があったので、同じエラーで1日潰してしまう子羊が少しでも減るように記事を残しておきます。

犯人はSVG冒頭のXML宣言

php読み込みの指定文を書き換えてみても直らない。php.cgiから呼び出すパスを見直してみても直らない。ファイルのパーミッションも推奨のパターンを全部試した。WordPress内のパーマリンクを見直しても直らない。そもそもローカル(Xampp)上では問題なく表示できてる。

思いつく限り・調べられる限りのことを試して途方にくれる中、なにげなくサイト下層ページのリンクをいくつか叩いていたら、なぜか「500エラーが起きず表示できているページもある」ことが発覚しました。
サイトトップ（静的html）とワードプレスの記事詳細ページ（single.php）だけ500エラーが起きている。

上記2つのページの共通点は「SNSへのリンクを入れている」ことだったので、「もしかしてロゴのSVGファイル？」とアタリをつけ、消してみたらビンゴでした。

さらに検証したら、SNSロゴの中でも問題が起きるものと起きないものがある。正常なロゴとエラーの起きるロゴのソースを見比べます。

その結果、犯人はこいつでした。

<?xml version="1.0" encoding="utf-8"?>

お前ーーーッ！お前お前お前おｍ（ポプテピピック）

設定によってたまに冒頭に吐き出されるxml宣言の1行。自分でAiで作ったやつは宣言を吐き出さない設定にしていましたが、外部からダウンロードしてきたやつはスルーしていました。
これを解決すべくまた.htaccessと向き合ってもいいのですが、「version1.0」「utf-8」の組み合わせである限りは宣言は省略OKだったかと思いますので、サクッと切り取り。
その結果、無事に表示できました。

気づいたきっかけは「正常に表示できるページもあった」こと

今回のケースはさくらサーバーだけの話だった可能性もありますが、それでも今回得た「.htaccessやWordPress(php)以外でもサーバーエラーは起きることがある」という知見は財産です。

まさか画像ファイルで500エラー起きるなんて想像もしなかったです

もしあなたが今まさに500 Internal Server Errorと闘っていて、.htaccessやphp.cgi、php.iniあたりと睨めっこしているなら、気分転換にサイト内のURLをいくつか叩いてみてください。
もし「(正常な表示ではなかったとしても)エラーが起きずにリクエストできたページがある」のなら、それは大きなヒントです。

あなたのサイトが一刻も早く公開 or 復旧となりますように。