「戻るボタンが効かない」と言われたら、どこまで制作会社の責任？バックボタン・ハイジャック対策で見直した公開後チェック

「サイトから戻れないんだけど、これウチの責任ですか？」

Webサイトの運用保守をしていると、こうした問い合わせを受けることがあります。

ページの見た目は崩れていない。リンクも一見問題ない。アクセス解析のタグも動いている。
それなのに、ユーザーがブラウザの「戻る」を押したときに、前のページへ戻れなかったり、意図しないページや広告のようなものが表示されたりする。

いわゆる「バックボタン・ハイジャック」と呼ばれる挙動です。

2026年6月15日から、Googleはこのバックボタン・ハイジャックを検索のスパムポリシー、つまり迷惑行為の一つとして扱い始めました。対象になったページは、手動による対策や、検索での自動的な評価の引き下げを受けることがあります。

この案内を見たとき、私たちが最初に考えたのは、ポリシーの細かい文面よりも先に、

「自分たちが預かっているサイトで、“戻る”がちゃんと効くかを、誰が確認しているんだろう」

ということでした。

制作時には問題がなかったページでも、公開後に追加した広告タグや計測タグ、外部ライブラリによって、挙動が変わることがあります。
だからこそ、Webサイト保守では「作ったときに問題なかった」だけでは足りなくなってきました。

この記事では、複数のクライアントサイトを運用保守している制作会社の方に向けて、私たちが公開後の確認フローをどう見直したのかを整理します。

なぜこの課題が起きるのか

バックボタン・ハイジャックの厄介なところは、制作時のコードだけが原因とは限らないことです。

公開後の運用の中で、ページにはさまざまな変更が加わります。
広告タグを入れる。計測タグを増やす。外部ライブラリを更新する。ポップアップやレコメンドの仕組みを追加する。

その一つひとつは必要な対応でも、組み合わせによっては、ユーザーの「戻る」という自然な操作を妨げてしまうことがあります。

背景1：表示チェックだけでは「挙動の異常」に気づきにくい

運用の現場では、タグを追加したあとに次のような確認をすることが多いはずです。

ページが表示されているか。
デザインが崩れていないか。
計測が取れているか。
コンバージョンタグが反応しているか。

もちろん、これらは重要です。

ただ、「戻るボタンを押したときに一回で前のページへ戻れるか」は、表示を眺めているだけでは分かりません。

画面上は正常に見えていても、ブラウザの履歴操作だけがおかしい。
ユーザーが実際に操作して初めて違和感に気づく。

このような挙動は、従来の表示確認やリンクチェックだけでは拾いきれない領域です。

背景2：広告タグや外部ライブラリは、あとから入ることが多い

もう一つの問題は、原因が公開後に追加されることです。

納品時点では問題がなかったとしても、その後の運用で広告タグや計測スクリプトを追加することがあります。
広告運用を別会社が担当している場合、制作会社が直接コードを書いていなくても、サイト上の挙動には影響が出ることがあります。

つまり、確認すべき対象は「自分たちが書いたコード」だけではなくなっています。

これが、今回の変更で私たちが一番大きく受け止めた点でした。

解決するためのSTEP

私たちは、バックボタン・ハイジャック対策を特別な一回限りの点検ではなく、公開後の運用フローに組み込むことにしました。

大きく分けると、次の3つです。

STEP 1：現状を可視化する

まず行ったのは、「戻るボタンの挙動を見る」という確認項目を明文化することです。

なんとなく気づいた人が見るのではなく、公開後やタグ追加時に必ず確認する項目として、チェックリストに入れました。

たとえば、私たちは次のような項目を確認しています。

1. 主要ページで「戻る」を押して、一回で前のページに戻れるか
2. 意図しないリダイレクトが発生していないか
3. 頼んでいないポップアップやおすすめ表示が出ていないか
4. 直近で追加したタグやスクリプトが、挙動に影響していないか
5. PCとスマートフォンの両方で確認したか

ポイントは、「表示」ではなく「操作後の動き」を確認項目として扱うことです。

Webサイトの公開後チェックでは、どうしても見た目の崩れやリンク切れに目が行きがちです。
しかし、バックボタン・ハイジャックのような問題は、実際に操作しなければ見つけられません。

私たちは、こうした確認を毎回同じ粒度で行えるように、MONJI+のチェックリスト機能に登録しています。修正依頼を作る画面から確認項目を呼び出せるため、担当者によって確認内容がばらつきにくくなりました。

STEP 2：月次運用として記録・一覧化する

次に見直したのが、異常を見つけたあとの記録方法です。

「戻るボタンが効かない気がする」
「このページ、何か変な挙動をしている」
「スマホだけおかしいかもしれない」

こうした報告は、言葉だけで伝えると再現に時間がかかります。

そのため私たちは、怪しい挙動を見つけたら、画面の該当箇所に直接コメントを置き、「どこで」「何をすると」「どうなるのか」を修正依頼として残すようにしています。

MONJI+の修正依頼機能を使うと、画面上の場所に紐づけてコメントを残せます。
担当者と期日も設定できるため、「誰がいつ対応するのか」が宙に浮きにくくなります。

また、挙動の確認とあわせて、タグやライブラリの追加履歴もWikiに残すようにしました。

記録しているのは、たとえば次のような内容です。

• どのタグ・ライブラリを追加したか
• いつ追加したか
• 何のために追加したか
• 誰が依頼・対応したか

この履歴があると、挙動がおかしくなったときに「最近入れたあのタグが影響しているかもしれない」と当たりをつけやすくなります。

広告運用を別会社に任せている場合も、対応中の修正依頼を公開リンクで共有すれば、「このタグが戻る挙動に影響していませんか」と具体的に確認できます。

STEP 3：数カ月分の実績をもとに交渉・提案する

公開後の挙動チェックは、一度だけ行って終わりではありません。

特に複数のクライアントサイトを保守している場合、タグ追加やページ改修のたびに同じ観点で確認していくことが重要です。

そのため私たちは、月次の運用項目として、チェック結果や修正依頼の履歴を残すようにしています。

この記録があると、クライアントへの報告もしやすくなります。

単に「問題ありませんでした」と伝えるのではなく、

「今月は主要ページで戻る操作を確認しました」
「新しく追加した広告タグについて、PC・スマートフォンの両方で挙動を確認しました」
「怪しい挙動があったため、修正依頼として対応中です」

というように、運用保守の中で何を見ているのかを具体的に伝えられます。

Webサイトの保守費や運用費は、見えにくい作業ほど価値が伝わりにくいものです。
だからこそ、公開後の確認項目や対応履歴を残しておくことは、保守業務の説明材料にもなります。

リンク切れや表示異常のようなものは、MONJI+のWebサイト異常検知&改善機能でまとめて拾えます。
一方で、「戻る操作を妨げているかどうか」は、現時点では人が操作して判断する領域です。

異常はツールで拾い、挙動は人が見る。
私たちは、この役割分担で公開後の確認フローを回しています。

実際に起きた変化

公開後やタグ追加時のチェックリストに「戻るボタンの挙動確認」を入れたことで、確認の抜け漏れは減りました。

以前は、担当者の経験や気づきに頼っていた部分がありました。
しかし、チェックリストとして項目を登録しておくことで、誰が見ても同じ観点で確認できます。

また、怪しい挙動を見つけたときに、画面の該当箇所へ直接コメントを残せるようにしたことで、修正依頼のやり取りも整理しやすくなりました。

「どのページで起きたのか」
「どの操作をしたときに起きたのか」
「PCなのかスマートフォンなのか」

こうした情報を最初から揃えて渡せるため、再現待ちのやり取りが減りました。

さらに、タグの追加履歴をWikiに残すようにしたことで、原因の切り分けも早くなりました。

挙動がおかしくなったときに、直近で追加したタグやライブラリを確認できる。
広告運用の委託先にも、具体的な修正依頼や確認事項として共有できる。

このように、公開後のチェックを「気づいたときに見るもの」から「運用の中で記録するもの」へ変えたことで、対応の属人化を少しずつ減らせています。

注意点・限界

ただし、仕組み化すればすべて自動で判断できるわけではありません。

戻る操作の途中に何かが挟まること自体が、常に問題になるとは限らないからです。
重要なのは、ユーザーが本来行きたかった場所へ戻る行動を、不当に妨げていないかどうかです。

この線引きは、ツールだけで自動判断できるものではありません。

そのページで何を見せたいのか。
どのタグが必要なのか。
ユーザー体験として許容できる挙動なのか。
検索評価やスパムポリシー上のリスクをどう考えるのか。

最後は、サイトの目的と運用状況を理解している人が判断する必要があります。

私たちは、怪しい挙動を見つけやすくする部分は仕組みに任せつつ、「このタグは残す」「この挙動は修正する」「この導線は見直す」という判断は、自分たちで握るようにしています。

公開して終わりではなく、公開後もサイトの挙動を見届ける。
今回のバックボタン・ハイジャックに関する変更は、その当たり前を見直すきっかけになりました。

現場から生まれたWebサイト運用支援プラットフォーム【MONJI+】

公開後の確認を、もう少しラクに回したい方へ。
この記事で触れたチェックリストや修正依頼は、30日間の無料トライアルでそのまま試せます。

▼この記事で触れた機能
・修正依頼：https://monji.tech/ja/plus/function/redesign-request/
・チェックリスト：https://monji.tech/ja/plus/function/#func-feedback-3
・異常検知：https://monji.tech/ja/plus/function/sitecheck-issues/

▼まずは無料ではじめる
https://tool.monji.tech/signup

私たちが現場で感じてきた課題を解決するために生まれたのが、Web運用プラットフォームMONJI+です。

MONJI+は、Webサイト運用に携わる「人」を1つの「チーム」にまとめ、Webサイト運用のあらゆるフェーズを横断して、課題を解決するプラットフォームです。

私たちは、最初から“完成されたプロダクト”を開発することを目指していません。

本当に向き合うべき課題はWebサイト運用の現場にあり、だからこそ私たちは、現場のリアルな声と向き合い続けてきました。

一つひとつの声を受け止めながら、小さな違和感を解消するアップデートを重ね、現場の課題から新たな機能も生まれてきました。
そうした積み重ねを経て、MONJI+は世界77ヶ国のユーザーさまに支えられる存在となりました。

▼MONJI+について、詳しくはこちらをご覧ください
https://monji.tech/ja/plus/

Webサイト運用の現場で働く人が、誇りを持って「この仕事が好きだ」と言える世界。
▼その実現のために、あなたの声をお待ちしております
https://monji.tech/ja/plus/co-creation/

まとめ

バックボタン・ハイジャックは、制作時のコードだけでなく、公開後に追加した広告タグや外部ライブラリが原因で起きることがあります。

だからこそ、Webサイト保守では「納品時に確認したから大丈夫」ではなく、公開後やタグ追加時にも、ユーザーの操作に影響が出ていないかを見続ける必要があります。

私たちは、主要ページで戻るボタンが正しく効くかをチェックリスト化し、怪しい挙動は画面上に直接コメントして修正依頼として管理するようにしました。
あわせて、どのタグをいつ追加したかをWikiに残すことで、原因の切り分けもしやすくしています。

もちろん、「戻る操作を妨げているかどうか」の最終判断は、ツールだけに任せられるものではありません。
サイトの目的やユーザー体験を踏まえ、運用している私たち自身が判断する必要があります。

表示だけでなく、挙動まで見る。
公開後のWebサイト運用では、その確認がますます大切になっていると感じています。