古いサイトの問い合わせフォームが動かないときに確認したいポイント

長い年月が経過したウェブサイトでは、運営を続ける中でさまざまな不具合が表面化してきます。中でも利用者からの問い合わせ窓口となるメールフォームが機能しなくなるケースは非常に多く、開店休業状態に追い込まれた個人サイトや小規模なショップで散見されます。フレーム構造を採用した古いページや、文字コードが正しく解釈されないまま放置されているHTMLで構成されている場合、フォームの送信処理そのものがブラウザやサーバー側で拒否されてしまうことも珍しくありません。

問い合わせフォームが反応しないと、それまで顧客との接点として機能していた重要な導線が断たれてしまいます。新規案件の獲得機会を失うだけでなく、信頼性の低下にもつながるため、早めの対処が必要です。本稿では、レガシー環境下で発生しがちなフォーム障害の典型例を取り上げながら、ひとつずつ確認すべき項目と復旧への道筋を整理していきます。

フォームが機能しない主な原因を整理する

古いサイトに設置されたメールフォームが動作しないとき、最初に疑うべきはフォームタグそのものの記述ミスです。<form> 要素の action 属性が誤ったパスや空欄になっていると、送信ボタンを押しても何も起きないことがあります。同じく method 属性が get ではなく post に設定されているか、エンコード形式を示す enctype 属性が適切であるかも確認ポイントです。

次に注意したいのは、JavaScript を用いた送信制御です。古いサイトでは、よく使われるフレームワークが登場する前の時代に、外部ライブラリの読み込みや独自スクリプトでフォームの検証・送信を行う実装が多く見られました。そのスクリプトファイルがサーバーから消えていたり、相対パスが現在のディレクトリ構造と合っていなかったりすると、エラーで停止してしまいます。ブラウザの開発者ツールでコンソールメッセージを確認し、404 や構文エラーが出ていないかチェックするのが有効な手がかりになります。

さらに、CSS による見た目の調整が送信ボタンを覆い隠してしまい、クリックできない状態を作り出している例もあります。透明なレイヤーが上に重なっている、z-index の指定で表示順序が逆転しているといったケースでは、本人は問題なく動作しているつもりでも、利用者側では何の反応も起きないという現象が発生します。

文字コードとHTMLの構造を見直す

レガシーサイトでは、文字コードの不一致が大きな障害要因になります。HTML ファイルが Shift_JIS や EUC-JP で保存されているにもかかわらず、サーバーから送信される HTTP ヘッダで UTF-8 が宣言されている、あるいはその逆の組み合わせになっていると、フォーム内のテキストは文字化けを起こし、最悪の場合は送信処理そのものがサーバー側で破棄されることもあります。<meta charset="..."> タグとサーバー設定が一致しているか、両方を揃えて確認することが大切です。

フレーム構造を採用しているサイトでは、親フレームと子フレームの文字コードが異なることも珍しくありません。親ページが Shift_JIS のまま放置されているのに子ページだけ UTF-8 に移行した結果、フォームの値が正しく受け渡されないといった不具合が報告されています。フレームを解除し、単一ページで表示してテストするだけでも、現象の切り分けが進みます。

フォーム内の隠し項目や確認画面を経由する仕組みが、HTML の構文エラーで正しく動作しないケースもあります。タグの閉じ忘れや属性値の引用符不足は、最近のブラウザでは自動で補正されることが多いものの、古いブラウザや特定の端末では致命的です。HTML バリデータで構文を点検し、必要であれば doctype 宣言から最新の標準に沿った形へ書き直すことを検討してください。

送信先メールアドレスの設定を確認する

フォームの見た目や文字コードが正常に見えても、肝心の送信先が機能していなければ問い合わせは届きません。古いサイトでは、<form action="mailto:..."> のような仕組みで直接メーラーを起動させる方式が取られていることがありますが、現在主要なブラウザーではこの挙動が制限されており、利用者の環境に大きく依存してしまいます。mailto リンクは補助的な手段と考え、サーバーサイドの送信処理へ移行するのが望ましいです。

CGI や PHP といったサーバーサイドスクリプトを利用する実装の場合、スクリプト内で指定された送信先メールアドレスが現在も有効かどうかを確認する必要があります。プロバイダーのメールアドレスは、提供終了や仕様変更によって突然使えなくなることがあります。フリーメールへ自動転送する設定が解除されていたり、独自ドメインのメールが受信サーバーでブロックされていたりと、問題はさまざまです。別のアドレスからフォーム送信テストを行い、実際に受信できるまで何度も検証を繰り返してください。

また、迷惑メール対策で送信ドメインに SPF レコードや DKIM 署名が求められる時代になり、古いフォームがこれらの要件を満たしていないと、送信そのものが届かない事態も増えています。エラーメールが返ってこないため気付きにくいですが、送信先のメールサーバーで弾かれている可能性があります。その場合は、SPF レコードを追加するか、信頼できる SMTP リレーサービスを経由する方法を検討します。日本語フォント関連のトラブルが並行して発生している場合は、フォント再インストールの解説のような周辺情報も合わせて確認すると、根本原因の特定につながることがあります。

サーバー側の処理とメール送信プログラムを検証する

フォームからのデータを受け取るスクリプトが、現代のサーバー環境でそのまま動くとは限りません。古い CGI スクリプトは Perl のバージョンが上がると動作しなくなることがあり、PHP 製フォームも PHP 7 から 8 へのメジャーアップデートで互換性の問題が出ています。エラーメッセージを画面に出す設定にしている場合は、ログから該当箇所を特定し、必要であれば関数名や引数の仕様を新しいものに書き換えます。

本番環境で詳細なエラーを表示させるとセキュリティ上の懸念があるため、error_log などのサーバーログを活用するのが一般的です。フォーム送信時にログへエラーが出力されているかを確認することで、スクリプト内で何が起きているのか把握できます。ディレクトリのパーミッションも忘れてはならない要素で、CGI スクリプトや書き出し用ディレクトリが適切な実行権を持っていないと、フォーム送信は拒否されます。

フォームに入力された内容を保存するデータベースがある場合、接続情報の不整合もよく見られる障害です。MySQL のバージョンが変わってソケットファイルの場所が変わったり、パスワードポリシーが厳しくなったりしたことで、以前は動いていた接続処理が失敗することがあります。設定ファイル内の接続文字列、ホスト名、ポート番号が現在の環境と合っているか、今一度入念にチェックしてください。対処に不安がある場合は、redwoow.comのような制作会社の支援ページを参考にしながら、専門家に見てもらうのも有効です。

外部サービスへの置き換えも選択肢に入れる

上記の確認項目をひと通り試しても復旧が難しい場合、思い切って問い合わせフォームだけを外部のサービスへ移行する選択肢があります。Google フォームや問い合わせフォーム作成サービスは、サーバーの改修を伴わずとも設置できるほか、初期費用や月額コストを抑えて導入できる利点があります。古いフレームベースのサイトでも、インラインフレームや単独の HTML ファイルとして埋め込めるため、既存サイトの大規模な改修を避けることができます。

移行時は、フォーム名からラベル、必須項目にいたるまで今まで収集していた項目をそのまま引き継ぐことが大切です。メールアドレスだけでなく、氏名や問い合わせ内容、案件種別といった項目は業務フローに組み込まれているため、欠落すると運用に影響が出ます。自動返信メールの仕組みや管理者への通知設定も同等に機能するよう、新しいサービス側で一つずつ設定し直してください。

CSS や JavaScript が多用される最近のサービスでは、古いブラウザでの互換性が問題になることもあります。サービス提供側が推奨環境を示している場合はそれに従い、Internet Explorer の延長サポート終了後は Microsoft Edge や Chrome といった現代的なブラウザの利用を案内するのも一案です。移行完了後は、実際に複数の端末やブラウザから送信テストを行い、すべての経路で正常に届くことを確認してから公開するようにしてください。

長い間放置されていたサイトのフォームを復活させるには、原因の切り分けと段階的な対処が欠かせません。文字コード、HTML 構造、送信先、サーバー処理と順を追って確認し、それでも解決しなければ外部サービスへの切り替えも視野に入れることで、利用者との大切な接線を守ることができます。焦らずひとつずつ確かめながら、利用しやすい問い合わせ窓口を取り戻してください。