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/13
集客・マーケティング戦略生成AIでSEO記事を作るときの注意点｜量産を避けて独自性を出す編集方法
AI検索が広がってもSEOの基本は変わらない Google検索では、従来の検索結果に加えて、AI OverviewsやAI Modeなど、生成AIを活用した検索体験が広がっています。 そのため、 従来のSEOは通用しなくなるのか AIに引用されるための特別な対策が必要なのか AEOやGEOに取り組まなければならないのか と不安を感じる企業担当者も増えています。 しかし、Googleは公式ガイドで、生成AIを活用した検索でも従来のSEO施策は引き続き重要であり、AI OverviewsやAI Modeに表示されるための特別な技術要件はないと説明しています。 AI検索が広がったからといって、SEOの基本をすべて作り直す必要はありません。 重要なのは、これまで以上に、独自性があり、信頼でき、ユーザーの判断に役立つ情報を作ることです。 まず結論：特別な「AI専用SEO」より基本施策の徹底が重要 AI検索への対応で優先すべきことは、特殊なファイルや新しいテクニックを導入することではありません。 まずは、次の基本を徹底します。 ユーザーの疑問に明確に答える 他サイトにはない経験や情報を加える 著者・運営会社・根拠を明確にする 関連ページを内部リンクで整理する Googleがクロール・インデックス登録できる状態にする ページをスマートフォンでも読みやすくする 公開後も情報を更新する Googleは、生成AI検索においても、明確な技術構造と、独自性・価値のあるコンテンツが基盤になると説明しています。 「AIに選ばれる文章」を考えるよりも、ユーザーが読んで納得し、次の行動を選べるページを作ることが先です。 AI Overviews・AI Modeとは？従来の検索との違い AI Overviewsは複雑な質問の概要を提示する AI Overviewsは、ユーザーが検索した内容について、複数の情報を整理した概要と、詳しく調べるためのリンクを検索結果上に表示する機能です。 特に、 複数の要素を整理する必要がある質問 一つの回答だけでは解決しにくい質問 比較や判断材料が必要な検索 などで表示される可能性があります。 すべての検索で表示されるわけではなく、Googleが従来の検索結果に追加する価値があると判断した場合に表示されます。 AI Modeは比較・検討・深掘り検索に対応する AI Modeは、複雑な質問や比較、追加質問を重ねながら情報を深掘りする検索体験です。 例えば、ホームページ制作を検討している人が、 自社に必要なページ数 制作費用 SEO対策の範囲 制作会社の選び方 公開後の運用方法 などを一度に比較・検討する場面で活用される可能性があります。 従来は複数回に分けて検索していた内容を、より会話的に整理できる点が特徴です。 複数の関連検索を行う「クエリファンアウト」 AI OverviewsやAI Modeでは、ユーザーの質問を理解するために、関連する複数のテーマや情報源を調べる「クエリファンアウト」と呼ばれる仕組みが使われる場合があります。 例えば「中小企業がホームページから問い合わせを増やす方法」という質問には、次のような関連テーマが含まれます。 SEO対策 サービスページの内容 CTA設計 実績・事例 料金ページ フォーム改善 アクセス解析 つまり、単一のキーワードだけを繰り返すよりも、中心テーマと関連する疑問をサイト全体で整理している方が、さまざまな検索意図に対応しやすくなります。 AI検索で選ばれやすいコンテンツの6つの条件 他サイトでは得られない独自情報がある AI検索時代に特に重要になるのが、簡単に代替できない情報です。 例えば、次のような内容が該当します。 自社で実際に対応した事例 顧客からよく相談される課題 現場で起きた失敗と改善策 自社独自の調査やアンケート 実務で使用しているチェックリスト 専門家による判断基準 Googleも、独自の情報・分析・調査や、検索結果にある他のページを上回る実質的な価値があるかを、コンテンツの自己評価項目として挙げています。 他サイトの情報を整理し直しただけの記事ではなく、自社だから書ける情報を加えることが重要です。 質問への答えと根拠が明確に書かれている 記事の冒頭で結論が分からず、長い説明を読まなければ答えにたどり着けないページは、ユーザーにとって使いにくいものです。 基本構成は、次の順番にすると分かりやすくなります。 結論 その理由 具体例・根拠 注意点・例外 次に取るべき行動 ただし、AIに読み取らせることだけを目的に、文章を不自然に細切れにする必要はありません。 あくまで、ユーザーが内容を理解しやすい見出しと文章構造にすることが目的です。 実務経験・事例・一次情報が含まれている 一般的な説明に加えて、実際の経験を記載します。 例えば、 実際にはどこで失敗しやすいか 顧客がどの段階で迷うのか どの施策から始めると改善しやすいか 理論と現場で異なる部分は何か などです。 一次情報は、コンテンツの独自性だけでなく、E-E-A-Tにおける「経験」を伝える要素にもなります。 誰が発信しているか分かる 情報の内容だけでなく、発信者も明確にします。 記事には、可能な範囲で次の情報を掲載します。 執筆者名 監修者名 担当分野 経歴・実績 所属会社 著者プロフィールへのリンク 参考にした公式情報 特に専門性や判断の正確性が重要なテーマでは、誰が、どのような根拠で書いているかが信頼性につながります。 関連情報がサイト内で整理されている 1ページですべてを説明しようとすると、情報が長くなり、検索意図も曖昧になります。 そのため、 親ページでテーマの全体像を説明する 個別記事で疑問を深掘りする 記事からサービスページへ誘導する 料金・事例・FAQへ内部リンクを設置する という構造を作ります。 Googleは、生成AI検索においても、重要なページを内部リンクで見つけやすくすることを基本施策として挙げています。 クロール・インデックス登録が可能な状態になっている どれだけ有用な記事でも、Googleがページを取得・認識できなければ検索結果には表示されません。 最低限、次を確認します。 robots.txtでクロールを誤って拒否していない noindexが設定されていない ページがSearch Consoleで認識されている 重要な文章が画像内だけに記載されていない 内部リンクからページに到達できる スマートフォンで問題なく表示できる ページの読み込みが極端に遅くない AI OverviewsやAI Modeの参照リンク候補になるには、ページがGoogle検索にインデックス登録され、検索結果にスニペットを表示できる状態であることが前提です。 AI検索を意識したコンテンツ制作の手順 検索キーワードではなく「質問」を整理する キーワードだけでなく、ユーザーが実際に知りたい質問を整理します。 例えば「ホームページ制作 費用」であれば、次のように分解できます。 ホームページ制作はいくらかかるのか 何によって費用が変わるのか 制作費以外に必要な費用はあるか 安い制作会社と高い制作会社は何が違うのか 自社には何ページ必要か 見積書のどこを比較すべきか 一つの検索語の裏にある複数の疑問を把握することで、内容の抜け漏れを防げます。 結論→理由→具体例→注意点の順で書く 各見出しでは、最初に答えを示します。 基本テンプレート 結論：まず何をすべきか 理由：なぜ必要なのか 具体例：どのようなケースがあるか 注意点：例外や失敗しやすい点 次の行動：読者は何を確認すべきか この順番にすると、ユーザーが必要な情報を見つけやすくなります。 独自の経験・数値・判断基準を追加する 一般論を書いた後に、必ず自社の情報を追加します。 例えば、 実際の相談で多い課題 制作現場で確認している項目 成果が出た事例 改善前後の数値 依頼を断るケース 自社が重視する判断基準 などです。 数字を掲載できない場合でも、どのような状態から、何を変え、どのような変化が起きたかを具体的に説明すれば、十分な一次情報になります。 関連記事とサービスページを内部リンクでつなぐ 記事を読んだ後の行動まで設計します。 例えば、 AI検索の記事↓キーワード設計の記事↓サービスページSEOの記事↓実績・料金・問い合わせ という流れです。 内部リンクはSEO評価のためだけでなく、ユーザーが検討を進めるための案内として設置します。 公開後も事例や最新情報を追記する 公開時点で完成と考えず、定期的に更新します。 新しい事例を追加する 公式情報の変更を反映する Search Consoleで新しい検索クエリを確認する 読者から寄せられた質問をFAQに追加する 古くなった画面や手順を差し替える 更新すること自体が目的ではありません。 検索する人にとって、現在も正確で役立つ状態を保つことが重要です。 AI検索対策として無理にやらなくてよいこと Google検索のためだけにllms.txtを設置する Googleは、Google検索や生成AI検索に表示されるために、llms.txtなどの特別なAI向けファイルを設置する必要はないと説明しています。 llms.txtを利用する別のサービスのために設置すること自体は問題ありませんが、Google検索での表示や順位を高める効果はないとされています。 AI専用の特殊な構造化データを追加する AI OverviewsやAI Mode専用のschema.orgマークアップはありません。 通常の検索結果でリッチリザルトの対象になる構造化データは引き続き活用できますが、ページに表示している内容と一致させる必要があります。 文章を細かく分割することだけを目的にする 「AIに読み取らせるため、すべての文章を短い塊に分けるべき」という考え方に、Google公式の必須要件はありません。 ページの長さや文章の区切りは、AIのためではなく、テーマとユーザーの理解しやすさに合わせて決めます。 検索語の言い換えページを大量に作る AI検索は同義語や質問全体の意味を理解するため、細かな言い換えごとに別ページを大量作成する必要はありません。 例えば、 ホームページ制作費用 ホームページ制作料金 ホームページ制作価格 ホームページ制作相場 をすべて別記事にすると、内容が重複し、サイト内で評価が分散する可能性があります。 同じ検索意図であれば、原則として一つのページにまとめます。 不自然な口コミ・言及・被リンクを増やす AI検索で紹介されることを目的に、実態のない口コミ、言及、被リンクを作るのは避けます。 Googleは、生成AI検索を操作する目的を含むスパム行為にも、従来のスパムポリシーを適用しています。 長期的には、取材、事例、地域活動、調査データ、役立つテンプレートなど、自然に紹介される理由を作ることが重要です。 生成AIを記事制作に使う場合の正しい運用方法 AIは調査・構成・下書きの補助として使う 生成AIは、次のような作業と相性があります。 関連する疑問の洗い出し 記事構成の整理 長文資料の要点整理 表現の調整 誤字脱字のチェック 見出し候補の作成 Googleも、生成AIはテーマの調査や、独自コンテンツの構造化に役立つ場合があると説明しています。 人が事実確認と独自情報の追加を行う AIの出力をそのまま公開するのではなく、次を人が確認します。 事実関係は正しいか 情報は現在も有効か 公式な根拠があるか 自社の経験が反映されているか 既存記事と重複していないか 読者の判断に役立つ具体性があるか 生成AIなどを使い、ユーザーへの価値を追加せずに大量のページを作る行為は、Googleの「大量生成されたコンテンツの不正使用」に該当する可能性があります。 問題になるのはAIを使うこと自体ではなく、独自性や価値のないページを検索順位の操作目的で大量に公開することです。 誰が・どのように・なぜ作ったかを説明できる状態にする コンテンツ制作では、次の3点を説明できる状態が理想です。 Who：誰が作成・監修したか How：どのように調査・制作したか Why：なぜこの記事を公開したか AIを使用した場合も、読者にとって意味があるなら、使用方法や人による確認体制を説明します。 大切なのは「AIを使ったかどうか」ではなく、情報の正確性と責任の所在が明確になっているかです。 Search ConsoleとGA4でAI検索からの成果を測る方法 生成AIパフォーマンスレポートを確認する GoogleはSearch Consoleに、生成AI検索でのサイトの表示状況を確認する「Generative AI performance report」を提供しています。 このレポートでは、生成AI検索における表示の推移や、表示されているページ、デバイス、国などを確認できます。 ただし、段階的に展開されているため、すべてのSearch Consoleプロパティで表示されるとは限りません。 AI検索から閲覧されるページを把握する レポートが利用できる場合は、次を確認します。 どのページが表示されているか 表示が増えているテーマは何か デバイスや国による違いがあるか 表示されるページに共通する特徴は何か 順位だけを追うのではなく、どのテーマやページが生成AI検索で発見されているかを確認します。 GA4で回遊・問い合わせへの貢献を確認する 検索上で表示されること自体が最終目的ではありません。 GA4では、検索経由で訪問したユーザーについて、次を確認します。 サービスページへの遷移 事例・料金ページの閲覧 CTAクリック フォーム到達 問い合わせ・資料請求 エンゲージメント時間 Search Consoleで「見つけられているか」を確認し、GA4で「成果につながっているか」を確認することで、改善の優先順位を判断しやすくなります。 このまま使えるチェックリスト｜AI検索時代のSEO対策 コンテンツ ユーザーの質問に対する結論が明確に書かれている 結論に対する理由・根拠・具体例がある 自社独自の経験・事例・データが含まれている 他サイトの要約だけで終わっていない 読者が次に取るべき行動が分かる 著者・監修者・運営会社が明確になっている 公式情報や信頼できる情報源を確認している サイト構造 関連記事がテーマごとに整理されている 親ページと子記事が内部リンクでつながっている 記事からサービス・事例・料金ページへ移動できる 重要ページが孤立していない 同じ検索意図の記事が重複していない 技術面 Search Consoleに登録されている 重要ページにnoindexが入っていない robots.txtでクロールを拒否していない スマートフォンで読みやすい 主要な情報がテキストでも掲載されている 構造化データと画面上の内容が一致している AI活用 AIの文章をそのまま公開していない 人による事実確認を行っている 自社独自の知識や経験を追加している 量産を目的にしていない 定期的に内容を見直している 効果測定 Search Consoleで表示ページを確認している GA4で回遊・CTA・CVを確認している 表示だけでなく問い合わせへの貢献を見ている 成果の弱いページをリライトしている まとめ：AIに向けて書くのではなく、ユーザーにとって最も役立つ情報を作る AI検索時代のSEOでも、根本的な考え方は変わりません。 重要なのは、 ユーザーの疑問に明確に答える 独自の経験や一次情報を加える 根拠と発信者を明確にする サイト内の関連情報を整理する Googleがページを取得できる状態にする 公開後の成果を測定して改善する ことです。 AI専用のテクニックを追いかけるのではなく、ユーザーが読んで納得し、比較・判断・行動できるコンテンツを作ることが、従来の検索にも生成AI検索にも共通するSEO対策です。 無料相談 Refuでは、検索キーワードだけでなく、AI検索で深掘りされる関連質問や検索意図まで整理し、記事構成・サイト構造・内部リンク・サービスへの導線を設計しています。 「AI検索の普及で流入が減らないか不安」「今の記事をAI検索時代に合わせて見直したい」「生成AIを使った記事運用のルールを整えたい」など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら コンテンツSEOとは？中小企業でも成果を出せる記事戦略 SEOライティングの基本と構成テンプレート｜検索で“選ばれる”記事の書き方を徹底解説 検索意図から逆算するキーワード設計｜中小企業のためのKWマップ作成法 E-E-A-Tを高めるコンテンツ設計｜信頼されるホームページの作り方 被リンクを増やす広報・PR設計｜中小企業でもできる獲得ルート7選 AI検索時代のSEO対策｜AI Overviews・AI Modeで選ばれるコンテンツの作り方
2026/08/12
デザイン・ブランディングWebアクセシビリティを意識したデザインとは？中小企業サイトの改善ポイント
Webアクセシビリティは「一部の人向け」ではなく、誰でも使いやすいサイトを作る考え方 「Webアクセシビリティ」と聞くと、 障害のある人だけを対象にしたもの 公共機関のサイトだけが対応すればいいもの デザインの自由度が下がるもの というイメージを持つ方もいるかもしれません。 しかし、本質はもっとシンプルです。 年齢、障害の有無、利用している端末や操作方法などにかかわらず、できるだけ多くの人がWebサイトの情報や機能を利用できる状態にすること。 これがWebアクセシビリティの基本的な考え方です。 例えば、 文字が薄すぎて読みにくい ボタンが小さくて押しにくい 画像だけで内容を説明している キーボードではメニューを操作できない フォームのエラー理由が分からない といった問題は、特定のユーザーだけではなく、スマートフォンを使う人、高齢者、一時的に手をけがしている人、明るい屋外で画面を見る人など、多くのユーザーに影響します。 デジタル庁も、Webアクセシビリティについて、専門知識がない担当者や事業者が実務で取り組むためのガイドを公開しており、スマートフォン対応を含めた考え方を整理しています。 まず結論：中小企業サイトは「見える・読める・押せる・操作できる」から改善する Webアクセシビリティには多くの基準があります。 すべてを一度に理解しようとすると難しく感じますが、中小企業サイトで最初に見るべきポイントは、大きく4つです。 見える文字・ボタン・情報が認識できる 読める文章や画像の意味を理解できる 押せるボタンやリンクを間違えず操作できる 操作できるマウス以外の方法でも必要な機能を利用できる まずこの4つを基準に既存サイトを見るだけでも、多くの改善点を発見できます。 Webアクセシビリティとは？まず知っておきたい基本 WCAG 2.2とは？世界的に参照されるアクセシビリティガイドライン Webアクセシビリティを考えるうえで重要なのが、W3Cが策定するWCAG（Web Content Accessibility Guidelines）です。 2026年8月時点では、WCAG 2.2がW3C Recommendationとして公開されています。WCAG 2.2では、従来からの文字コントラストやキーボード操作などに加え、フォーカスが他の要素に隠れないことや、操作対象のサイズなども追加されています。 WCAGには、達成基準として主に A AA AAA というレベルがあります。 企業サイトでアクセシビリティを検討する際は、まずA・AAレベルの考え方を理解しながら改善すると現実的です。 日本ではJIS X 8341-3:2016も重要な基準 日本では、JIS X 8341-3:2016がWebアクセシビリティに関する規格として広く参照されています。 デジタル庁の2025年10月更新の「ウェブアクセシビリティ導入ガイドブック」でも、JIS X 8341-3:2016が現在も参照されることの多い規格として紹介され、スマートフォンなど、その後重要性が増した課題も含めた実践方法が整理されています。 「どこまで対応すればアクセシブルなのか」を考える際は、感覚だけで判断せず、こうした基準を参照することが重要です。 中小企業も無関係ではない｜合理的配慮との関係 日本では、2024年4月1日から、障害者差別解消法に基づく事業者による合理的配慮の提供が義務化されています。 ただし、ここは誤解しないことが重要です。 「すべての民間企業サイトが一律にWCAG 2.2へ完全適合しなければ法律違反になる」という単純な話ではありません。 合理的配慮は個別の場面・状況や事業者への負担なども踏まえて判断されます。Webサイトに求められる具体的な対応も、サービス内容や利用状況によって異なります。 とはいえ、企業がWebを重要な顧客接点として利用する以上、最初から利用しづらい状態を減らしておくことは、ユーザー体験とリスク管理の両面で重要になっています。 まず改善したい8つのポイント 文字と背景のコントラストを確保する おしゃれなサイトで特に起きやすいのが、 「薄いグレーの文字 × 白背景」 です。 見た目は洗練されていても、コントラストが不足すると読みにくくなります。 WCAG 2.2のレベルAAでは、通常サイズのテキストについて少なくとも4.5:1、大きな文字については少なくとも3:1のコントラスト比が基準として示されています。 特に確認したいのは、 本文 小さな注釈 ボタン内の文字 フォームのラベル 画像上に重ねた文字 です。 ブランドカラーだからといって、そのまま文字色に使えるとは限りません。 ブランドカラーの色相を守りながら、明度などを調整して読みやすさを確保するという設計が必要です。 色だけで情報を伝えない 例えばフォームで、 「入力エラーは赤色にします」 だけでは不十分です。 色の違いを認識しにくいユーザーには、何が間違っているのか分からない可能性があります。 そのため、 赤色＋「必須項目です」 赤色＋エラーアイコン＋説明文 グラフなら色＋柄・ラベル のように、色以外の情報も組み合わせることが重要です。 これはアクセシビリティだけでなく、誰にとっても分かりやすいデザインにつながります。 文字サイズ・行間・拡大時の読みやすさを確認する 文字が読みにくい原因は、文字サイズだけではありません。 行間が狭い 文字が細すぎる 1行が長すぎる 拡大するとレイアウトが崩れる スマホで文字が極端に小さくなる こうした問題も確認します。 特に重要なのは、デザインカンプ上で美しく見えるかではなく、実際の端末で読めるかです。 PC・スマートフォンの両方で、 文章を拡大する ブラウザのズームを使う 画面幅を狭くする などの確認をしておきましょう。 画像には内容に応じた代替テキストを設定する 画像だけに重要な情報が含まれていると、画像を認識できない環境では内容が伝わりません。 例えば、 商品写真 施工事例 グラフ サービスの仕組みを説明する図 バナー画像 などです。 意味のある画像には、内容に応じてalt属性などによる代替テキストを設定します。 一方で、純粋な装飾画像にまで説明文を付ければよいわけではありません。 重要なのは、 「この画像が表示されなくても、必要な情報が伝わるか？」 という視点です。 Google Search Centralも、画像などの視覚コンテンツについて、テキストによる説明を用意し、セマンティックなHTMLを使用することを案内しています。Googleはサイトについて、検索だけでなく、あらゆるユーザーに対するアクセシビリティも高めるよう推奨しています。 ボタン・リンクを押しやすくする スマートフォンでは、見えていても押せなければ使いやすいサイトとは言えません。 例えば、 小さな「×」ボタン 密集したテキストリンク 小さなページネーション タップ範囲が文字だけのメニュー などです。 WCAG 2.2では、新しいレベルAAの基準として、ポインター操作のターゲットサイズについて原則24×24 CSSピクセル以上とする基準が追加されています。ただし、要素間の間隔など複数の例外があります。 ここで重要なのは「24pxにすれば終了」ではありません。 実際のサイトでは、 十分なボタンサイズ ボタン同士の余白 タップしやすい位置 誤操作しにくいレイアウト まで含めて確認しましょう。 キーボードだけでも操作できるか確認する Webサイトはマウスやタッチ操作だけで利用されるとは限りません。 キーボードのTabキーなどを使って、 メニュー リンク ボタン フォーム モーダル を操作できるか確認します。 さらに重要なのが、今どこを選択しているのか分かることです。 WCAG 2.2では、キーボードフォーカスが視覚的に確認できることがレベルAAの達成基準として示され、さらにフォーカスされたUIが固定ヘッダーなどで完全に隠れないこともレベルAAの基準に含まれています。 デザイン上、 outline: none; などでフォーカス表示を消してしまうと、キーボード利用者が現在位置を把握できなくなる場合があります。 「デザイン的に邪魔だから消す」ではなく、ブランドに合った見やすいフォーカス表現へ調整することが重要です。 フォームの項目名・エラー内容を分かりやすくする 問い合わせフォームもアクセシビリティで重要な場所です。 特に確認したいのは、 入力欄に項目名がある 必須・任意が分かる エラー理由が具体的 色だけでエラーを表現していない 入力欄とラベルが正しく対応している キーボードでも順番に操作できる といったポイントです。 例えば、 ×「入力内容に誤りがあります」 だけではなく、 ○「メールアドレスを『example@example.com』の形式で入力してください」 のように、修正方法まで伝えます。 アクセシビリティ対応は、結果的にフォーム離脱の改善にもつながる考え方です。 動画・アニメーションは情報を取り残さない設計にする 動画やアニメーションはブランド表現に有効ですが、使い方には注意が必要です。 例えば、 動画でしか説明していない 字幕がない 自動再生され続ける 動きが激しく、情報を追いにくい カルーセルが自動で切り替わり、止められない といった状態です。 重要な情報は動画だけに閉じ込めず、必要に応じて 字幕 テキスト 操作ボタン 停止手段 などを用意します。 「動かすこと」自体を目的にしないことが重要です。 “アクセシブル＝地味”ではない｜ブランドデザインと両立する考え方 アクセシビリティ対応について、 「色が使えなくなる」「デザインが普通になる」「ブランドらしさがなくなる」 と心配されることがあります。 しかし、これは誤解です。 アクセシビリティが求めているのは、デザインを地味にすることではありません。 例えばブランドカラーのコントラストが足りない場合でも、 背景側を調整する 色の明度を調整する ボタンだけ別のアクセントカラーを使う 文字色ではなく装飾にブランドカラーを使う など、ブランドを守りながら改善できます。 むしろ、 「美しいけれど読めない」より、「ブランドらしく、しかも伝わる」ことが本当のデザインです。 アクセシビリティはデザインの制約ではなく、デザインの完成度を高める条件のひとつとして考えるのがおすすめです。 中小企業サイトで優先順位をつけるならどこから？ アクセシビリティ改善を「全ページ一気にやる」と考えると、ハードルが高くなります。 既存サイトであれば、重要度の高い場所から段階的に進める方法があります。 最優先：問い合わせ・予約などCVに直結する場所 最初に確認したいのは、 問い合わせフォーム 予約フォーム CTA 電話ボタン 資料請求 などです。 ここが利用できないと、ビジネス成果そのものを取りこぼします。 まず「相談したい人が最後まで操作できるか」を確認するのが優先です。 次に：トップ・サービス・料金など主要ページ 次に確認するのは、アクセスや比較検討で重要なページです。 トップページ サービスページ 料金ページ 実績・事例 FAQ 特に、 文字色／文字サイズ／リンク／画像／見出し構造／ボタン を重点的に確認します。 最後に：サイト全体へルールを展開する 主要ページを改善したら、個別対応で終わらせず、デザインルールにします。 例えば、 本文色はこの色以上のコントラストを確保 ボタンサイズはこのルール リンクには共通表現を使う フォームのエラー表示はこの形式 画像登録時はaltを確認 フォーカス表示は削除しない といったルールです。 これをCMSの運用ルールやデザインガイドラインに組み込めば、更新するたびにアクセシビリティが悪化する状態を防げます。 このまま使えるWebアクセシビリティ改善チェックリスト 文字・色 本文と背景のコントラストを確認した 薄すぎるグレー文字を多用していない 色だけで「正解・エラー・重要」などを表現していない 文字を拡大しても情報が読める スマホでも本文が小さすぎない 画像・動画 意味のある画像に適切な代替テキストがある 画像の中だけに重要情報を閉じ込めていない 動画だけで重要情報を説明していない 必要な動画には字幕などを用意している 自動再生・アニメーションが操作を邪魔していない 操作 ボタン・リンクが押しやすい タップ要素同士が近すぎない キーボードだけでも主要機能を操作できる Tabキーで現在位置が確認できる 固定ヘッダーなどでフォーカス位置が隠れない フォーム 項目名が入力後も確認できる 必須・任意が分かる エラー内容が具体的 色だけでエラーを示していない エラー後も入力内容が保持される 送信ボタンの役割が明確 運用 新規ページ作成時の確認ルールがある 更新担当者にもアクセシビリティ基準を共有している PCだけでなくスマホでも確認している 自動チェックだけで終わらず、実際に操作して確認している まとめ：アクセシビリティは“制約”ではなく、伝わるデザインの基本 Webアクセシビリティは、特別なユーザーだけを対象にした対応ではありません。 見える。読める。押せる。迷わず操作できる。 この基本を整えることです。 そして、この考え方は、 UI/UX スマホ対応 問い合わせフォーム改善 コンテンツ設計 ブランドへの信頼 とも密接につながっています。 Google Search Centralも、Webサイトについて安全性・速度・デバイス対応と並び、あらゆるユーザーにとってのアクセシビリティを高めることを案内しています。アクセシビリティを「SEOの裏技」と考えるのではなく、ユーザーにも検索エンジンにも内容を適切に届けるサイトづくりの土台として考えるのが適切です。 中小企業サイトであれば、最初から完璧を目指す必要はありません。 まずは問い合わせフォーム、CTA、トップページ、サービスページなど重要度の高い場所から確認し、改善したルールをサイト全体へ広げていきましょう。 法務面の注意 2024年4月1日から、民間事業者にも障害のある人への合理的配慮の提供が義務化されています。 ただし、「民間企業のWebサイトはすべてWCAG 2.2のAAに適合しなければならない」と一律に解釈するのは適切ではありません。 実際の法的義務や必要となる対応は、事業内容・利用者・具体的な申出・過重な負担の有無などによって判断されます。 そのため、公共性の高いサービスや、予約・申請・購入などWeb上で重要な手続きを提供している企業では、「法律でどこまで必須か」だけではなく、利用者がサービスへアクセスできる状態をどう確保するかという視点で対応することが重要です。 無料相談 Refuでは、見た目のデザインだけでなく、文字の読みやすさ・色のコントラスト・スマホ操作・CTA・フォーム・キーボード操作など、実際のユーザー体験を含めたサイト改善をご提案しています。 「アクセシビリティと言われても何から直せばいいか分からない」「デザイン性を保ったまま改善したい」といった場合も、現在のサイトを確認し、優先順位から整理します。 ▶ 無料相談はこちらから その他おすすめ記事はこちら スマホで差がつくUI改善｜押しやすさ・読みやすさのチェックポイント 問い合わせフォームのデザイン改善｜入力離脱を防ぐ項目・エラー表示・確認画面 “信頼される文章”に見せるデザイン｜行間・段落・余白の文章レイアウト術 配色に迷わない｜メイン・サブ・アクセントの黄金比と運用ルール ヘッダー・グロナビの正解は？迷わせないメニュー設計の基本 更新しても世界観が崩れない｜デザインガイドライン（簡易版）の作り方
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/04
リニューアル・運用ノウハウホームページの404エラーとは？SEOへの影響と正しい対処法
404エラーとは？ページが見つからない時に表示される状態 404エラーとは、ユーザーがアクセスしたURLに、該当するページが存在しない時に返されるHTTPステータスコードです。 ホームページを閲覧していて、次のような表示を見たことがある方も多いでしょう。 「ページが見つかりません」 「404 Not Found」 「お探しのページは削除または移動された可能性があります」 これらは、サーバーには接続できているものの、指定されたURLにページが存在しないことを示しています。 404エラーが発生したからといって、必ずしもサイトに重大な不具合が起きているわけではありません。重要なのは、なぜ404になっているのかを確認し、状況に合った処理をすることです。 404エラーが発生する主な原因 404エラーが発生する原因は、主に次のようなものです。 ページを削除した 古いサービスや終了したイベントなどのページを削除した場合、旧URLへアクセスすると404になります。 ページのURLを変更した リニューアルやサイト構造の変更でURLが変わり、旧URLから新URLへの転送が設定されていないケースです。 リンク先のURLが間違っている サイト内のリンクに入力ミスがある場合、存在しないURLへ移動してしまいます。 ユーザーがURLを間違えて入力した URLのスペルミスや文字の入力漏れでも404が発生します。 外部サイトに古いURLが掲載されている 取引先やポータルサイト、過去のSNS投稿などに旧URLが残っている場合もあります。 リニューアル直後に404が急増した場合は、URL変更に伴う301リダイレクトの設定漏れを最初に疑う必要があります。 404エラーはSEOに悪影響を与える？ 結論として、正しく返されている404エラーが存在するだけで、サイト全体の検索順位が下がるわけではありません。 Googleも、存在しないURLが正しい404レスポンスを返している場合、通常はサイトの検索パフォーマンスに影響しないと説明しています。 したがって、存在したことのないURLや、代替ページのない削除済みページまで、無理に修正する必要はありません。 ただし、次のような404は問題になります。 検索流入があった重要ページが404になっている 外部サイトからリンクされているページが404になっている サイト内の主要導線が404へつながっている リニューアル後に大量の404が発生している XMLサイトマップに404のURLが残っている 問題なのは404というステータスそのものではなく、本来ユーザーを案内すべきページが失われ、検索流入や導線が途切れていることです。 404エラーを修正すべきケース・修正しなくてもよいケース ページのURLを変更した場合 ページの内容は残っているものの、URLだけを変更した場合は、旧URLから新URLへ301リダイレクトを設定します。 例 旧URL /service-old/ 新URL /service/ この場合、旧URLを404のままにすると、検索評価や外部リンクからの流入が途切れる可能性があります。 ページを統合した場合 複数のページを1ページへまとめた場合は、それぞれの旧URLから統合先へ301リダイレクトを設定します。 ただし、内容の関係が薄いページへ無理に転送するのは避けましょう。旧ページで説明していた内容を引き継いだ、関連性の高い受け皿ページへ転送することが重要です。 ページを完全に削除した場合 ページを完全に削除し、代わりとなるページも存在しない場合は、404を返して問題ありません。 Googleは、コンテンツを完全に削除し、関連する代替ページがない場合は、404または410を返す方法を案内しています。また、Google検索では410も404と同じように扱われます。 「404があるとSEOに悪い」と考え、関係のないトップページへ転送する必要はありません。 サイト内のリンク先が間違っている場合 自社サイト内のリンクミスで404が発生している場合は、リンク先を正しいURLへ修正します。 特に確認したい場所は次のとおりです。 グローバルメニュー フッターメニュー バナー 記事内の内部リンク 事例からサービスページへのリンク 問い合わせボタン PDFや画像へのリンク サイト内リンクの間違いは、ユーザーの離脱だけでなく、検索エンジンによるページ発見にも影響するため、優先的に修正します。 Googleも、ページの発見やサイト内の関係性の理解にリンクが利用されると説明しています。 存在したことのないURLの場合 ユーザーの入力ミスや、不正なボットによって生成されたURLなど、もともと存在したことのないURLが404になる場合があります。 このような404は、基本的に修正しなくても問題ありません。 ただし、同じ入力ミスが繰り返されている場合や、外部サイトから間違ったURLでリンクされている場合は、正しいページへの転送を検討します。 301リダイレクトと404の正しい使い分け 301リダイレクトと404は、次の基準で使い分けます。 ページが移動した → 新しいURLへ301リダイレクト 複数ページを統合した → 内容を引き継いだ統合先へ301リダイレクト 同じ内容の代替ページがある → 関連性の高い代替ページへ301リダイレクト ページを完全に削除し、代替ページがない → 404または410 存在したことのないURL → 404のままで問題なし 避けたいのは、すべての404をトップページへ一括転送する方法です。 ページの内容とトップページの関連性が低い場合、ユーザーは探していた情報にたどり着けません。また、Googleからソフト404と判断される可能性があります。 Googleも、存在しないページをホームページなどへ転送したり、robots.txtでブロックしたりする対応を控えるよう案内しています。 ソフト404とは？通常の404との違い ソフト404とは、実際にはページが存在しない、または「ページが見つかりません」と表示されているにもかかわらず、サーバーが正常表示を示す「200」のステータスを返している状態です。 通常の404 ページが存在しない → HTTPステータスも404 ソフト404 ページが存在しないように見える → HTTPステータスは200など ソフト404になると、ユーザーにも検索エンジンにもページの状態が正しく伝わりません。 よくある原因は次のとおりです。 404ページを表示しているがステータスコードが200 削除ページをすべてトップページへ転送している 内容がほとんどないページを公開している 検索結果が0件のページを正常ページとして返している Googleは、存在しないページで404や410以外のコードを返したり、無関係なページへ転送したりすると、ソフト404として扱われる可能性があると説明しています。 404ページを使いやすくする改善ポイント ページが見つからないことを明確に伝える まずは、ユーザーに現在の状況を分かりやすく伝えます。 例 「お探しのページは見つかりませんでした」 「ページが移動または削除された可能性があります」 「URLが正しく入力されているかご確認ください」 専門用語だけでなく、ユーザーが次に何をすればよいかまで説明することが大切です。 トップページや主要ページへの導線を設置する 404ページに行き止まりしかないと、そのまま離脱されてしまいます。 次のようなリンクを設置しましょう。 トップページ サービス一覧 制作実績・導入事例 よくある質問 お知らせ・ブログ お問い合わせ ただし、サーバーが返すステータスコードは正しい404のままにします。 404ページ内にリンクを設置することと、URL自体をトップページへ転送することは別です。 サイト内検索や問い合わせ導線を用意する ページ数が多いサイトでは、サイト内検索を設置すると目的の情報を探しやすくなります。 また、サービスや商品を探しているユーザーを取りこぼさないように、問い合わせ導線を設置する方法もあります。 例 「お探しのサービスが見つからない場合は、お問い合わせください」 「ご相談内容に応じて担当者がご案内します」 404ページも、ユーザーを正しい情報へ戻すための導線として設計できます。 404エラーの確認方法 Google Search Consoleで確認する Google Search Consoleでは、インデックス関連のレポートやURL検査を使って、404として認識されているURLを確認できます。 確認するポイントは次のとおりです。 重要ページが404になっていないか サイトマップに記載したURLが404になっていないか リニューアル前のURLが大量に404になっていないか ソフト404が発生していないか リダイレクトエラーが出ていないか ただし、Search Consoleに404が表示されたからといって、すべてを修正する必要はありません。 そのURLに流入や代替ページがあるかを確認してから判断します。 サイト内リンクをチェックする サイト内のリンク切れは、定期的に確認しましょう。 目視だけでは漏れが出るため、ページ数が多い場合はリンクチェックツールやクロールツールを活用します。 特に確認したいのは次の場所です。 共通メニュー 古い記事 過去のキャンペーンページ 事例ページ PDF・画像ファイル 外部予約システムへのリンク リニューアル後は旧URLを重点的に確認する リニューアル後は、旧URLと新URLの対応表をもとに確認します。 旧URLへアクセスする 正しい新URLへ転送されるか確認する 最終ページが正常に表示されるか確認する 多段リダイレクトになっていないか確認する 転送先の内容が旧ページと関連しているか確認する 公開直後だけでなく、Search Consoleの情報が更新される期間も継続して確認します。 404エラー対応でよくある失敗 すべての404をトップページへ転送する 関連性のない一括転送は、ユーザーを迷わせ、ソフト404の原因にもなります。 404をrobots.txtでブロックする 検索エンジンがページの状態を確認できなくなるため、404を隠す目的でのブロックは避けます。 重要ページの404を放置する 流入や被リンクがあるページは、関連する新ページへ引き継ぐ必要があります。 404ページを正常な200ステータスで表示する 見た目だけ404でも、ステータスが200ならソフト404になる可能性があります。 404をゼロにすること自体を目標にする 存在しないURLが正しい404を返すのは正常です。 数を減らすことではなく、重要な導線が失われていないかを確認します。 404エラーチェックリスト 旧URLと新URLの対応表を作成している 移動したページには301リダイレクトを設定している 完全に削除したページは正しい404または410を返している すべての旧URLをトップページへ一括転送していない 404ページが200ステータスを返していない サイト内のリンク切れを確認している XMLサイトマップから削除済みURLを除外している Search Consoleで404・ソフト404を確認している 外部リンクや検索流入のあるURLを把握している 404ページに主要ページへの導線を設置している まとめ：すべての404を消すのではなく、原因に合わせて処理する 404エラーは、存在するだけでサイト全体のSEO評価を下げるものではありません。 重要なのは、404になっている理由を確認し、次のように処理を分けることです。 ページを移動したなら301リダイレクト 関連する代替ページがあるなら適切なページへ転送 完全に削除したなら404または410 サイト内リンクの間違いならリンクを修正 存在したことのないURLなら基本的に対応不要 リニューアル後やページ整理後は、404・リダイレクト・内部リンクをまとめて確認し、検索流入とユーザー導線を守りましょう。 無料相談 Refuでは、サイト内の404調査から、旧URLと新URLの整理、301リダイレクト設定、内部リンク修正、Search Consoleでの公開後確認まで一括で対応しています。 「リニューアル後に404が増えた」「どのURLを転送すべきか分からない」など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら 301リダイレクト完全ガイド｜SEOを落とさずURL変更する手順と注意点 リニューアル後に検索順位が落ちた時の原因チェック｜最短で戻す改善手順 コンテンツ移行で失敗しないために｜旧サイト資産の棚卸しと移行判断基準 SEOを落とさないページ統合・削除の進め方｜残す/統合/消す判断基準と301設計 Googleサーチコンソールの基本操作と改善への活かし方
2026/07/16
集客・マーケティング戦略失注を減らす問い合わせ対応術｜返信テンプレと追客フローの作り方
問い合わせは“獲得”より「初動」で勝負が決まる SEO・広告・SNSなどで問い合わせが増えても、その後の対応が弱いと受注にはつながりません。 実務では、次のようなケースがよくあります。 返信が遅い 返信内容が薄く、次のステップが分からない 見積り後に追客できず自然消滅する 問い合わせは、獲得した瞬間がゴールではありません。 むしろ、問い合わせ後の初動対応こそが受注率を左右します。 特に最初の24時間の対応で、相手の印象は大きく変わります。 まず結論：失注の多くは「遅い・薄い・放置」で起きる 問い合わせ後の失注は、サービス品質以前に次の3つで起きることが多くあります。 遅い：返信が遅く、相手の熱が冷める 薄い：返信内容がテンプレ的で不安が残る 放置：追客がなく、自然消滅する 逆に言えば、この3つを改善するだけで、同じ問い合わせ数でも受注率を高められる可能性があります。 失注が増える問い合わせ対応の落とし穴 返信が遅い 比較検討中のユーザーは、複数社へ同時に問い合わせていることが少なくありません。 返信が1営業日以上遅れるだけで、候補から外れてしまう可能性があります。 次のステップが分からない 「お問い合わせありがとうございます。追ってご連絡します。」 だけでは、相手は次に何が起こるのか分かりません。 いつ連絡が来るのか 何を準備すればよいのか どのように進むのか を伝えることが重要です。 ヒアリング不足で提案がズレる 要望や背景を十分に聞かないまま見積りを出すと、提案内容がズレやすくなります。 ズレた提案は、「この会社は分かっていない」という印象につながります。 見積りの根拠が弱い 金額だけを提示しても、納得感は生まれません。 何が含まれているのか どこまで対応するのか 追加費用はあるのか を明確にしましょう。 追客ができていない 返信が止まったからといって、必ずしも失注とは限りません。 相手が忙しいだけ、社内確認中、比較検討中というケースもあります。 追客の仕組みがないと、そのまま自然消滅してしまいます。 まず整えるべき問い合わせ対応ルール 返信スピードの基準を決める おすすめの目安は次の通りです。 自動返信：即時 一次返信：当日〜翌営業日午前中 見積り・提案の初回提示：3営業日以内 明確な基準があるだけで、対応漏れや返信遅れを防ぎやすくなります。 対応する役割を決める 問い合わせ対応では、役割分担が重要です。 基本の役割 受付：一次返信・日程調整 担当者：ヒアリング・提案 決裁者：見積り確認・最終判断 1人で対応する場合でも、この順番を決めておくと対応が止まりにくくなります。 ヒアリング項目を固定する 最低限、次の5つは確認しましょう。 目的 現状 期限 予算感 意思決定者 聞く内容を固定すると、提案の精度が上がります。 管理表を用意する CRMがなくても、最初はスプレッドシートで十分です。 重要なのは、問い合わせを管理し、次の対応を忘れない仕組みを作ることです。 初動返信テンプレート 資料請求・相談向け 件名 【ご連絡ありがとうございます】資料のご案内／次のステップについて 本文 〇〇様 この度はお問い合わせありがとうございます。株式会社〇〇の△△です。 資料は本メールにてご案内いたします。 より的確なご案内のため、差し支えなければ下記について教えていただけますでしょうか。 ご検討の目的 現在の状況 ご希望時期 ご返信いただけましたら、状況に合わせておすすめの進め方や概算の考え方をご案内いたします。 どうぞよろしくお願いいたします。 見積り依頼向け 件名 【お見積りの件】ヒアリングのお願い 本文 〇〇様 お見積りのご依頼ありがとうございます。株式会社〇〇の△△です。 正確なお見積りのため、以下を確認させてください。 分かる範囲で構いません。 ご相談の目的 参考サイト 必要なページや機能 ご希望納期 ご予算感 いただいた内容をもとに、概算費用と進め方をご案内いたします。 必要であれば、30分ほどのオンラインヒアリングも可能です。 どうぞよろしくお願いいたします。 緊急相談向け 件名 【ご相談内容を確認しました】本日・明日のご相談も可能です 本文 〇〇様 ご相談ありがとうございます。株式会社〇〇の△△です。 内容を確認いたしました。 お急ぎの場合、本日または明日で30分ほどのオンライン相談が可能です。 下記よりご都合の良い時間をお知らせください。 本日 〇〇：〇〇 明日 〇〇：〇〇 事前に、現状のURLと最も困っていることを1行でお送りいただけると、当日のご案内がスムーズです。 どうぞよろしくお願いいたします。 追客フローで自然消滅を防ぐ 追客はしつこさではなく親切 追客は、相手を急かすためではありません。 迷っているポイントや不安を解消するための対応です。 価値ある情報を添えた追客であれば、不快感を与えにくくなります。 追客は3回で十分 おすすめの追客タイミングは次の通りです。 1回目：提案・見積り送付の2日後 2回目：1週間後 3回目：2週間後 それ以上は、相手の温度感を見ながら判断します。 追客メールテンプレート 件名 先日のご提案について補足です 本文 〇〇様 先日はありがとうございました。 ご提案内容はご確認いただけましたでしょうか。 検討時によくご質問いただく点を簡単にまとめました。 追加費用が発生するケース：＿＿＿＿ スケジュールの目安：＿＿＿＿ 近い事例：＿＿＿＿ ご不明点があれば、1点だけでもお気軽にご返信ください。 短く回答いたします。 どうぞよろしくお願いいたします。 反応がない理由を切り分ける 反応がない理由は、主に次のどれかです。 忙しくて後回しになっている 社内決裁で止まっている 予算で迷っている 競合と比較している 追客では、「どこで止まっているか」を確認すると前に進みやすくなります。 失注を減らす提案・見積りの出し方 比較される前提で出す 問い合わせ後の提案は、他社と比較される前提で作ります。 そのため、 何が含まれているか 何が含まれていないか 自社の強みは何か を明確にしましょう。 見積りの根拠を明記する 金額だけではなく、内訳や前提条件を伝えることで納得感が高まります。 記載したい内容 作業項目 想定ページ数 打ち合わせ回数 修正回数 制作範囲 追加費用の条件を明確にする 追加費用が曖昧だと、「後から増えそう」という不安につながります。 最初の提案段階で、追加費用が発生する条件を伝えておきましょう。 次のアクションを決めて終える 提案後に「ご検討ください」で終わると止まりやすくなります。 最後に、 次回打ち合わせ候補日 決裁までの流れ 追加確認事項 を提示しましょう。 CRMなしでも回る管理表テンプレート 必須項目 問い合わせ管理表には、最低限次の項目を入れます。 問い合わせ日時 氏名・会社名 連絡手段 問い合わせ内容 温度感 担当者 ステータス 次回アクション日 メモ ステータス例 未返信 一次返信済み ヒアリング中 提案済み 追客中 受注 失注 特に重要なのは「次回アクション日」です。 これがあるだけで対応漏れを大きく減らせます。 見るべきKPI 月1回は次の数字を確認しましょう。 初動返信までの平均時間 問い合わせから商談化した割合 商談から受注した割合 失注理由 問い合わせ数だけでなく、受注までの歩留まりを見ることが重要です。 このまま使える問い合わせ対応チェックリスト 自動返信が即時で届く 一次返信が当日〜翌営業日午前中にできている 返信テンプレートが温度感別に用意されている ヒアリング項目が固定されている 見積りに内訳・前提条件がある 追加費用の条件が明記されている 追客が3回設計されている 管理表に次回アクション日がある 月1回、返信速度・商談化率・失注理由を確認している まとめ：問い合わせ対応は“文章”より“設計”で改善できる 問い合わせが来ているのに受注につながらない場合、原因は集客ではなく対応設計にあるかもしれません。 重要なのは、 早く返信する 次のステップを明確にする ヒアリング項目を固定する 見積りの根拠を示す 追客を仕組み化する ことです。 問い合わせ対応を整えるだけで、同じ問い合わせ数でも受注率を高められる可能性があります。 無料相談 Refuでは、問い合わせ対応の返信テンプレート作成、追客フロー設計、管理表の整備、失注理由の分析まで含めて、受注につながる運用改善をサポートしています。 「問い合わせは来るのに受注につながらない」「追客ができず自然消滅してしまう」という方は、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら お問い合わせが増えるCTA設計｜ボタン文言・配置・タイミングの鉄則 料金ページのデザインで失注を防ぐ｜見せ方・不安解消・注意点まとめ BtoBのリード獲得を加速する「資料請求」導線の作り方 Web集客に必要なKPIとは？成果を数値で管理する方法｜中小企業が“改善できるサイト”を作る基礎知識 GA4で“集客のムダ”を見つける方法｜チャネル別に成果を伸ばす分析手順
2026/07/14
リニューアル・運用ノウハウリニューアル後の改善ロードマップ｜公開後90日でやるべき施策チェックリスト
リニューアルは公開がスタート｜90日で差がつく理由 ホームページのリニューアルは、公開した時点がゴールではありません。むしろ、本当のスタートは公開後です。 公開直後は、Googleが新しいサイトを評価し直す期間であり、ユーザーのアクセスデータや行動データも集まり始めます。 この最初の90日間で改善を継続できるかどうかが、その後の検索順位や問い合わせ数に大きく影響します。 例えば、次のような要素は公開直後だからこそ重要になります。 404エラーやリダイレクト漏れなどの技術的な問題 GA4やGoogleタグマネージャーの計測設定 問い合わせフォームの動作確認 CTAや導線の改善 SEO評価を高めるコンテンツの充実 公開後の運用を前提にサイトを育てることで、長期的な成果につながります。 まず結論：90日ロードマップは「計測→SEO→CV→運用拡張」の順で進める 公開後は改善したいことが多くありますが、優先順位を間違えると効率が下がります。 まず取り組むべき流れは次のとおりです。 計測環境を確認する SEO上の問題を解消する 問い合わせ導線（CV）を改善する コンテンツや運用体制を拡張する この順番で進めることで、無駄なく成果につなげやすくなります。 公開直後（0〜3日）に必ず確認すること GA4・GTM・広告計測が正しく動いているか 公開後は、まず計測環境を確認します。 確認したいポイントは以下です。 GA4のリアルタイムでアクセスが取得できている お問い合わせ完了などのコンバージョンが計測されている Googleタグマネージャー（GTM）が公開されている 広告を運用している場合はコンバージョン計測が正常に動作している 計測が正しくできていない状態では、改善の判断も誤ってしまいます。 SEOの初期トラブルを確認する 公開直後はSEOに影響する設定も必ず確認しましょう。 主なチェック項目は次のとおりです。 301リダイレクト漏れがない 旧URLが404エラーになっていない noindexが誤って設定されていない robots.txtでクロールを制限していない canonicalタグが適切に設定されている お問い合わせフォームを実際に送信する フォームは必ず実際に送信テストを行います。 確認する内容は以下です。 送信完了ページが表示される 自動返信メールが届く 管理者宛てメールが届く 迷惑メールに振り分けられていない 公開から1週間以内（〜7日）に行うこと Search Consoleでインデックス状況を確認する 公開後1週間程度はGoogle Search Consoleを確認します。 主に見る項目は次のとおりです。 インデックス登録状況 除外ページ 404エラー リダイレクトエラー 問題があれば早めに対応することでSEOへの影響を抑えられます。 重要ページの導線を確認する まずは成果に直結するページを確認しましょう。 対象になりやすいページは次のとおりです。 トップページ サービスページ 料金ページ 事例ページ お問い合わせページ GA4で、 どこから流入しているか どこで離脱しているか CTAがクリックされているか を確認します。 改善候補を書き出す この段階では大きな改修は必要ありません。 例えば、 情報が不足している CTAが分かりづらい 不安を解消する情報が足りない など、改善点を整理しておきます。 公開後30日までに取り組むこと CTAと導線を改善する 問い合わせ数を増やすためには、まず導線を改善します。 例えば、 CTAの種類を絞る CTAの配置を見直す CTA付近に料金や事例、FAQを配置する など、小さな改善でも効果が期待できます。 フォームを改善する 入力の負担を減らすことも重要です。 改善例は次のとおりです。 必須項目を減らす 選択式を増やす 返信目安を記載する プライバシーポリシーへの導線を分かりやすくする スパム対策を見直す 表示速度を改善する 表示速度はユーザー体験だけでなくSEOにも影響します。 見直したいポイントは次のとおりです。 画像の圧縮 不要なJavaScriptの削除 外部スクリプトの整理 フォントやアニメーションの最適化 公開後60日までに取り組むこと SEOで伸びしろのあるページを改善する Search Consoleを活用し、 検索順位が8〜20位程度のページ を優先的に改善すると成果につながりやすくなります。 改善内容としては、 情報を追加する タイトルを見直す メタディスクリプションを改善する などが効果的です。 信頼につながるコンテンツを増やす 比較検討中のユーザーが安心できる情報を充実させます。 例えば、 導入事例 FAQ 料金の考え方 会社情報 実績 などは、問い合わせにもSEOにも効果があります。 内部リンクを整備する 記事や事例が増えてきたら、内部リンクも見直します。 例えば、 ブログ記事からサービスページへ誘導する 事例ページから関連サービスへ誘導する FAQからお問い合わせへつなげる など、回遊しやすい構造を作ります。 公開後90日までに取り組むこと 改善サイクルを定例化する 公開後90日で最も重要なのは、「改善を続けられる体制」を作ることです。 例えば、 毎月数字を確認する 改善案を整理する 優先順位を決める 実施・検証する という流れをルール化します。 更新ルールを整備する 運用が止まらないよう、更新ルールも決めておきます。 例えば、 更新担当 承認フロー 画像サイズ SEOルール 緊急時の対応方法 などを決めておくと、継続しやすくなります。 次の集客施策へ広げる サイトの基盤が整ったら、新たな集客施策にも取り組みます。 例えば、 Web広告 SNS運用 コンテンツSEO メールマーケティング など、集客チャネルを広げていきます。 このまま使える90日チェックリスト 公開直後（0〜3日） GA4でアクセスを計測できている コンバージョン計測が動作している GTMが公開されている お問い合わせフォームが正常に動作している 301・noindex・robots・canonicalを確認した 公開から1週間以内 Search Consoleでインデックス状況を確認した 404エラーや除外ページを確認した 重要ページの導線を確認した 優先して改善する項目を整理した 公開から30日以内 CTAを改善した フォームを改善した 表示速度を改善した 公開から60日以内 SEOを改善した 事例やFAQを追加した 内部リンクを整理した 公開から90日以内 月次レビューを開始した 更新ルールを整備した 次の集客施策を計画した よくある失敗と改善策 計測できていないまま改善してしまう まずはGA4やGTMが正しく動作していることを確認しましょう。 SEO設定のミスを放置してしまう 301リダイレクトやnoindexなどの設定ミスは、早期発見・早期対応が重要です。 改善が単発で終わってしまう 改善項目を優先順位順に整理し、毎月見直す仕組みを作ることで継続しやすくなります。 コンテンツだけ増やして導線を改善していない 記事を増やす前に、CTAやフォームなど問い合わせにつながる導線を整えることが重要です。 まとめ：公開後90日で「育つホームページ」に変わる ホームページは公開して終わりではなく、公開後90日間の改善によって成果が大きく変わります。 まずは、 計測環境を整える SEOの問題を解消する 問い合わせ導線を改善する 継続的な運用体制を作る という順番で進めましょう。 改善を積み重ねることで、ホームページは「作って終わり」ではなく、「成果を生み続ける資産」として育っていきます。 無料相談 Refuでは、ホームページ公開後90日間の改善ロードマップ作成から、GA4・Google Search Consoleによる分析、SEO改善、CV改善、月次運用まで一貫してサポートしています。 「公開後に何を改善すればいいか分からない」「リニューアル後の成果を最大化したい」という方も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら リニューアル時のアクセス解析「引き継ぎ」完全ガイド｜GA4設定・GTM・計測の落とし穴 リニューアル後に検索順位が落ちた時の原因チェック｜最短で戻す改善手順 運用で差がつく！Webサイトの更新ルール（品質・表記・画像・承認フロー） 301リダイレクト完全ガイド｜SEOを落とさずURL変更する手順と注意点 問い合わせの質を上げる「サンクスページ」活用術｜計測・育成・CV最適化
