COLUMN
よく検索されるキーワード
2026/08/18
リニューアル・運用ノウハウrobots.txtとnoindexの違い｜検索に表示されない原因と正しい使い分け
robots.txtとnoindexの違い｜まず結論から理解しよう robots.txtとnoindexは、どちらも検索エンジンに関係する設定ですが、役割はまったく異なります。 最初に結論を整理すると、 robots.txt→ 検索エンジンのクローラーに「このURLをクロールしないで」と伝える noindex→ 検索エンジンに「このページを検索結果へ掲載しないで」と伝える という違いがあります。 Googleは、robots.txtについてクローラーがどのページやファイルをリクエストできるかを制御する仕組みとして案内しています。一方、noindexはページをGoogleのインデックスから除外し、検索結果に表示されないようにするためのルールです。 この違いを理解しないまま設定すると、 検索から消したかったのに残っている Googleに見てほしいページをブロックしてしまった noindexを設定したのに反映されない といったSEOトラブルにつながります。 そもそも「クロール」と「インデックス」は何が違う？ robots.txtとnoindexを理解するには、まずクロールとインデックスの違いを知っておく必要があります。 簡単に整理すると、 クロール→ Googlebotなどの検索エンジンがページを訪れて内容を取得すること インデックス→ 取得したページの内容をGoogleが解析し、検索結果に表示できる状態として登録すること です。 イメージすると、 Googleがページを見に来る＝クロール↓ページの内容を理解する↓検索データベースへ登録する＝インデックス↓検索結果に表示される可能性が生まれる という流れです。 robots.txtは最初の「クロール」に関係し、noindexは主に「インデックス」に関係します。 この違いが、今回の記事で最も重要なポイントです。 robots.txtとは？検索エンジンのクロールを制御するファイル robots.txtでできること robots.txtは、検索エンジンのクローラーに対して、サイト内のどのURLへアクセスしてよいか、またはアクセスしてほしくないかを伝えるためのテキストファイルです。 通常は、 https://example.com/robots.txt のように、サイトのルート直下へ設置します。 Googleもrobots.txtは対象ホストのルートに配置する必要があり、サブディレクトリ内に置いても有効にならないと案内しています。 例えば、 管理上クロールさせる必要がないURL サイト内検索結果など大量にURLが生成される領域 重要性の低い類似ページ などについて、クロールを制御する用途があります。 Googleはrobots.txtを、クロールトラフィックの管理や、重要性の低いページ・類似ページへのクロールを防ぐ用途として案内しています。 robots.txtでできないこと ここが非常に重要です。 robots.txtは「Google検索に表示しないための設定」ではありません。 Googleは、robots.txtでクロールを禁止したページであっても、他のページからそのURLがリンクされている場合などには、ページ内容をクロールせずURLだけをインデックスする可能性があると説明しています。 つまり、 robots.txtでブロック＝検索結果から必ず消える ではありません。 「検索結果に表示したくない」という目的なら、原則としてnoindexなど別の方法を検討します。 基本的な記述例 例えば、すべてのクローラーに対して/private-directory/以下へのクロールを許可しない場合、考え方としては次のようになります。 User-agent: * Disallow: /private-directory/ 一方、すべてのページをクロール可能にする場合は、特別な制限を設けない構成にします。 robots.txtは書き方を間違えると、サイト全体をクロールできなくしてしまう可能性があります。 そのため、「何となくSEO対策として設定する」ものではありません。 noindexとは？検索結果への掲載を防ぐための設定 noindexとは、検索エンジンに対して、 「このページを検索結果に表示しないでください」 と伝えるためのルールです。 Googlebotがページをクロールし、noindexを確認すると、そのページはGoogle検索結果から除外されます。 Googleは、他サイトからリンクされている場合でも、Googlebotがnoindexを検出すればGoogle検索結果から除外すると説明しています。 HTMLページでnoindexを設定する方法 代表的なのは、HTMLのrobots metaタグを使う方法です。 例えば、 <meta name="robots" content="noindex"> という設定です。 この設定によって、対応する検索エンジンへ「インデックスしない」という指示を出します。 WordPressなどのCMSでは、HTMLを直接編集しなくても、管理画面やSEO関連機能から設定できる場合があります。 PDFなどHTML以外ではX-Robots-Tagを使える PDFなど、HTMLの<head>内へmetaタグを設置できないファイルについては、HTTPレスポンスヘッダーのX-Robots-Tagを使ってnoindexを指定できます。 Googleも、PDF・動画・画像などHTML以外のリソースについてX-Robots-Tagを利用できると案内しています。 例えば、 営業資料PDF 過去資料 検索から見つけてもらう必要のないファイル などで検討するケースがあります。 noindexを設定してもすぐ消えるとは限らない noindexは設定した瞬間にGoogle検索からページを消すスイッチではありません。 Googlebotがそのページを再度クロールし、 「noindexが設定されている」 と認識する必要があります。 Googleは、ページの重要度などによって再クロールまで時間がかかる場合があり、必要に応じてSearch ConsoleのURL検査ツールから再クロールをリクエストできると説明しています。 そのため、 「昨日noindexを入れたのに、今日も検索結果に出ている」 からといって、必ず設定失敗とは限りません。 robots.txtとnoindexの決定的な違いを比較 項目robots.txtnoindex主な目的クロール制御インデックス制御Googlebotのアクセスブロックできるアクセスさせる必要がある検索結果から除外保証されないGooglebotが認識すれば除外主な設定場所ドメイン直下のrobots.txtmetaタグ／HTTPヘッダーページ単位の検索除外不向き適している機密情報の保護不向き不向き 特に覚えておきたいのは、 検索結果に表示させたくない＝noindexクロールそのものを制限したい＝robots.txt という基本です。 絶対に注意したい「robots.txt＋noindex」の組み合わせ 初心者の方が最も間違いやすいのが、この設定です。 「検索に出したくないから、robots.txtでブロックして、さらにnoindexも付けておこう」 一見すると二重に対策できて安全そうですが、逆効果になる可能性があります。 理由は、robots.txtでクロールをブロックすると、Googlebotがページへアクセスできなくなるからです。 Googlebotがページを開けなければ、ページ内にあるnoindexも確認できません。 Googleは明確に、noindexを機能させるにはrobots.txtでページをブロックせず、クローラーがアクセスできる状態にする必要があると案内しています。 つまり、 robots.txt：入るなnoindex：中に入ったら「検索に載せるな」と書いてある という状態になります。 入れないので、中の指示を読めません。 検索結果から除外したいページなら、 クロールを許可する↓Googlebotにnoindexを読ませる という流れが基本です。 目的別｜robots.txtとnoindexの正しい使い分け 検索結果に表示させたくないページ 例えば、 検索結果ページ ユーザーにとって検索流入させる必要のない完了ページ 一部の管理上必要な公開ページ など、公開状態ではあるもののGoogle検索には載せたくない場合は、noindexを検討します。 ただし「そのページを本当に検索から除外すべきか」は慎重に判断しましょう。 SEO上価値がないと思ってnoindexにしたページが、実は検索流入を持っていた、というケースもあります。 Googlebotのクロールを抑えたいページ 大量のURLが生成されるなど、Googlebotに積極的にクロールしてもらう必要がない領域ではrobots.txtを検討します。 Googleも、robots.txtをクロールトラフィックの管理などに利用できるとしています。 ただし、小規模な企業サイトで、 「SEOに良さそうだから、とりあえずrobots.txtで色々ブロックする」 必要はありません。 むしろ重要なCSS・JavaScriptやページを誤ってブロックするリスクに注意が必要です。 会員限定・社内限定・機密情報を守りたいページ これはrobots.txtでもnoindexでもありません。 ログイン認証やパスワード保護など、アクセス自体を制限する仕組みが必要です。 robots.txtは誰でも閲覧できるファイルであり、セキュリティ機能ではありません。 noindexも検索結果への掲載を制御するもので、URLを知っている人からページを守る機能ではありません。 Googleも、検索結果に出したくないページについて、必要に応じてパスワード保護などを利用するよう案内しています。 機密情報を守る目的でrobots.txtやnoindexだけを使うのはNGです。 テスト環境・ステージングサイト リニューアルで特に注意したいのが、制作中のテストサイトです。 テストサイトがGoogleにインデックスされると、 本番サイトとほぼ同じ内容が検索される 制作途中の情報が一般公開される 会社名検索でテストサイトが出る といった問題につながります。 テスト環境では、noindexだけに依存するのではなく、認証をかけて一般ユーザーや検索エンジンからアクセスできない状態にするのが安全です。 そして本番公開時には、認証・noindex・robots.txtなどのテスト用設定が残っていないか必ず確認します。 検索に表示されない時に確認すべきポイント noindexが残っていないか リニューアル後に検索へ出なくなった場合、最優先で確認したいのがnoindexです。 制作中に設定していたnoindexを、本番サイトでもそのまま残してしまう事故があります。 特に、 トップページ サービスページ ブログ・お知らせ 施工事例 採用ページ など重要ページのnoindexは致命的です。 robots.txtで重要ページをブロックしていないか robots.txtの設定ミスによって、重要なページ群をGooglebotがクロールできなくなっている可能性もあります。 例えば、 Disallow: / のような設定は、対象ユーザーエージェントに対してサイト全体へのクロールを禁止する意味になります。 制作環境用の設定を本番へそのまま移さないよう注意しましょう。 WordPressの検索エンジン表示設定を確認する WordPressでは管理画面に、検索エンジンがサイトをインデックスしないよう促すための設定があります。 制作中に有効にしていた場合、公開時の解除忘れに注意が必要です。 リニューアル公開時のチェックリストに、 「検索エンジン関連設定の確認」 を必ず入れておきましょう。 HTTPヘッダーのX-Robots-Tagを確認する HTMLを見てもnoindexが見つからないのに検索へ出ない場合、HTTPレスポンスヘッダーにX-Robots-Tagが設定されている可能性があります。 Googleでは、X-Robots-Tagでもnoindexなどのルールを指定できます。 特に、 PDF サーバー設定 .htaccess NGINX設定 などが関係する場合は、制作会社やエンジニアへ確認しましょう。 そもそもGoogleにクロールされているか noindexもrobots.txtも問題がないのに表示されない場合、 新しく公開したばかり 内部リンクがない XMLサイトマップに含まれていない GoogleがまだURLを発見していない など、別の理由も考えられます。 「検索に出ない＝noindex」と決めつけず、Search Consoleで状況を確認することが大切です。 リニューアル時に起こりやすいrobots.txt・noindex事故 テスト環境のnoindexを本番に残す 最も危険な事故の一つです。 デザインもフォームも正常なのに、検索流入だけが急激に落ちる可能性があります。 robots.txtでサイト全体をブロックしたまま公開する 制作中にクロールを抑える目的で設定し、そのまま本番公開するケースです。 公開前チェックで必ずrobots.txtを確認します。 noindexページをrobots.txtでもブロックする 先ほど説明した通り、Googlebotがnoindexを確認できなくなる可能性があります。 検索から外したいなら、Googlebotがnoindexを読み取れる状態にすることが必要です。 robots.txt内に「Noindex:」と書く robots.txtへnoindexを記述して検索結果から除外しようとする方法は、Googleではサポートされていません。 Googleは、noindexはmetaタグまたはHTTPレスポンスヘッダーで実装するよう案内しています。 インデックスさせたい重要ページまでnoindexにする カテゴリページやサービス詳細などを、「重複しそうだから」という理由だけでnoindexにするのも注意が必要です。 そのページがユーザーの検索意図に応えられるなら、検索流入の入口になる可能性があります。 noindexは、 「SEO評価が低そうだから」ではなく、「検索結果に存在する必要があるか」 で判断しましょう。 設定を確認する方法｜Search Consoleでチェックする robots.txtやnoindexの状態を確認する際は、Google Search Consoleを活用します。 特に便利なのがURL検査ツールです。 対象URLについて、 Googleにインデックスされているか クロールできているか noindexが検出されているか GoogleがどのURLを正規URLとして認識しているか などを確認できます。 Googleも、noindexが正しく実装されているか確認する方法としてURL検査ツールやページのインデックス登録レポートを案内しています。 robots.txtについても、Search Consoleのrobots.txtレポートなどを利用して公開済みファイルの問題を確認できます。 「設定したつもり」で終わらず、Googleから実際にどう見えているかを確認することが重要です。 robots.txt・noindexチェックリスト robots.txt robots.txtがドメインのルート直下にある 重要ページを誤ってDisallowしていない サイト全体を意図せずブロックしていない 制作環境用の設定が本番に残っていない 「検索から消す目的」でrobots.txtを使っていない robots.txtにNoindexルールを書いていない noindex 検索結果に必要なページへnoindexが付いていない noindexページをrobots.txtで同時にブロックしていない WordPress等の検索エンジン設定を確認している HTTPヘッダーのX-Robots-Tagも確認している noindex設定後、Search Consoleで認識状況を確認している リニューアル公開時 トップページをURL検査した 主要サービスページをURL検査した robots.txtを確認した noindexを全ページ横断で確認した XMLサイトマップを確認した 旧URL→新URLの301を確認した 公開後もSearch Consoleでインデックス状況を監視している まとめ：検索に出したくない＝robots.txtではない robots.txtとnoindexは似ているようで、役割が明確に違います。 robots.txt→ クロールを制御する noindex→ 検索結果へのインデックスを制御する そして最も注意したいのが、 robots.txtでクロールを止めると、Googlebotがnoindexを読めなくなる という点です。 Googleも、noindexを有効にするには、そのページをrobots.txtでブロックせずGooglebotがアクセスできる状態にする必要があると明記しています。 また、robots.txtもnoindexもセキュリティ機能ではありません。 社内限定・会員限定・機密情報など、本当に第三者へ見せたくない情報については、認証などアクセス自体を制限する仕組みが必要です。 特にサイトリニューアルでは、制作中の設定が本番へ残り、検索流入が失われる事故があります。 公開前には、 robots.txt noindex X-Robots-Tag Search Console XMLサイトマップ をセットで確認し、検索エンジンが正しくサイトをクロール・インデックスできる状態を整えましょう。 無料相談 Refuでは、リニューアル時のrobots.txt・noindex設定確認から、Search Consoleを使ったインデックス状況の調査、301リダイレクト、XMLサイトマップ、公開後のSEO監視まで一括で対応しています。 「リニューアル後に検索に出なくなった」「noindexが残っていないか確認したい」「Search Consoleにエラーが出ているけれど原因が分からない」 など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら Googleサーチコンソールの基本操作と改善への活かし方 301リダイレクト完全ガイド｜SEOを落とさずURL変更する手順と注意点 リニューアル後に検索順位が落ちた時の原因チェック｜最短で戻す改善手順 コンテンツ移行で失敗しないために｜旧サイト資産の棚卸しと移行判断基準 ホームページの404エラーとは？SEOへの影響と正しい対処法
2026/08/17
ホームページ制作の基本問い合わせフォームに迷惑メールが届く原因｜スパム対策と安全な運用方法
問い合わせフォームに迷惑メールが届くのはなぜ？ ホームページを運用していると、突然、 英語や外国語のメッセージ 意味のない文字列 大量のURLが記載された投稿 仮想通貨・SEO・営業サービスなどの宣伝 同じ内容が短時間に何十件も送られてくる といった迷惑メールが届くことがあります。 「メールアドレスが漏えいしたのでは？」 と心配になるかもしれませんが、問い合わせフォーム経由の迷惑メールの場合、必ずしもメールアドレスが流出しているとは限りません。 多くの場合は、Bot（自動プログラム）がWeb上のお問い合わせフォームを発見し、自動的に情報を送信していることが原因です。 現在のWebサービスでは、不正な自動アクセスを完全に一つの仕組みだけで防ぐのは難しく、OWASPもBot対策について、WAF・レート制限・行動判定・Honeypot・CAPTCHAなどを組み合わせた多層的な対策を推奨しています。 そのため、 「迷惑メールが来た＝サイトが乗っ取られた」 と判断するのではなく、まずはどこから送信されているのかを切り分けることが重要です。 まず確認｜「フォームスパム」と普通の迷惑メールは別物 迷惑メール対策を始める前に、まず確認したいのが、 「ホームページのフォーム経由なのか」 という点です。 フォームスパム ホームページの入力フォームをBotなどが自動送信し、その内容が管理者宛ての通知メールとして届いている状態です。 この場合は、 CAPTCHA・Bot対策 Honeypot 送信回数制限 WAF 入力チェック など、ホームページ側の対策が有効です。自動化された不正利用については、一つの防御だけではなく複数レイヤーを組み合わせることがOWASPでも推奨されています。 メールアドレスに直接届く迷惑メール 一方、 info@example.jp など、公開しているメールアドレスへ直接迷惑メールが送られている場合は、問い合わせフォームとは別問題です。 このケースではフォームにCAPTCHAを追加しても解決しません。 メールサーバー側の迷惑メールフィルターや、メールアドレスの公開方法などを確認する必要があります。 まずは、 「フォームから送信されたものなのか、メールアドレスへ直接届いているのか」 を確認しましょう。 問い合わせフォームが狙われる主な原因 問い合わせフォームへのスパムが増える理由には、いくつかあります。 誰でも送信できる公開フォームだから お問い合わせフォームは、基本的にログインせず誰でも利用できます。 正規ユーザーにとって便利である一方、Botから見てもアクセスしやすい場所です。 Bot対策が設定されていない フォームを設置しただけで、 CAPTCHA Honeypot レート制限 WAF などが設定されていない場合、自動送信を繰り返されやすくなります。 同じフォームへ短時間に何度でも送信できる 送信回数に制限がなければ、Botが同じフォームへ大量のリクエストを送ることができます。 OWASPはBot対策においてレート制限を基礎的な防御策の一つと位置付けています。 CMS・プラグインの管理が不十分 WordPressなどのCMSでは、お問い合わせフォームをプラグインで実装することが多くあります。 フォームや関連機能を長期間放置している場合は、スパム対策だけでなく、サイト全体の保守状況も確認した方が安全です。 迷惑メール対策で効果的な7つの方法 迷惑メールを減らすには、一つの対策に頼るのではなく、複数の方法を組み合わせることが重要です。 reCAPTCHA・TurnstileなどのBot対策を導入する 代表的なのが、 Google reCAPTCHA Cloudflare Turnstile などのBot判定サービスです。 GoogleのreCAPTCHA v3では、ユーザーに毎回画像認証をさせるのではなく、操作をスコアで評価し、リスクに応じた処理を行うことができます。 また、Cloudflare Turnstileは、通常のCAPTCHAのような画像選択を常に求めることなく、ユーザーやブラウザの状態からBot判定を行う仕組みを提供しています。 問い合わせフォームでは、 「Botを防ぎたいけれど、本物のお客様にはできるだけ手間をかけさせたくない」 というバランスが重要です。 そのため、サイトの利用者やフォームの重要度に合わせて適切な方式を選びましょう。 Honeypot（ハニーポット）を設置する Honeypotとは、通常のユーザーには見えない入力欄などを用意し、Botだけが入力した場合に送信を拒否する方法です。 人間には追加操作を求めないため、フォームの使いやすさを維持しやすいメリットがあります。 ただしHoneypotだけですべてのBotを防げるわけではありません。 OWASPも、HoneypotやCAPTCHA、レート制限などをアプリケーション層で組み合わせる方法を示しています。 Honeypot＋Bot判定＋送信制限 のように組み合わせる方が効果的です。 短時間の大量送信を制限する 同じ送信元から、 数秒間に何十件も問い合わせが届く のであれば、通常のユーザー行動とは考えにくいでしょう。 そこで有効なのがレート制限（Rate Limiting）です。 たとえば、 同一IPから一定時間内に送信できる回数を制限する フォームへの連続アクセスを制限する 異常な送信パターンを検知して一時的にブロックする といった対策があります。 OWASPもレート制限をBot対策の基礎的なコントロールとして挙げています。ただしIPだけに依存すると回避される可能性もあるため、複数のシグナルを組み合わせる考え方が重要です。 入力内容をサーバー側で検証する お問い合わせフォームでは、 メールアドレス 電話番号 郵便番号 選択項目 お問い合わせ内容 などに適切な入力ルールを設定します。 たとえば電話番号欄に大量のURLや異常に長い文字列が入力されている場合、通常の問い合わせとは考えにくいでしょう。 OWASPは入力値について、形式や長さなどを検証し、セキュリティ上のチェックはブラウザ側だけでなくサーバー側でも実施することを推奨しています。JavaScriptなどクライアント側だけのチェックは回避できるためです。 ポイントは、 「画面上で入力できないようにしたから安心」ではない ということです。 フォームの送信先へ直接リクエストされる可能性も考慮し、サーバー側で確認する必要があります。 WAF・Bot対策を活用する 大量の不正アクセスが続く場合には、フォームだけでなくサイト全体で対策する方法もあります。 代表的なのがWAF（Web Application Firewall）です。 WAFやCDNなどのエッジ側で、 不審なアクセス 異常な送信回数 Botらしい通信 特定条件に一致するリクエスト などを検知・制御します。 OWASPでも、CDN・WAF・Bot対策と、アプリケーション側のレート制限やCAPTCHA等を組み合わせる多層防御が示されています。 問い合わせフォームへのスパムが非常に多いサイトでは、フォーム単体ではなく、サイト全体のアクセス対策まで確認するとよいでしょう。 CMS・プラグインを最新状態に保つ WordPressなどを利用している場合は、 WordPress本体 フォームプラグイン テーマ その他のプラグイン を適切に管理します。 ただし、 「最新にすれば迷惑メールがゼロになる」 わけではありません。 アップデートはサイトを安全に運用するための基本であり、スパム対策とは分けて考えながら、両方を継続することが重要です。 更新前にはバックアップを取得し、更新後はフォーム送信まで正常に動くか確認しましょう。 特定ワードやURLによるフィルタリングは補助的に使う スパムに共通する、 特定の単語 特定ドメイン 大量のURL 不自然な文字列 などを検知して拒否する方法もあります。 ただし、 「この文字が入っていたら全部拒否」 という単純な設定は、正規のお客様までブロックする可能性があります。 OWASPも、禁止ワードだけを並べるようなDenylistだけに依存する方法は回避されやすく、補助的な対策として使うべきとしています。 キーワードフィルターは主役ではなく、CAPTCHA・レート制限などを補う目的で使いましょう。 「CAPTCHAを入れれば安心」ではない理由 問い合わせフォームにスパムが増えたとき、 「とりあえずCAPTCHAを付けよう」 となりがちですが、それだけでは十分とは限りません。 OWASPは、自動化対策について一つのコントロールだけに頼るのは脆弱であり、複数レイヤーを組み合わせるべきとしています。 さらに重要なのが、実装方法です。 たとえばCloudflare Turnstileでは、画面上にウィジェットを表示するだけでは不十分で、発行されたトークンをサーバー側で検証することが必須と公式ドキュメントに明記されています。 GoogleのreCAPTCHA v3でも、取得したスコアやアクションなどをバックエンド側で検証する仕組みになっています。 つまり、 「見た目上CAPTCHAが付いている」＝「正しく守られている」 とは限りません。 導入するときは、制作会社やエンジニアに、 「サーバー側の検証まで実装されていますか？」 と確認すると安心です。 正規ユーザーを取りこぼさないフォーム設計も重要 スパムを完全に止めることだけを考えて対策を強くしすぎると、本物のお客様まで問い合わせできなくなる可能性があります。 たとえば、 何度も画像認証を求められる 少し時間をかけただけで送信できなくなる 海外からのアクセスをすべて拒否する 特定単語が入っただけでエラーになる エラー理由が表示されない といったフォームでは、問い合わせ前にユーザーが離脱してしまいます。 OWASPも、視覚的なCAPTCHAを主たる防御策として過度に頼るのではなく、より負担の少ないリスク判定などと組み合わせる考え方を示しています。 フォーム対策で重要なのは、 「迷惑メールをゼロにすること」ではなく、正規ユーザーの利便性を維持しながら迷惑メールを実用上問題ないレベルまで減らすこと です。 対策後は必ず、 PC iPhone Android 異なるブラウザ などから実際にフォームを送信し、正常に問い合わせできるか確認しましょう。 迷惑メールが急増したときの確認手順 突然フォームスパムが増えた場合は、次の順番で確認すると原因を整理しやすくなります。 ステップ1：本当にフォーム経由か確認する 管理者通知メールの形式などから、ホームページのフォーム経由なのか確認します。 ステップ2：どのフォームから届いているか確認する 複数のフォームがある場合、 お問い合わせ 資料請求 採用応募 見積もり依頼 予約 のどこが狙われているかを確認します。 ステップ3：送信パターンを見る 次のような特徴を確認します。 同じ文章が繰り返されている URLが大量に含まれている 短時間に集中している 同じ送信元から繰り返されている 特定フォームだけ大量に送られている ステップ4：現在のBot対策を確認する reCAPTCHAはあるか Turnstileはあるか Honeypotはあるか レート制限はあるか WAFは有効か などを確認します。 ステップ5：正規フォームの送信テストを行う 対策を変更したら、必ず自分たちでフォーム送信を行います。 「スパムは止まったが、お客様からの問い合わせまで止まった」 という状態は避けなければなりません。 ステップ6：一定期間モニタリングする 対策後、 スパム件数 正常な問い合わせ件数 フォームエラー CAPTCHA・Bot判定の失敗状況 などを確認します。 Cloudflare Turnstileでもチャレンジや検証状況を分析する機能が提供されており、Bot対策は導入して終わりではなく、状況を見ながら調整する考え方が重要です。 WordPressのお問い合わせフォームで確認したいポイント WordPressサイトで迷惑メールが増えている場合は、最低限次を確認しましょう。 どのフォームプラグインを使っているか Bot対策機能が有効になっているか reCAPTCHAやTurnstileが正しく接続されているか Honeypotなどを追加できるか フォームプラグインが更新されているか WordPress本体・テーマも管理されているか サーバー側でWAFが利用できるか 大量送信を制限できるか 特に注意したいのが、 「以前CAPTCHAを入れたから大丈夫だと思っている」 というケースです。 APIキーや設定変更、プラグインの変更などによって正常に機能していない可能性もあるため、実際に現在のフォーム環境を確認しましょう。 また、CAPTCHA系サービスを新しく導入する場合は、利用するサービスの規約やデータの取り扱いを確認し、プライバシーポリシーへの記載が必要かもあわせて確認することをおすすめします。Bot判定ではサービスによってブラウザ情報などが利用されるため、プライバシー面も含めた選定が重要です。 問い合わせフォームのスパム対策チェックリスト 迷惑メールが増えてきたら、次の項目を確認してください。 フォーム経由のスパムか確認したか どのフォームが狙われているか特定したか reCAPTCHA・Turnstileなどを導入しているか Bot判定をサーバー側でも検証しているか Honeypotを利用できるか 同一送信元からの大量送信を制限しているか WAF・Bot対策を利用しているか 入力値をサーバー側でも検証しているか フォームプラグインを最新状態にしているか WordPress・CMS本体を適切に管理しているか キーワード拒否だけに頼っていないか 対策後にPC・スマートフォンから送信テストをしたか 正常な問い合わせまでブロックしていないか スパム件数を対策前後で比較しているか 導入サービスのプライバシー条件を確認したか すべてを一度に導入する必要はありません。 まずは、 Bot判定 → Honeypot → レート制限 → WAF・監視 というように、現在のスパム量やサイト規模に合わせて対策を追加していきましょう。 まとめ：一つの対策ではなく“多層防御”で守る 問い合わせフォームの迷惑メールは、ホームページを運用していれば発生する可能性があります。 重要なのは、 「迷惑メールが届いたから危険」 と慌てるのではなく、原因を切り分けて必要な対策を行うことです。 基本的な考え方は、 Bot判定を導入する Honeypotを組み合わせる 大量送信をレート制限する 入力内容をサーバー側でも検証する 必要に応じてWAFを活用する CMS・プラグインを適切に保守する 正規ユーザーが問い合わせできるか必ず確認する という流れです。 現在のBot対策では、一つの仕組みだけにすべてを任せるのではなく、複数の防御を組み合わせる「多層防御」が基本的な考え方です。 そして、もう一つ忘れてはいけないのが、 お問い合わせフォームは“守るため”だけでなく、“問い合わせを受けるため”に存在する ということです。 セキュリティを高めながらも、ユーザーに余計な負担をかけないフォームを目指しましょう。 無料相談 Refuでは、ホームページ制作だけでなく、既存サイトのお問い合わせフォーム確認、WordPress・プラグインの保守、Bot対策、WAFなども含めて運用環境を確認しています。 「突然迷惑メールが増えた」「CAPTCHAを入れているのにスパムが止まらない」「本物のお問い合わせまで止めてしまわないか不安」といった場合も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら SSL（https）って何？ホームページの信頼性とSEOに必須な理由 ホームページ公開後にやるべき初期設定10選｜最低限の運用準備チェック お問い合わせが増える導線設計｜CTA・ボタン・フォーム最適化の基本 ホームページの保守・更新費用の相場｜何が含まれて何が別料金？ ホームページの表示速度を改善する方法｜Core Web Vitalsと画像最適化の基本
2026/08/11
リニューアル・運用ノウハウCore Web Vitalsの改善方法｜LCP・INP・CLSを初心者向けに解説
Core Web Vitalsとは？ホームページの「使いやすさ」を測る3つの指標 Core Web Vitals（コアウェブバイタル）とは、Webページを利用したユーザーが感じる読み込み速度・操作への反応・表示の安定性を測るための指標です。 現在のCore Web Vitalsは、次の3つで構成されています。 LCP（Largest Contentful Paint）→ メインコンテンツがどれくらい早く表示されるか INP（Interaction to Next Paint）→ クリックやタップなどの操作にどれくらい早く反応するか CLS（Cumulative Layout Shift）→ ページ表示中にレイアウトがどれくらいズレるか つまりCore Web Vitalsは、単純な「ページの速さ」だけを見る指標ではありません。 表示されるまで待たされないかボタンを押したのに反応しない状態にならないか読んでいる途中で文字やボタンが突然動かないか といった、実際のユーザー体験を数値化する考え方です。Googleも、Core Web Vitalsを実際のユーザー体験を測定する指標として位置づけています。 Core Web VitalsはSEOにどこまで影響する？ Core Web Vitalsについて、「数値を改善すれば検索順位が上がる」と考えている方もいます。 しかし、これは少し違います。 GoogleはCore Web Vitalsを、検索ランキングを決定する際に考慮するページエクスペリエンス関連の要素の一つとして扱っています。一方で、Core Web Vitalsだけを改善すれば上位表示できるわけではなく、検索意図に合った有益なコンテンツであることの方が重要です。 例えば、 Aサイト：Core Web Vitalsは非常に良いが、内容が薄いBサイト：表示速度は少し劣るが、検索ユーザーの疑問に詳しく答えている という場合、単純にAサイトが上位になるわけではありません。 そのため、Core Web Vitals改善の目的は、 「SEOの点数を上げること」ではなく、ユーザーがストレスなく利用できる環境を整えること と考えるのが重要です。 問い合わせや採用を目的とした企業サイトなら、ユーザー体験の改善は離脱防止やフォーム到達にもつながるため、SEO以外の意味でも取り組む価値があります。 まず覚えたいLCP・INP・CLSの基準値 Googleが示している「良好」の目安は次のとおりです。 LCP：2.5秒以下INP：200ミリ秒以下CLS：0.1以下 Core Web Vitalsでは一部の高速ユーザーだけを見るのではなく、実際のユーザー体験を広く捉えるため、ページ訪問の75パーセンタイルで3指標すべてが推奨値を満たしているかが重要な基準になります。 指標何を測る？良好の目安LCP読み込み速度2.5秒以下INP操作への反応200ms以下CLS表示の安定性0.1以下 まずは、この3つの意味を理解することから始めましょう。 LCPとは？ページの「表示速度」を改善する方法 LCPは、ページを開いてから、ファーストビュー内の大きな画像やテキストなど、主要なコンテンツが表示されるまでの時間を測ります。 Googleが推奨する良好なLCPは2.5秒以下です。 企業サイトでLCPの対象になりやすいのが、 メインビジュアル 大きな写真 メインコピーを含む大きなテキスト領域 などです。 ファーストビューの大きな画像を軽くする 企業サイトでLCPが悪化する代表的な原因の一つが、ファーストビューの大きな画像です。 例えば、 5MB以上ある写真をそのまま掲載 PC用の巨大画像をスマホでも読み込む 必要以上に高解像度な画像を使用 といった状態です。 改善する場合は、 適切な画像サイズへリサイズするWebPなど効率的な画像形式を検討する端末サイズに合った画像を配信する必要以上に高画質な画像を使用しない といった方法を検討します。 LCPはメインコンテンツが表示されるまでの時間を測るため、特にファーストビュー画像の読み込み方法は重要な改善ポイントです。 サーバーの応答速度を見直す 画像だけではなく、サーバー側の応答が遅ければページ表示全体が遅くなります。 例えば、 サーバースペックが不足している アクセス集中で処理が遅れている CMS側の処理が重い キャッシュが適切に利用されていない といった原因が考えられます。 画像を圧縮してもLCPが改善しない場合は、フロント側だけでなくサーバー・CMS環境まで確認することが大切です。 不要なCSS・JavaScript・外部読み込みを減らす ページを開く際に大量のCSSやJavaScriptを読み込んでいると、重要なコンテンツの表示が後回しになることがあります。 よくあるのが、 使用していないプラグイン 大量のアニメーション 計測タグ チャットツール SNS埋め込み Webフォント などです。 「便利だから」「以前から入っているから」と残すのではなく、本当に必要なものか定期的に棚卸しすることが重要です。 LCP画像を遅延読み込みしすぎない 画像の遅延読み込み（lazy load）は、ページ全体の読み込み量を減らすためには便利です。 しかし、最初から表示されるメインビジュアルなど、LCPの対象になる重要画像まで不必要に遅延させると、逆に表示が遅くなることがあります。 「すべての画像を遅延読み込みする」のではなく、ファーストビュー画像と下層画像を分けて設計することが大切です。GoogleのLCP最適化ガイドでも、LCPリソースを早く発見・読み込み・レンダリングできる状態にすることが重要とされています。 INPとは？クリック後の「反応の遅さ」を改善する方法 INPは、ユーザーがページ内で行ったクリック・タップ・キーボード操作などに対して、画面がどれだけ早く反応したかを評価する指標です。 良好な目安は200ミリ秒以下です。INPはページ滞在中に発生した対象インタラクションの応答性を継続的に見て、ページ全体として反応が悪くないかを評価します。 例えば、 メニューを押したのに開かない フォームの選択肢を押しても反応が遅い 「もっと見る」を押してから表示まで時間がかかる といった状態は、INP悪化につながる可能性があります。 重いJavaScript処理を減らす INPが悪い場合、代表的な原因の一つがJavaScriptです。 JavaScriptの処理中は、ブラウザがユーザー操作への反応をすぐに返せない場合があります。 不要なスクリプトを削除する 処理内容を見直す 必要なタイミングまで読み込みを遅らせる などによって改善を検討します。GoogleのINP最適化ガイドでも、入力遅延・イベント処理・次の描画までの時間を短縮することが重要とされています。 長時間メインスレッドを占有する処理を分割する 一つの重い処理が長時間実行されていると、その間ユーザー操作への反応が遅れます。 処理を小さく分けたり、不要な処理を減らしたりすることで、ユーザー操作を処理できる余裕を作ります。 専門的な実装になるため、INPに問題がある場合は制作会社やエンジニアへの相談をおすすめします。 外部ツール・タグを整理する 企業サイトでは公開後、さまざまなツールが追加されていきます。 GA4 GTM 広告タグ ヒートマップ チャット MAツール SNS関連 一つひとつは必要でも、積み重なることでサイトが重くなる場合があります。 リニューアル時には、現在使っているタグをすべて棚卸しするのがおすすめです。 「昔の広告用タグが残っていた」「使っていないヒートマップが動いていた」 というケースは珍しくありません。 フォームやメニューの操作感を実機で確認する 数値だけでなく、自分でスマートフォンを操作することも重要です。 ハンバーガーメニュー 問い合わせフォーム アコーディオン 検索機能 スライダー モーダル など、ユーザーが触る機能を実際に試してみましょう。 INPはユーザー操作への応答性を見る指標なので、「自分で触って遅いと感じる場所」が改善箇所を探すヒントになります。 CLSとは？突然レイアウトがズレる問題を改善する方法 CLSは、ページを閲覧している途中にレイアウトが予期せず移動する現象を評価します。 良好な目安は0.1以下です。 例えば、 ボタンを押そうとした瞬間に広告が表示され、位置がずれる 文章を読んでいたら上から画像が読み込まれて文章が移動する Webフォント読み込み後に文字サイズが変わる といった状態です。 ユーザーにとって非常にストレスの大きい現象なので、改善する価値があります。 画像・動画の表示領域をあらかじめ確保する 画像のwidth・heightなどが適切に設定されていないと、ブラウザは画像が読み込まれるまで必要なスペースを判断できません。 結果として、 文章が先に表示↓画像読み込み↓文章が下へ移動 というレイアウトシフトが発生します。 画像や動画のサイズ・アスペクト比を事前に指定し、読み込み前から表示領域を確保することが、CLS改善の基本です。 後から表示されるバナーやコンテンツに注意する Cookieバナー、広告、キャンペーン案内などをページ上部へ後から挿入すると、既存コンテンツを押し下げることがあります。 対策として、 あらかじめ表示スペースを確保する 既存コンテンツを押し下げない表示方法にする ユーザー操作後の表示方法を見直す などを検討します。サイズを確保していない動的コンテンツは、CLS悪化の代表的な原因の一つです。 Webフォントによる文字ズレを抑える Webフォントの読み込み前後で文字幅や高さが大きく変わると、文章の位置がずれることがあります。 日本語サイトでは文字量が多いため、フォント選択や読み込み方法による影響が大きくなるケースもあります。 デザイン性だけでなく、 読み込み速度 可読性 レイアウトへの影響 まで考えてフォントを選択しましょう。 Core Web Vitalsの確認方法｜まず見るべき3つのツール Google Search Console Search ConsoleにはCore Web Vitalsのレポートがあり、実際のユーザーデータをもとにサイトの問題を確認できます。GoogleもCore Web Vitals改善時の確認手段としてSearch Consoleのレポートを案内しています。 「サイト全体として問題があるページ群を探す」用途に向いています。 まずは、 良好 改善が必要 不良 となっているページがどれくらい存在するのか確認しましょう。 PageSpeed Insights PageSpeed Insightsは、URLを入力するだけでパフォーマンスを確認できるGoogleのツールです。 利用可能な場合は実際のユーザー環境から収集されたフィールドデータを確認でき、同時にLighthouseによるラボ環境での診断も改善箇所の特定に役立ちます。フィールドデータとラボデータは測定環境が異なるため、数値が一致しない場合があります。 重要なのは、 点数だけを見るのではなく、「何が遅くしているか」を見ること です。 Chrome DevTools・Lighthouse 具体的な原因を調べたい場合は、Chrome DevToolsやLighthouseを利用します。 例えば、 どの画像がLCP対象か どの処理が重いか どの要素がレイアウトシフトしているか など、問題の原因をより細かく分析できます。Googleは、Core Web Vitalsは実際のユーザーデータで評価しつつ、Lighthouseなどのラボツールを問題診断に活用するワークフローを案内しています。 「PageSpeed Insightsで100点」を目標にしなくていい理由 Core Web Vitals改善でよくある失敗が、 「とにかくPageSpeed Insightsを100点にする」 ことが目的になってしまうことです。 Google自身も、Core Web Vitalsのスコアが良いからといって検索上位が保証されるわけではなく、SEOだけを理由に満点を追い求めることは有効な時間の使い方とは限らないと説明しています。 例えば、100点を取るために、 必要な写真を極端に小さくする 便利な機能を削除する ブランド表現をすべてなくす となってしまえば、本末転倒です。 目指すべきなのは、 ユーザーがストレスなく閲覧できる伝えたい情報がきちんと伝わる問い合わせ・応募につながるそのうえでCore Web Vitalsも良好 という状態です。 リニューアル時にCore Web Vitalsが悪化しやすい原因 「古いサイトより新サイトの方が遅くなった」ということは実際に起こります。 原因として考えられるのは、 大きなメインビジュアルを追加した動画をファーストビューへ追加したアニメーションを増やしたWebフォントを増やしたJavaScriptライブラリが増えた計測・広告・チャットタグが増えたWordPressプラグインが増えた などです。 つまり、デザインを豪華にすることと、快適に使えることは必ずしも同じではありません。 リニューアルではデザイン確認だけでなく、公開前にPageSpeed Insightsや実機でパフォーマンス確認を行いましょう。 Core Web Vitals改善チェックリスト LCP｜読み込み速度 ファーストビュー画像が必要以上に大きくない 画像を適切なサイズ・形式にしている LCP対象画像を不必要に遅延読み込みしていない 不要なCSS・JavaScriptを減らしている サーバー応答が極端に遅くない 不要な外部ツールを削除している INP｜操作への反応 ボタン・メニューがすぐ反応する 重いJavaScript処理を見直している 不要なタグ・外部スクリプトを整理している フォームを実際のスマートフォンで操作確認している アニメーションやUI機能を増やしすぎていない CLS｜表示の安定性 画像に表示サイズ・アスペクト比を設定している 動画・iframeの領域を確保している 後から挿入されるバナーの領域を確保している フォント読み込みによる大きなズレがない ページをスクロールしても突然コンテンツが動かない 計測・運用 Search ConsoleでCore Web Vitalsを確認している PageSpeed Insightsで重要ページを確認している トップページだけでなくサービスページも確認している PC・スマートフォンの両方を確認している リニューアル公開後も継続して数値を監視している まとめ：数字を良くすることではなく“快適に使えるサイト”を目指す Core Web Vitalsは、 LCP＝表示されるまでの速さINP＝操作への反応の速さCLS＝画面の安定性 という、ユーザーがホームページを利用するときの基本的な体験を数値化したものです。 現在Googleが示している良好の目安は、LCP 2.5秒以下・INP 200ミリ秒以下・CLS 0.1以下です。 ただし、Core Web Vitalsだけを改善すればSEOで勝てるわけではありません。 検索意図を満たすコンテンツ企業としての信頼性分かりやすい導線問い合わせしやすい設計快適なページ体験 これらを総合的に整えることが重要です。Googleも、特定のページエクスペリエンス指標だけに集中するのではなく、全体として良いページ体験を提供することを推奨しています。 Core Web Vitalsは「SEOのための点数」ではなく、ユーザーが快適にサイトを利用できているかを確認する健康診断として活用しましょう。 無料相談 Refuでは、PageSpeed Insights・Search Consoleなどを活用した現状分析から、画像最適化、JavaScript・外部タグの整理、WordPress・サーバー環境の見直しまで、サイトごとの原因に合わせた改善をご提案しています。 「リニューアルしたらサイトが重くなった」「PageSpeed Insightsの数値をどう見ればいいか分からない」「SEOと問い合わせの両方を考えて改善したい」 など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら ページスピード改善で成果が変わる！画像・構造の見直し術 画像サイズとページ速度の関係を理解する｜表示速度を改善する実践テクニック リニューアル後に検索順位が落ちた時の原因チェック｜最短で戻す改善手順 リニューアル時のアクセス解析「引き継ぎ」完全ガイド｜GA4設定・GTM・計測の落とし穴 リニューアル後の改善ロードマップ｜公開後90日でやるべき施策チェックリスト
2026/08/10
ホームページ制作の基本404エラーとは？ホームページで起きる原因と正しい対処法
404エラーとは？「ページが見つからない」を示すステータス ホームページを見ていると、 「404 Not Found」「お探しのページが見つかりません」 という画面が表示されることがあります。 これは、アクセスされたURLに対応するページがサーバー上に存在しないことを示すものです。 Webサーバーは、ブラウザや検索エンジンからアクセスを受けると、「正常に表示できた」「ページが存在しない」などの状態をHTTPステータスコードで返します。 その中で404は「要求されたページが見つからない」状態を示すコードです。 Googleも、すでに削除され、同じ内容の代替ページが存在しない場合には、404または410のステータスコードを返すことを案内しています。つまり、404が表示されること自体が必ずしも異常というわけではありません。 重要なのは、 「なぜ404になっているのか」「その404を直す必要があるのか」 を判断することです。 404エラーが発生する主な原因 404が発生する原因は一つではありません。 ホームページ運用でよくあるのは、次のケースです。 ページを削除した ブログ記事やサービスページなどを削除すると、そのURLへアクセスした際に404になります。 ページのURLを変更した たとえば、 /service-web/ だったURLを、 /web-production/ へ変更したにもかかわらず、旧URLから新URLへの転送設定をしていない場合です。 内部リンクのURLを間違えている メニューや記事内リンクの入力ミスでも404は発生します。 たとえば、 /service/ へリンクするつもりが、 /servise/ となっているケースです。 リニューアルでURL構造を変更した ホームページリニューアルでは、サイト構造を整理するためにURLを変更することがあります。 このとき旧URLへの対応をしていないと、検索結果や外部サイトからアクセスしたユーザーが404ページへ到達してしまいます。 外部サイトに古いURLが掲載されている 自社サイトを修正しても、 ポータルサイト SNS 過去のプレスリリース 他社ブログ メディア記事 などに古いURLが残っているケースがあります。 この場合も、旧URLが適切に処理されていなければ404になります。 404エラーがあるとSEOに悪影響？ 「404があるとGoogleから評価を下げられるのでは？」 と心配する方も多いでしょう。 しかし、404が存在すること自体を過度に恐れる必要はありません。 ページを削除し、代わりとなるページも存在しないのであれば、404または410を返すのはGoogleが案内している正しい処理です。 問題なのは、本来ユーザーに見せるべきページが404になっているケースです。 たとえば、 検索結果に表示されている重要ページが404 サイト内のメニューから404へリンクしている 外部サイトから多くリンクされているページを削除した リニューアル後に旧ページが大量に404になった といった状態です。 この場合、検索エンジン以前に、ユーザーが必要な情報へ到達できません。 したがって404対策では、 「404をゼロにする」 のではなく、 「ユーザーが本来到達すべきページを404にしない」 という考え方が重要です。 404のままで問題ないケース・修正すべきケース 404を見つけたからといって、すべてリダイレクトすればいいわけではありません。 ページの状態によって対応を変えます。 削除して代替ページがない→404または410 たとえば、 終了したキャンペーン 廃止したサービス 古くなり完全に不要になったページ などで、ユーザーを案内できる代替ページが存在しない場合です。 この場合は、無理に別ページへ転送せず、404または410を返す方法が適切です。 Googleも、削除済みで同様のコンテンツを持つ代替ページがない場合には、404または410を返すことを案内しています。 つまり、 「404＝必ず修正しなければならない」 ではありません。 ページを別URLへ移動した→301リダイレクト ページそのものは残っているものの、URLだけ変更した場合は対応が変わります。 たとえば、 旧URL：/old-service/ 新URL：/service/ へ移動したのであれば、旧URLから新URLへ301リダイレクトを設定します。 Googleも、ページが移動した場合や明確な代替ページが存在する場合には、301によって適切なページへリダイレクトすることを推奨しています。 301リダイレクトによって、 古いURLから来たユーザーを新ページへ案内できる ページの新しい場所を検索エンジンに伝えられる というメリットがあります。 URL変更やリンク設定のミス→リンクを修正 単純なリンクミスで404が起きている場合は、リダイレクトではなくリンクそのものを修正するのが基本です。 たとえば、 × /servise/○ /service/ という間違いであれば、内部リンクを正しいURLへ変更します。 特に確認したいのは、 グローバルメニュー フッターメニュー CTA ブログ記事内リンク バナー パンくずリスト などです。 ユーザーがよく利用する導線ほど、優先して修正しましょう。 注意したい「soft 404」とは？ 404対策で知っておきたいのが、soft 404（ソフト404）です。 通常の404では、サーバーが「このページは存在しません」という意味の404ステータスコードを返します。 一方soft 404では、 画面上では「ページがありません」と表示しているのに、サーバーは「200 OK＝正常なページです」と返している といった矛盾が発生しています。 Googleは、存在しないページが200のステータスを返している場合や、メインコンテンツがほとんどないページなどをsoft 404として認識することがあります。該当ページはSearch Consoleのインデックス登録レポートでsoft 404として表示される場合があります。 たとえば、 「商品がありません」 とだけ書かれているのに、正常なページとして200を返しているケースです。 soft 404が発生した場合は、 本当にページが存在しない→404または410 新しいページへ移動した→301 本来存在するページ→表示エラーや読み込み問題を修正 というように、ページの状態に合わせて対応します。 ユーザーを離脱させない404ページの作り方 正しい404を返していても、 「404 Not Found」 とだけ表示されているページでは、ユーザーは次に何をすればいいか分かりません。 そこでおすすめなのが、カスタム404ページです。 Googleも、404ページを分かりやすくカスタマイズし、ユーザーが他のコンテンツを探せるようにすることを案内しています。 最低限、次の要素を入れましょう。 ページが見つからないことを明確に伝える 例： 「お探しのページは見つかりませんでした。」 専門用語ではなく、ユーザーに分かりやすい表現にします。 トップページへのリンク まず戻れる場所を用意します。 👉 トップページへ戻る 主要サービスへのリンク 企業サイトなら、 サービス一覧 料金 制作事例 お問い合わせ などへ誘導すると、離脱防止につながります。 人気記事・おすすめコンテンツ オウンドメディアなら、 「よく読まれている記事」 を表示するのも有効です。 Googleも、人気のある記事やホームページへのリンクを404ページに追加する方法を案内しています。 サイト全体とデザインを統一する 突然真っ白なエラー画面になるのではなく、通常ページと同じヘッダー・フッター・デザインを使用します。 ただし重要なのは、見た目を通常ページのようにしても、サーバーは正しく404ステータスコードを返すことです。Googleもカスタム404ページについて、検索エンジンにインデックスされないよう404を返すよう案内しています。 404エラーを見つける方法 404はユーザーから指摘される前に、定期的に確認することが重要です。 Search Consoleを確認する Google Search Consoleでは、インデックス登録状況などから404やsoft 404に関連する問題を確認できます。 特定URLについて詳しく確認したい場合には、URL検査ツールでGoogleが取得した状態やHTTPレスポンスを確認する方法もあります。Googleもsoft 404やリダイレクトの確認にURL検査ツールを案内しています。 サイト内リンクをチェックする 特に、 サイトリニューアル後 URL変更後 古い記事を大量に整理した後 はリンク切れが発生しやすくなります。 重要ページから順番に確認しましょう。 GA4で404ページへのアクセスを見る 404ページにアクセス解析を入れておけば、 「実際にユーザーがどのくらい404ページへ到達しているか」 を確認できます。 大量にアクセスされている404があれば、検索結果・外部リンク・内部リンクなど、どこからアクセスされているかを調査することで優先順位を付けやすくなります。 リニューアル時に404を大量発生させないための対策 404対策で特に重要なのが、ホームページリニューアルです。 リニューアルでは、 URL構造を変更する ページを統合する 不要ページを削除する カテゴリを整理する といった作業が発生します。 ここで旧URLを整理せず公開すると、検索結果や外部サイトに残っている旧URLからアクセスしたユーザーが404へ到達してしまいます。 リニューアル前に、次のようなURL対応表を作成しておくと安全です。 旧URL → 新URL 例： /old/service-a/ ↓/service/service-a/ 移動先が明確なページは301リダイレクトを設定し、完全に廃止して代替ページもないものは404または410として処理します。これはGoogleが現在案内している考え方とも一致します。 また、リダイレクトはGoogleに対して新しい正規URLを伝える強いシグナルの一つとされています。 404対応でよくあるNG例 NG1：404をすべてトップページへ転送する ページがなくなったからといって、何でもトップページへ飛ばせばいいわけではありません。 ユーザーが探していた内容とトップページが無関係なら、かえって混乱させます。 明確な代替ページがある場合のみ301、ない場合は404または410 と判断するのが基本です。 NG2：削除したページを何でも301する 「SEO評価を失いたくない」という理由だけで、無関係なページへリダイレクトするのもおすすめできません。 サービスAの記事を、内容がまったく違うサービスBへ転送しても、ユーザーの検索意図を満たせないからです。 NG3：見た目だけ404にする 「ページがありません」と表示しているのに200 OKを返していると、soft 404として扱われる可能性があります。 カスタム404ページを作る場合も、HTTPステータスコードは正しく404を返す必要があります。 NG4：404を一件見つけるたびに慌てて直す 存在して当然の404もあります。 たとえば、ユーザーがURLを打ち間違えれば、存在しないURLへの404が発生します。 すべてを修正対象にするのではなく、 「本来存在すべきURLか？」「ユーザーが実際にアクセスしているか？」「代替ページがあるか？」 で優先順位を判断しましょう。 404エラー改善チェックリスト 404が見つかったら、次の順番で確認すると判断しやすくなります。 そのURLは本来存在するページか ページを削除したのか、移動したのか 代替となるページがあるか 代替ページがあるなら301を設定したか 代替ページがないなら404または410を返しているか 内部リンクから404へリンクしていないか Search Consoleで問題を確認したか soft 404になっていないか 404ページ自体が200を返していないか カスタム404ページにトップへの導線があるか サービス・記事など関連コンテンツへの導線があるか リニューアル時に旧URL→新URLの対応表を作ったか 特に優先すべきなのは、 「検索や内部リンクから多くアクセスされている404」 です。 ユーザーへの影響が大きいものから対応しましょう。 まとめ：404は全部消すのではなく「正しく処理する」 404エラーは、ホームページに存在してはいけないものではありません。 ページを削除し、代替ページも存在しないのであれば、404または410を返すこと自体が正しい対応です。 大切なのは、 ページがなくなった→404または410 ページが移動した→301リダイレクト リンクを間違えた→リンクを修正 正常ページなのにsoft 404→表示・読み込みを修正 404ページには次の行動につながる導線を設置 というように、原因ごとに正しく処理することです。 特にホームページリニューアルでは、URL変更による404が大量に発生しないよう、公開前に旧URLと新URLを整理することが重要です。 SEOだけを見るのではなく、 「ユーザーが探している情報へきちんとたどり着けるか」 という視点で404を管理しましょう。 無料相談 Refuでは、ホームページリニューアル時のURL整理・301リダイレクト設計・Search Console確認まで含めて、既存サイトのSEO資産をできるだけ活かしたサイト移行をサポートしています。 「リニューアルすると検索順位が落ちないか心配」「Search Consoleに404がたくさん出ているけれど、どこまで直せばいいか分からない」といった段階からでもお気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら ホームページ公開後にやるべき初期設定10選｜最低限の運用準備チェック SEOの前に整える「サイト構造」｜カテゴリ設計・URL・内部リンクの基本 リニューアル判断の基準｜いつ、何を、どこまで変えるべきか Search Consoleの見方入門｜流入キーワードと改善ポイントの見つけ方 ドメイン・サーバーの選び方｜初心者でも失敗しない基礎知識と注意点
2026/08/03
ホームページ制作の基本ホームページの表示速度を改善する方法｜Core Web Vitalsと画像最適化の基本
ホームページの表示速度が重要な理由 ホームページを開いたとき、なかなか画面が表示されなかったり、ボタンを押しても反応しなかったりすると、ユーザーはストレスを感じます。 特にスマートフォンでは、通信環境や端末の性能によって表示速度が左右されるため、パソコンでは問題なくても、スマートフォンでは遅く感じられることがあります。 表示速度が遅い状態を放置すると、次のような問題につながります。 ページが表示される前に離脱される サービス内容や強みを読んでもらえない お問い合わせや予約まで進んでもらえない 企業や店舗に対する信頼感が下がる 検索結果で競合サイトに負けやすくなる 表示速度は、単なる技術的な問題ではありません。 ホームページを通じて成果を上げるための、ユーザー体験と導線設計の一部として考える必要があります。 Googleも、Core Web Vitalsを検索ランキングで考慮する要素の一つとしています。ただし、表示速度の点数が良ければ必ず上位表示されるわけではなく、コンテンツの関連性や有用性を含めた総合的なページ体験が重要です。 Core Web Vitalsとは？確認すべき3つの指標 Core Web Vitals（コアウェブバイタル）とは、実際のユーザーがページを利用したときの体験を、主に次の3つの視点から測定する指標です。 読み込みの速さ 操作に対する反応の速さ 表示の安定性 2026年7月時点では、LCP・INP・CLSの3つが主要な指標として使用されています。 LCP｜主要コンテンツが表示されるまでの速さ LCP（Largest Contentful Paint）は、画面内の主要な画像やテキストが表示されるまでの時間を測る指標です。 Googleが示す良好な目安は、2.5秒以内です。 LCPが遅くなる主な原因には、次のようなものがあります。 ファーストビューの画像容量が大きい サーバーからの応答が遅い 表示前に大量のJavaScriptを読み込んでいる 画像の読み込み開始が遅れている ホームページを開いても、メイン画像や見出しがなかなか表示されない場合は、LCPに問題がある可能性があります。 INP｜操作に対する反応の速さ INP（Interaction to Next Paint）は、ボタンのクリックやメニュー操作などに対して、ページがどれだけ素早く反応するかを測る指標です。 良好な目安は、200ミリ秒未満です。 INPが悪化しやすいケースとしては、次が挙げられます。 JavaScriptの処理が多い 外部の計測タグや広告タグが多い 複雑なアニメーションを使用している 問い合わせフォームの処理が重い 見た目は表示されていても、メニューやボタンの反応が遅い場合は、INPの改善が必要です。 CLS｜表示中のレイアウトの安定性 CLS（Cumulative Layout Shift）は、ページの読み込み中に、画像やボタン、文章などの位置が突然ずれる現象を測る指標です。 良好な目安は、0.1未満です。 たとえば、ボタンを押そうとした瞬間に広告や画像が表示され、違う場所を押してしまう状態は、CLSが悪い典型例です。 画像や動画の表示領域が事前に確保されていないことや、後から読み込まれるコンテンツ、Webフォントなどが主な原因になります。 まずは現状を測定する｜表示速度の確認方法 表示速度を改善するときは、感覚だけで判断せず、まず現在の状態を測定しましょう。 代表的な確認方法は、次の3つです。 PageSpeed Insights URLを入力すると、スマートフォンとパソコンの表示状況を確認できます。 主に次の情報が表示されます。 Core Web Vitalsの評価 実際のユーザーによる利用データ テスト環境で測定したパフォーマンス 改善できる項目 容量の大きい画像や不要なコード 実際のユーザーデータが表示される場合は、テスト時の点数だけでなく、実際のユーザーがどのような体験をしているかを優先して確認することが重要です。 Search ConsoleのCore Web Vitalsレポート Search Consoleでは、サイト内のページをグループ単位で確認できます。 特定の1ページだけでなく、サイト全体に共通する問題を見つけたい場合に向いています。Search Consoleのレポートは、実際の利用状況に基づくデータを使用しています。 Lighthouse Lighthouseは、表示速度だけでなく、アクセシビリティやSEOなども確認できる診断ツールです。 PageSpeed InsightsやChromeの開発者ツールから実行でき、具体的な問題を調査する際に役立ちます。 ホームページの表示が遅くなる主な原因 表示速度が遅くなる原因は、一つとは限りません。 よくある原因は次のとおりです。 画像の容量が大きい 動画をそのまま読み込んでいる JavaScriptやCSSが多い 外部サービスの読み込みが多い サーバーの応答が遅い WordPressのプラグインが多い キャッシュが正しく設定されていない Webフォントを多く使用している 広告やSNSの埋め込みが多い 古いテーマやコードを使用している まずはPageSpeed Insightsなどで問題を確認し、影響の大きい項目から改善することが大切です。 表示速度を改善する7つの方法 画像を圧縮・最適化する 企業サイトで表示速度を遅くしている原因として、特に多いのが画像です。 デジタルカメラやスマートフォンで撮影した写真を、そのまま掲載すると、1枚で数MBになることがあります。 次の方法で画像を最適化しましょう。 掲載場所に合ったサイズへ縮小する JPEG・PNGを適切に使い分ける WebPやAVIFなどの軽量な形式を検討する 画質を保てる範囲で圧縮する 画面外の画像は遅延読み込みを利用する ただし、ファーストビューの主要画像まで遅延読み込みにすると、LCPが悪化する可能性があります。 最初に表示する重要な画像は早く読み込み、それ以外の画像を遅らせるという使い分けが必要です。 不要なJavaScriptやCSSを減らす JavaScriptやCSSが多すぎると、ブラウザが画面を表示するまでの処理が増えます。 特に注意したいのが、次のような外部ツールです。 アクセス解析タグ 広告計測タグ SNS埋め込み チャットツール ヒートマップ アニメーション用ライブラリ すべて必要かを見直し、使っていないタグや機能は削除しましょう。 ファイルの圧縮や読み込み順序の変更も有効ですが、専門的な作業になるため、制作会社やエンジニアに確認するのが安全です。 サーバーとキャッシュ設定を見直す 画像を軽くしても改善しない場合は、サーバー側に原因がある可能性があります。 確認したいポイントは次のとおりです。 サーバーの処理性能 PHPなどの実行環境 ページキャッシュの有無 ブラウザキャッシュの設定 CDNの利用 データベースの状態 LCPを改善するには、画像だけでなく、HTMLの最初のデータが届くまでの時間や、主要コンテンツの読み込み開始時期など、ページ全体の読み込み工程を確認する必要があります。 アクセス数やサイト規模に対してサーバー性能が不足している場合は、プラン変更やサーバー移転も選択肢になります。 ファーストビューの読み込みを優先する ファーストビューとは、ページを開いたときに最初に表示される範囲です。 ここに大きな画像、動画、複雑なアニメーションを多く配置すると、ユーザーが内容を確認できるまでに時間がかかります。 改善方法としては、次が挙げられます。 メイン画像の容量を小さくする 背景動画の自動再生を見直す 最初に必要なCSSを優先して読み込む ファーストビューに不要な外部ツールを置かない メイン画像を早い段階で読み込ませる 見た目の華やかさだけでなく、ユーザーがすぐに内容を理解できるかを基準に設計しましょう。 Webフォントを使いすぎない Webフォントは、デザインの統一感を出すうえで便利です。 一方で、種類や文字の太さを多く読み込むと、表示速度に影響します。 次のような見直しが有効です。 使用するフォントを絞る 使用する文字の太さを減らす 不要な言語のフォントデータを読み込まない システムフォントの使用を検討する フォントの読み込み中も文字を表示できる設定にする デザイン性と表示速度のバランスを考えることが大切です。 画像や広告によるレイアウトのずれを防ぐ 画像や動画、地図、広告などの表示領域が決まっていないと、読み込み後にコンテンツが押し下げられます。 CLSを改善するためには、次の対策が有効です。 画像に幅と高さを設定する 動画や地図の表示領域を先に確保する 後から表示するバナー用のスペースを用意する ページ上部へ突然コンテンツを追加しない Webフォントによる文字幅の変化を抑える ユーザーが操作しようとしているボタンやリンクを動かさないことが重要です。 WordPressのプラグインを整理する WordPressでは、プラグインを追加するだけでさまざまな機能を利用できます。 しかし、プラグインが増えすぎると、次の問題が起こりやすくなります。 不要なファイルが読み込まれる データベース処理が増える プラグイン同士が競合する 管理画面やページ表示が遅くなる セキュリティ管理が複雑になる 使用していないプラグインは停止するだけでなく、必要に応じて削除しましょう。 ただし、削除によってフォームや表示が動かなくなることもあるため、バックアップを取ってから作業することが重要です。 症状別｜優先して改善すべきポイント ページ全体の表示開始が遅い 確認する項目 サーバーの応答速度 キャッシュ設定 リダイレクトの回数 WordPressやデータベースの処理 メイン画像の表示が遅い 確認する項目 画像容量 画像形式 読み込みの優先順位 ファーストビュー画像への遅延読み込み ボタンやメニューの反応が遅い 確認する項目 JavaScriptの処理 外部タグの数 アニメーション フォームや検索機能の処理 読み込み中に画面が大きくずれる 確認する項目 画像の幅・高さ 動画や地図の表示領域 後から表示されるバナー Webフォント 原因によって対応方法が異なるため、PageSpeed Insightsの点数だけで判断せず、どの指標に問題があるかを確認しましょう。 表示速度改善でよくある失敗と注意点 失敗1：PageSpeed Insightsで100点を取ることが目的になる 点数を上げること自体が目的ではありません。 Googleも、Core Web Vitalsの良好な結果だけで検索上位が保証されるわけではなく、SEOのためだけに満点を目指すことは必ずしも有効ではないと説明しています。 重要なのは、ユーザーが快適にページを利用できることです。 失敗2：必要な画像や機能まで削除してしまう 画像や動画、フォーム、チャットなどは、ビジネス上必要な場合があります。 単純に削除するのではなく、次の視点で判断しましょう。 問い合わせに貢献しているか 信頼感を高めているか ユーザーの理解を助けているか 軽量化や読み込み方法の変更で残せないか 失敗3：トップページだけを確認する ユーザーが最初に訪れるのは、トップページとは限りません。 検索からブログ記事、サービスページ、事例ページへ直接アクセスすることもあります。 次のページは個別に確認しましょう。 トップページ 主要サービスページ アクセス数の多い記事 お問い合わせフォーム 採用ページ 広告やSNSのリンク先 失敗4：一度改善して終わる 画像やプラグイン、外部タグは運用中に増えていきます。 公開時は速くても、数年後には遅くなっていることがあります。 月次や四半期ごとなど、定期的に確認する仕組みを作りましょう。 表示速度の改善チェックリスト スマートフォンとパソコンの両方で測定したか 実際のユーザーデータを確認したか LCP・INP・CLSのどこに問題があるか把握したか ファーストビュー画像を圧縮したか 画像の表示サイズに合ったデータを使用しているか 不要なJavaScriptや外部タグを整理したか キャッシュ設定を確認したか WordPressの不要なプラグインを整理したか 画像や動画の表示領域を事前に確保したか 主要ページを個別に確認したか 改善後にフォームや表示の動作確認をしたか 定期的に測定する担当者と頻度を決めたか すべてを一度に改善する必要はありません。 まずは、容量の大きい画像・不要な外部タグ・サーバーの応答速度など、影響の大きい部分から着手しましょう。 まとめ：点数ではなくユーザー体験を改善する ホームページの表示速度は、SEOのためだけに改善するものではありません。 ユーザーがストレスなく情報を確認し、問い合わせや予約、応募へ進める状態を作ることが本来の目的です。 表示速度を改善するときは、次の順番で進めましょう。 PageSpeed InsightsやSearch Consoleで現状を確認する LCP・INP・CLSのどこに問題があるか把握する 画像・コード・サーバーを影響の大きい順に見直す 改善後に表示とフォームの動作を確認する 定期的に測定して、遅くなる前に対処する 点数だけを追うのではなく、ホームページの目的や必要な機能を維持しながら、ユーザーにとって快適な状態を目指すことが重要です。 無料相談 Refuでは、PageSpeed InsightsやSearch Consoleを活用した現状分析から、画像最適化・サーバー環境・WordPressの構成まで確認し、優先順位を付けた表示速度改善をご提案しています。 「ホームページの表示が遅い」「改善項目が多く、どこから手を付ければよいか分からない」という方も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら スマホ対応は必須！レスポンシブデザインの基本 ドメイン・サーバーの選び方｜初心者でも失敗しない基礎知識と注意点 ホームページ公開後にやるべき初期設定10選｜最低限の運用準備チェック ホームページのKPI設計｜アクセス・CV・問い合わせを“数字で改善”する方法 GA4で最低限見るべき指標7つ｜初心者でも分かる分析のはじめ方 Search Consoleの見方入門｜流入キーワードと改善ポイントの見つけ方
2026/06/23
リニューアル・運用ノウハウフォームスパム対策まとめ｜reCAPTCHAだけに頼らない防止策
フォームスパムは、「迷惑メールのようなものだから」と放置されがちですが、実際には問い合わせ機会の損失や運用負担の増加につながる厄介な問題です。 特に企業サイトにとって問い合わせフォームは成果につながる重要な導線です。 スパム対策はセキュリティだけでなく、正規の問い合わせを守るためにも欠かせません。 フォームスパムとは？放置すると起きる被害 フォームスパムとは、問い合わせフォームに対して営業・詐欺・不正アクセスなどを目的とした送信が大量に届く状態です。 放置すると、次のような問題が発生します。 本当の問い合わせを見落としやすくなる 対応工数が増える メールサーバーやドメイン評価が低下する 正規メールが届かなくなる可能性がある フォーム停止による機会損失が発生する 不正アクセスや攻撃の足がかりになる 問い合わせフォームは成果の入口だからこそ、適切な対策が必要です。 スパムの種類｜ボット型と手動型で対策が変わる フォームスパムは大きく2種類に分かれます。 ボット型スパム 自動プログラムが短時間で大量送信するタイプです。 特徴として、 短時間で大量送信される 同じ内容を繰り返す 海外IPから送られることが多い などがあります。 手動型スパム 人が実際に入力して送信するタイプです。 主に、 営業メール 詐欺メール 嫌がらせ投稿 などが該当します。 ボット型は技術的な対策で防ぎやすい一方、手動型は運用面も含めた対策が必要です。 結論：スパム対策は「多層防御」が最も効果的 フォームスパムに対して、「これ一つで完璧」という対策は存在しません。 実務では複数の対策を組み合わせることが重要です。 例えば、 入力時にチェックする 送信回数を制限する 人間かどうかを判定する サーバー側で怪しい通信を遮断する スパム疑いを隔離する といった対策を重ねることで、防御力が大きく向上します。 基本対策｜まず実施したいフォームスパム対策 入力チェック（バリデーション）を強化する フォームの各項目に最低限の入力チェックを設けます。 チェックしたい内容 メールアドレス形式 電話番号形式 必須項目の未入力 URLの過剰入力 異常に長い文字列 雑なボットであれば、これだけでもかなり減らせます。 送信頻度制限（レート制限）を設定する 短時間で連続送信できないよう制限します。 設定例 1分間に1回まで 同一IPから10分間で3回まで などが一般的です。 メールアドレスや電話番号の簡易チェックを行う 手動スパムにも効果があります。 例 存在しないドメインを判定する 電話番号の桁数を確認する 不自然な入力内容を隔離する ただし、厳しくしすぎると正規ユーザーも弾いてしまうため注意が必要です。 二重送信防止を実装する 送信後の再送信を防ぐことで、誤送信や不要な送信を減らせます。 対策例 送信ボタンの非活性化 ワンタイムトークンの利用 サンクスページへの遷移 reCAPTCHAの使い分け reCAPTCHAは有効ですが、単独ではなく他の対策と組み合わせることが重要です。 reCAPTCHA v2 チェックボックスや画像認証で人間確認を行います。 メリット 判定精度が高い デメリット ユーザー負担が大きい スマホで離脱につながることがある reCAPTCHA v3 裏側でスコア判定を行います。 メリット ユーザー操作が不要 UXを損ねにくい デメリット 誤判定が発生する場合がある reCAPTCHA導入時の注意点 reCAPTCHAを導入するときは次の点に注意しましょう。 モバイルで離脱率が上がらないか 誤判定で正規ユーザーを弾いていないか ページ表示速度に影響していないか 実務で効果の高い追加対策 ハニーポットを設置する 人間には見えない入力欄を設置し、入力があればスパムと判定する方法です。 メリット UXを損なわない 多くのボットに有効 比較的導入しやすく、優先度の高い対策です。 CSRF対策を行う フォーム画面を経由しない不正送信を防ぎます。 実装例 CSRFトークンの発行 セッション確認 フォームセキュリティの基本対策です。 WAFを導入する WAF（Web Application Firewall）は、怪しいアクセスや攻撃パターンをサーバー側で遮断する仕組みです。 防げるもの SQLインジェクション XSS攻撃 ボットアクセス 脆弱性探索 フォームだけでなくサイト全体の防御にもなります。 IP制限・国別ブロックを活用する 海外からのスパムが多い場合に有効です。 ただし、 海外顧客がいる 海外から問い合わせが来る可能性がある 場合は慎重に設定しましょう。 添付ファイルを制限する ファイル添付機能がある場合は特に重要です。 設定したい項目 拡張子制限 ファイル容量制限 ウイルスチェック 保存先の分離 スパムが届いた後の運用方法 スパム判定ルールを作る 完全に排除するのではなく、隔離運用が現実的です。 例 URLが大量に含まれる 特定ワードを含む 短時間で複数送信される これらを自動的に隔離フォルダへ振り分けます。 ログを記録する 原因追跡や改善のためにログを取得します。 記録したい情報 送信日時 IPアドレス ユーザーエージェント reCAPTCHAスコア 判定理由 CV計測を壊さない スパム対策後は計測の確認も重要です。 NG例 送信ボタンを押した時点でCV計測 推奨 サンクスページ表示時にCV計測 これにより実際の問い合わせのみを計測できます。 よくある失敗と注意点 reCAPTCHAを強くしすぎる 正規ユーザーの離脱につながることがあります。 フリーメールを全て拒否する 正規の問い合わせまで失う可能性があります。 送信制限を厳しくしすぎる 短期間に複数問い合わせしたいユーザーを妨げてしまいます。 スパムが増えたからフォームを閉じる 最も大きな機会損失につながります。 重要なのは、スパムを防ぎながら正規ユーザーを通すことです。 フォームスパム対策チェックリスト 入力チェック（形式・文字数・URL制限）がある レート制限を設定している 二重送信防止を実装している reCAPTCHAを導入している ハニーポットを導入している CSRF対策を実装している WAFなどサーバー側防御がある 添付ファイル制限を行っている スパム隔離ルールを設定している サンクスページでCV計測している まとめ：フォームは成果の入口だからこそ守る価値がある フォームスパムは放置すると運用負担だけでなく、問い合わせ機会の損失にもつながります。 reCAPTCHAだけに頼るのではなく、 入力チェック レート制限 ハニーポット CSRF対策 WAF 隔離運用 といった多層防御を行うことで、正規の問い合わせを守りながらスパムを減らせます。 無料相談 Refuでは、フォームスパムの原因調査から、reCAPTCHA・ハニーポット・WAF・送信制限の設計、GA4・GTMによるCV計測の整備まで一括で対応しています。 「スパムが増えて困っている」「対策したら問い合わせが減りそうで不安」という場合も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら 問い合わせが増える！フォーム改善の具体的テクニック 問い合わせの質を上げる「サンクスページ」活用術｜計測・育成・CV最適化 セキュリティ最低限チェックリスト｜改ざん・乗っ取りを防ぐ運用習慣 Googleタグマネージャーの導入と使い方｜初心者でも迷わない設定ステップ リニューアル時のアクセス解析「引き継ぎ」完全ガイド｜GA4設定・GTM・計測の落とし穴
2026/05/05
リニューアル・運用ノウハウセキュリティ最低限チェックリスト｜改ざん・乗っ取りを防ぐ運用習慣
なぜ今、サイトのセキュリティが“最低限”でも必須なのか Webサイトは、会社の名刺であり、営業・採用・信用の土台です。そのサイトが改ざんされたり、乗っ取られたりすると、被害は「表示が崩れる」だけでは終わりません。 信用の毀損（取引先・求職者からの不信） 機会損失（問い合わせが止まる、広告が止まる） 二次被害（不正サイトへの誘導、マルウェア配布の疑い） 特にCMS（WordPress等）を使うサイトは、更新を放置するとリスクが上がりやすいです。セキュリティは“専門家だけの話”ではなく、運用習慣の話です。 よくある被害例｜改ざん・乗っ取りで起きること 被害は次のような形で現れます。 検索結果に不審なタイトルが表示される（スパムSEO） サイトが別ページへ転送される トップに見知らぬ画像や文字が表示される 管理画面にログインできない（アカウント奪取） Googleから「このサイトは危険」と警告される いずれも、復旧対応・原因調査・信頼回復に時間とコストがかかります。だからこそ、最低限の予防が重要です。 まず結論：最低限やるべきセキュリティ対策はこの7つ 難しい話を抜きにすると、最低限はこの7つです。 SSL（https） CMS／プラグイン／テーマの定期更新 強固なID・パスワード＋二要素認証（2FA） 権限管理（管理者を増やさない） バックアップ（復元できる状態） WAF・ログイン制限などの防御 監視（異常を早く知る） これだけでも、事故の確率は大きく下がります。 最低限チェックリスト（運用編）｜これだけは押さえる SSL（https）と常時暗号化 URLがhttpsになっているか、常時SSLが有効か確認します。問い合わせフォームがあるなら必須です。 CMS／プラグイン／テーマの更新（放置しない） 更新放置は、脆弱性を放置するのと同じです。少なくとも月1回、更新可否を確認する運用を作ります。※更新前にバックアップがあることが前提です。 ID・パスワードと二要素認証（2FA） パスワードは「長く・複雑に・使い回さない」。可能なら2FAを有効化します。 管理画面URLを推測されにくくする ログイン試行制限を入れる といった対策も有効です。 権限管理（管理者を増やさない） 管理者権限は最小限にします。 退職者・不要アカウントは削除 役割に応じた権限（編集者など）を付与 バックアップ（頻度・保存先・復元テスト） バックアップは「取ってる」だけでは不十分です。 頻度：更新頻度に応じて（例：週1〜毎日） 保存先：サーバー外にも保管（同一サーバーだけは危険） 復元：年1でもいいので復元手順を確認 “復元できる”ことがセキュリティです。 WAF・ログイン制限・アクセス制限 WAF（Web Application Firewall）は、攻撃を一定ブロックできます。 加えて、 管理画面へのアクセス制限（IP制限など） ログイン試行制限 も有効です。 監視（改ざん検知・死活監視・通知） 「気づくのが遅い」が被害を大きくします。最低限、次を整えます。 サイトが落ちたら通知（死活監視） 改ざん検知（ファイル変更検知等） サーチコンソールの警告通知を受け取る 最低限チェックリスト（サーバー・ドメイン編） ドメインの乗っ取り対策（レジストラ管理） ドメイン管理画面のパスワード強化・2FAを有効にします。ドメインを奪われると、サイトだけでなくメールにも影響します。 DNS・ネームサーバーの管理と変更履歴 DNSが勝手に書き換えられると、別サイトへ誘導される可能性があります。管理者を限定し、変更履歴が追える状態にします。 サーバーの契約・アカウント管理（共有の罠） 制作会社の共有アカウントで運用していると、担当変更時に引き継ぎトラブルが起きやすいです。契約主体（誰の名義か）、管理情報の保管場所を明確にしましょう。 外注・制作会社に任せる時の注意点（契約の落とし穴） 保守範囲（何を、どこまで、いつやるか） 「保守」と言っても内容は様々です。最低限、次を明文化します。 アップデート対応（頻度） バックアップ（頻度・保存先） 監視（範囲・通知方法） 軽微修正の範囲（どこまで無料／有料か） 緊急時対応（復旧SLA・連絡手段） 改ざんや障害は、初動が命です。営業時間外の対応可否、連絡手段、復旧目安を決めておくと安心です。 アカウント・資産の帰属（ドメイン／サーバー／GA4等） これが曖昧だと、最終的に“自社の資産を取り戻せない”事故になります。最低限、以下は自社管理にするのがおすすめです。 ドメイン管理 サーバー契約情報 GA4／サーチコンソール 広告アカウント 主要なログイン情報の保管 やりがちなNG運用｜被害を呼ぶ“あるある” 更新通知を無視し続ける（放置） 管理者IDを複数人で使い回す（責任不明） パスワードを使い回す バックアップが“同じサーバー内だけ” 退職者アカウントが残り続ける 不具合が怖くて更新しない（結果、脆弱化） 「やらない理由」は色々ありますが、被害が出るともっと大変になります。 まとめ：セキュリティは“機能”ではなく“習慣”で守る セキュリティ対策は、高額なツールを入れることが本質ではありません。更新・権限・バックアップ・監視を習慣化するだけで、多くの事故は防げます。 リニューアルや運用見直しのタイミングで、まずは“最低限チェックリスト”を埋めるところから始めましょう。 無料相談 Refuでは、サイトのセキュリティ運用（SSL、更新、バックアップ、WAF、監視、権限整理）から、保守契約の整理、緊急時の復旧設計まで一括で対応しています。「うちのサイト、最低限できているか不安」「保守を見直したい」など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら SSL対応は本当に必要？セキュリティと信頼性の関係 保守契約とは？制作後に必要な運用サポートの種類と相場 ページスピード改善で成果が変わる！画像・構造の見直し術 運用で差がつく！Webサイトの更新ルール（品質・表記・画像・承認フロー） 301リダイレクト完全ガイド｜SEOを落とさずURL変更する手順と注意点
2026/03/10
リニューアル・運用ノウハウ301リダイレクト完全ガイド｜SEOを落とさずURL変更する手順と注意点
301リダイレクトとは？まずは役割をやさしく理解 301リダイレクトとは、古いURL（旧URL）へアクセスしたユーザーや検索エンジンを、新しいURL（新URL）へ自動転送する設定です。 「301」は恒久的（Permanent）に移転したことを示すステータスで、検索エンジンに「このページは今後こちらが正規です」と伝える役割があります。 リニューアルでURLが変わったのに301を設定しないと、検索エンジンは旧URLを見つけられなくなり、評価・順位・流入が落ちる原因になります。 なぜリニューアルで301が重要なのか｜SEO・流入・機会損失を防ぐ リニューアル時に301が重要なのは、次の3つを守るためです。 SEO評価の引き継ぎ：旧URLが積み上げた評価（被リンク・掲載実績など）を新URLへ渡す 検索流入の維持：検索結果に残っている旧URLからの流入を取りこぼさない ユーザー体験の維持：ブックマークや外部サイトから来た人を404にしない 特にBtoBサイトでは、問い合わせが月に数件でも大きな売上につながります。 リニューアル後に「アクセスはあるのに問い合わせが減った」の原因が、リダイレクト漏れだった…というケースは珍しくありません。 301が必要になるケース／不要なケース 必要：URLが変わる（構造変更・CMS移行・https化など） 例えばこんな変更が入ると、基本的に301が必要です。 ディレクトリ構造を変える（/service/aaa → /services/aaa など） WordPress移行などでパーマリンクが変わる 旧サイトが複数ページ→新サイトで統合（または分割） http→https化、www有無の統一、末尾スラッシュ統一 必要：旧URLが外部リンク・検索流入を持っている サーチコンソールやアクセス解析で流入があるURLは、ほぼ「資産ページ」です。 また、被リンク（他サイトからのリンク）が付いているページも評価が溜まりやすく、確実に引き継ぐべきです。 不要：URLが変わらない（見た目だけ変更） デザイン刷新や文言調整のみで、URLが変わらないなら301は原則不要です。 ただし、http/httpsやwwwの統一など「URLの正規化」を行う場合は別です。 事前準備｜リダイレクト設計でやるべきこと 旧URL一覧を作る（資産ページの洗い出し） 最低限、次のいずれかで旧URLを洗い出します。 サーチコンソール（上位ページ・エラーURL） GA4（ランディングページ） サイトマップ／クロールツール 重要ページ（サービス、実績、料金、会社概要、採用、問い合わせ） 新URLとの対応表（マッピング）を作る 旧URL → 新URL の対応表（マッピング）が、301の設計図です。 ここが曖昧だと、設定漏れ・誤転送が起き、SEOもユーザーも迷子になります。 優先度を付ける（まず守るべきページ） 全部のURLを完璧に…が理想ですが、現場では時間に追われがちです。 そのため、まずは優先度を付けます。 最優先：検索流入が多いページ／問い合わせに直結するページ 次点：被リンクがあるページ／資料DLなど中間CVページ 最後：ほぼ見られていないページ（ただし404放置はNG） 301リダイレクトの設定方法（代表例） サーバー（.htaccess／Nginx）で設定する場合 最も推奨されやすいのは、サーバー側での301設定です。 理由は、表示速度や安定性、転送の確実性が高いからです。 典型例（考え方） 旧URL（/old/aaa）を、新URL（/new/aaa）へ恒久転送 http→httpsやwww有無も、この段階で統一する ※実際の記述はサーバー環境で異なるため、制作会社・サーバー会社と方針だけ先に固めるとスムーズです。 WordPressプラグインで設定する場合（注意点あり） プラグインでも可能ですが、注意点があります。 設定が増えるほど管理が属人化しやすい プラグイン停止で転送が切れる 大量URLだと運用が破綻しやすい 少数のURL変更なら有効ですが、リニューアル規模が大きい場合はサーバー設定が無難です。 ドメイン変更（サイト移転）時の基本方針 ドメイン自体が変わる場合は、301がさらに重要です。 原則は「旧ページに近い新ページへ1対1で転送」し、トップへ一括転送は避けます（後述）。 加えて、サーチコンソールでの移転関連の設定や監視もセットで行うと安全です。 設定後の確認方法｜「できたつもり」を防ぐチェック 旧URLが200になっていないか（正しく転送されているか） 旧URLにアクセスしたとき、旧URLがそのまま表示（200）されているのは危険です。 正しくは、旧URL→新URLに転送され、最終的に新URLが200で返る状態が理想です。 連続リダイレクト（多段）になっていないか 旧URL → 中間URL → 新URL のように転送が重なると、速度低下や評価引き継ぎのロスが起きやすくなります。 できるだけ「旧URL→新URLの一発転送」にします。 Search Consoleでエラー（404/ソフト404）を確認する リニューアル後は、サーチコンソールで以下を定期確認します。 404（見つからない） ソフト404（中身が薄い／実質404扱い） リダイレクトエラー インデックス登録状況の変化 「公開したら終わり」ではなく、公開後に監視することで事故を最小化できます。 よくある失敗と対策｜SEOを落とす“事故パターン” トップへ一括転送（全ページを/に飛ばす） 旧URLを全部トップへ飛ばすのは、最悪の一手になりがちです。 検索エンジンから見ると「関連性が失われた」と判断され、評価が引き継がれにくくなります。 できる限り内容が近いページへ転送が原則です。 リダイレクト漏れで404が大量発生 リニューアル直後に404が増えると、機会損失が発生します。 特に、外部リンクや検索結果経由のユーザーは旧URLで来るため、漏れは直撃します。 事前のURL洗い出しと、公開後のエラー監視が重要です。 302（仮）で設定してしまう 302は「一時的な転送」の意味合いが強く、SEO評価の引き継ぎとしては301が基本です。 意図せず302になっていないかは必ずチェックしましょう。 http/https、www有無の統一ができていない httpとhttps、wwwあり／なし、末尾スラッシュなどが混在すると、評価が分散したり、転送が多段化したりします。 正規URLを決め、全てそこへ集約する設計が必要です。 まとめ：301は“SEOの保険”ではなく“引き継ぎ作業そのもの” 301リダイレクトは、単なるSEO対策というより、旧サイトの資産（評価・流入・導線）を新サイトへ引き継ぐための必須作業です。 URLが変わるリニューアルでは、事前のURL洗い出しとマッピング、公開後のエラー監視まで含めて「セット」で対応するのが安全です。 無料相談 Refuでは、リニューアル時のURL設計〜301マッピング作成〜リダイレクト設定〜公開後のエラー監視まで一括で対応しています。 「URL構造を変えたいけどSEOが怖い」「旧サイトの資産を落としたくない」など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら 古いサイトのSEOを回復させるリニューアル戦略｜検索順位が戻らない原因と改善策 リニューアルで失敗しないための進行スケジュール設計 ページスピード改善で成果が変わる！画像・構造の見直し術 Googleサーチコンソールの基本操作と改善への活かし方 HPリニューアルのタイミングはいつ？リニューアルすべき5つのサイン
2026/03/09
ホームページ制作の基本SSL（https）って何？ホームページの信頼性とSEOに必須な理由
SSL（https）とは？まずは仕組みをやさしく理解 SSLとは、ホームページとユーザーのブラウザの間の通信を暗号化する仕組みです。URLが「http」ではなく「https」で始まっているサイトは、SSLが有効になっています。 たとえば、お問い合わせフォームで入力する 氏名 メールアドレス 電話番号 などの情報は、SSLがないと第三者に盗み見られるリスクがあります。 SSLを導入してhttps化することで、こうした情報のやり取りが暗号化され、安心して閲覧・入力できる状態になります。 なぜSSLが必須なのか｜信頼性・SEO・成果への影響 今のホームページ運用において、SSLは「あると良い」ではなく “必須” です。理由は大きく3つあります。 信頼性：ユーザーは「安全なサイトか」を直感で判断します SEO：検索エンジンは安全性の高いサイトを評価しやすい 成果（問い合わせ・応募）：不安があるとフォーム入力が止まります 特に会社サイトや採用サイトは、「信用」が成果に直結します。SSLはその土台です。 SSL未対応（http）のままだと起こる3つのリスク ① ブラウザで「保護されていない通信」と表示される Chromeなど多くのブラウザは、httpサイトやフォームに対して警告表示を出します。ユーザーはその時点で不安になり、離脱につながります。 ② フォーム入力が敬遠される（CV低下） 問い合わせ・資料請求・採用応募など、入力が必要なページほどSSLの有無が影響します。「このサイト大丈夫かな…」と思われた瞬間に、送信されずに終わるケースは少なくありません。 ③ 情報漏えい・改ざんリスクが上がる SSL未導入は、通信を盗み見られるリスクが増えます。また、第三者に通信を改ざんされる可能性もゼロではありません。 小さなリスクに見えても、企業サイトでは信用毀損のダメージが大きいです。 SSL導入で得られるメリット 通信の暗号化で情報漏えいリスクを低減 フォーム送信やログイン情報など、ユーザーの入力データを暗号化し、盗み見リスクを下げます。 ブラウザ警告を回避して信頼を守る 「保護されていない通信」といった表示を避けられるため、企業サイトとしての安心感を担保できます。 SEO評価・クリック率にプラスに働く 検索結果ではURLが表示されます。httpsのサイトはユーザーに安心感を与え、クリック率にも好影響が出やすいです。 また、安全なサイトであることはSEO上のマイナス要因を潰す意味でも重要です。 SSLの導入方法（制作会社に依頼する場合の確認ポイント） SSL導入は、多くの場合「サーバー側」で設定します。最近は無料SSLが使えるサーバーも多く、導入ハードルは下がっています。 制作会社に依頼する場合は、次を確認すると安心です。 SSLは無料SSLか、有料証明書か（費用が変わる） 証明書の更新は自動か（手動更新だと更新漏れリスク） http→httpsへの切り替え（リダイレクト）も対応範囲か WordPressの場合、URL設定や内部リンク修正も含むか SSL導入時の注意点｜混在コンテンツ・リダイレクト・外部ツール SSL導入は「設定して終わり」ではありません。運用面での落とし穴があります。 ① 混在コンテンツ（httpsなのに一部がhttp） ページ内の画像・スクリプト・外部読み込みがhttpのままだと、ブラウザが警告を出すことがあります。 表示崩れや計測エラーの原因にもなるので、導入後にチェックが必要です。 ② リダイレクト設定（http→https）を必ず行う Googleやユーザーが古いhttpのURLを開いても、httpsへ自動で転送される設定が必須です。 これがないと、評価が分散したり、リンクが無駄になる可能性があります。 ③ アクセス解析・広告・サーチコンソールの再設定 https化後は、Google AnalyticsやSearch Console、広告計測などでURLが変わるため、設定の見直しが必要なケースがあります。 「切り替えたのに数字が取れない」事故を防ぎましょう。 まとめ：SSLは“安全対策”ではなく“ビジネスの前提” SSL（https）は、単なるセキュリティ対策ではありません。 信頼を守り、SEOの土台を整え、問い合わせや応募の機会損失を防ぐための必須要件です。 ホームページを作る・リニューアルするなら、SSLは最初から前提として組み込み、導入後のチェック（混在コンテンツ・リダイレクト・計測）までセットで対応するのが安心です。 無料相談 Refuでは、SSL設定〜https化後のチェック（リダイレクト／混在コンテンツ／計測設定）まで一括で対応しています。 「今のサイトがhttpsになっているか不安」「リニューアル時に安全面も整えたい」など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら ホームページ制作の流れを徹底解説｜依頼前に知っておくべき7つのステップ 契約前に確認すべき5つの項目｜納期・修正・保守のトラブル防止 ドメイン・サーバーの選び方｜初心者でも失敗しない基礎知識と注意点 CMS導入のメリット・デメリット｜自社更新の最適解とは？
