“The back button doesn’t work”—what should production agencies check after back-button hijacking became a spam policy issue?

“Users are saying they can’t go back from this page. Is that something we’re responsible for?”

If you manage client websites after launch, this kind of question can land on your desk without warning.

The page looks fine.
The layout isn’t broken.
The links seem to work.
The analytics and ad tags are firing.

And yet, when someone presses the browser’s Back button, they don’t return to the previous page. Instead, they may be sent to an unfamiliar page, or shown ads and recommendations they never asked for.

That behavior is often called back-button hijacking.

From June 15, 2026, Google began treating back-button hijacking as one of its search spam policies. Pages affected by this behavior can face manual actions or automatic demotion in search.

When we saw the announcement, the first thing we thought about was not the fine print of the policy.

It was this:

“On the sites we look after, who is actually checking whether the Back button works properly?”

The difficult part is that this behavior is not always caused by code written during the original build. It can also be triggered later by ad tags, measurement tags, third-party libraries, or other scripts added during operation.

That means “it was fine when we built it” is no longer enough.

In this article, we’ll walk through how we reviewed our post-launch check routine for the client sites we manage, and how we now check for back-button hijacking as part of ongoing website operation.

---

Why this problem happens

The hardest part of back-button hijacking is that the cause can be added after launch.

A site may be clean at handoff.
The Back button may behave normally during the final delivery check.
There may be no issue in the production code written by the agency.

But after launch, websites rarely stay untouched.

Measurement tags get added.
Ad tags are installed.
External libraries are updated.
Pop-ups, recommendation tools, or campaign scripts are introduced.

Each change may be necessary. But together, they can change how the page behaves when a user tries to go back.

Background 1: visual checks do not catch behavior issues

In day-to-day website operation, checks often focus on visible problems.

Is the layout broken?
Are images loading?
Are links working?
Is the tag firing correctly?
Is conversion tracking working?

These checks matter.

But a Back button issue does not always appear on the screen.

The page may look completely normal. The problem only appears when someone actually presses Back and watches what happens next.

That is why behavior checks need to be treated differently from visual checks.

A site can look fine and still interrupt the user’s expected action.

Background 2: ad tags and third-party scripts are often added later

Another reason this issue is easy to miss is that the cause may not come from the production agency’s original code.

In many cases, ad operations, campaign tracking, or marketing tools are handled after launch. Sometimes another company manages those tags. Sometimes the client adds them. Sometimes they are added in stages over several months.

As a result, the scope of responsibility becomes harder to see.

Even if your team did not write the script causing the behavior, the issue appears on the client’s website. And when users experience the problem, they often ask the site owner or the maintenance partner first.

That is why post-launch checks need to cover not only what was built, but also what has been added since launch.

---

Steps to solve it

We decided not to treat back-button hijacking checks as a one-time emergency inspection.

Instead, we added them to our normal post-launch operation flow.

STEP 1: Make the current behavior visible

The first thing we did was define what to check.

Instead of relying on someone’s memory or experience, we added Back button behavior to our checklist for post-launch reviews and tag additions.

For example, we check:

1. On main pages, does pressing Back return to the previous page in one step?
2. Are there any unintended redirects?
3. Do unexpected pop-ups or recommendations appear?
4. Could recently added tags or scripts be affecting the behavior?
5. Has the behavior been checked on both desktop and mobile?

The key is to check the action, not only the appearance.

Back-button hijacking cannot be found just by looking at the page. Someone needs to operate the page as a user would.

We register these items in the checklist feature of MONJI+, so the same checks can be called up when creating Feedback. This helps reduce variation between team members and keeps the review process consistent.

STEP 2: Record and organize issues during monthly operation

The next step was improving how we record suspicious behavior.

Reports like these are hard to act on when they are vague:

“The Back button feels strange.”
“This page is doing something weird.”
“It may only happen on mobile.”

Without enough context, the developer or operator has to reproduce the issue from scratch.

So when we find suspicious behavior, we leave a comment directly on the relevant part of the screen and turn it into Feedback.

Using the Feedback feature, we can attach the issue to the screen, add context, assign an owner, and set a due date.

That makes the handoff clearer:

Where did it happen?
What did the user do?
What happened after pressing Back?
Was it desktop or mobile?
Who is responsible for checking or fixing it?

This reduced the amount of back-and-forth needed just to reproduce the issue.

We also started recording tag and library history in the project Wiki.

For each added tag or library, we record:

• what was added
• when it was added
• why it was added
• who requested or handled it

This makes it easier to isolate the cause when behavior changes.

If a Back button issue appears, we can quickly check what was added recently. And if ad operations are handled by another company, we can share only the relevant in-progress Feedback via a public link and ask a concrete question:

“Could this tag be affecting the Back button behavior?”

Broken links and display anomalies can be caught in bulk with MONJI+’s website issue detection.
But whether the Back action is being obstructed is still something people need to check by actually operating the page.

So we divide the roles:

Tools catch anomalies.
People check behavior.

STEP 3: Use the accumulated record for reporting and proposals

Post-launch behavior checks should not be done only once.

For agencies managing multiple client sites, checks need to be repeated whenever tags are added, scripts are changed, or major pages are updated.

That is why we keep the results as part of monthly operation.

This also makes client reporting easier.

Instead of simply saying, “There were no problems,” we can explain what was actually checked:

“We checked Back button behavior on the main pages.”
“We reviewed the new ad tag on both desktop and mobile.”
“We found suspicious behavior and created Feedback for it.”
“We checked the tag history to narrow down the possible cause.”

Website maintenance often includes work that is hard for clients to see.

Behavior checks are one of those areas. They do not always result in a visible design change, but they protect the user experience and reduce operational risk.

Keeping records helps make that work easier to explain.

---

What changed in practice

Adding Back button behavior to our checklist reduced missed checks.

Before, this depended partly on who noticed the issue. Some people checked behavior carefully. Others focused more on layout, links, or tracking.

By turning it into a checklist item, we made the review process more consistent.

It also became easier to hand off suspicious behavior as a concrete issue.

Because we can leave comments directly on the screen and turn them into Feedback, we no longer need to explain everything from scratch in a separate message.

The person handling the fix can see:

where the issue happened,
what action triggered it,
what behavior appeared,
and whether it occurred on desktop or mobile.

Recording tag history in the Wiki also made cause isolation faster.

When behavior changes, we can look back and ask, “What changed recently?”
That gives us a starting point instead of searching blindly.

This does not mean every issue is solved automatically. But the process became less dependent on individual memory and easier to share across everyone involved in operation.

---

Notes and limitations

Even with a better process, not everything can be judged automatically.

Something appearing during a Back action is not always a problem by itself.

The important question is whether it prevents the user from returning to where they intended to go.

That judgment depends on the purpose of the page, the role of the tag, the user experience, and the risks around search policy.

A tool cannot always draw that line for you.

The people operating the site need to decide:

Should this tag stay?
Should this behavior be changed?
Is this script necessary?
Does this action interfere with what the user is trying to do?

Our approach is to let systems make suspicious behavior easier to find, while keeping the final decision in human hands.

Launch is not the end of website responsibility.
After launch, the site’s behavior still needs to be watched.

Back-button hijacking reminded us of that basic principle.

---

MONJI+, the website operation support platform born from the field

To run post-launch checks a little more easily, the checklist and Feedback features mentioned in this article are available to try as part of the 30-day free trial.

▼ Features mentioned in this article

• Feedback: https://monji.tech/plus/function/redesign-request/
• Checklist: https://monji.tech/plus/function/#func-feedback-3
• Website issue detection: https://monji.tech/plus/function/sitecheck-issues/

▼ Start free
https://tool.monji.tech/signup

---

MONJI+ is a WebOps platform born from the challenges we have felt firsthand in the field.

MONJI+ brings the people involved in website operation together into one team, and supports problem-solving across every phase of website operation.

From the start, we have not aimed to build a “finished product.”

The challenges truly worth facing are in the field of website operation. That is why we continue to listen to the real voices of people doing the work.

By taking in each voice, resolving small points of friction, and building new features from real operational challenges, MONJI+ has become supported by users across 77 countries.

▼ Learn more about MONJI+
https://monji.tech/plus/

A world where people working in website operation can say, with pride, “I love this work.”
▼ To make that real, we are waiting to hear your voice
https://monji.tech/plus/co-creation/

---

Summary

Back-button hijacking can be caused not only by code written during the original build, but also by ad tags, measurement tags, and external libraries added after launch.

That is why website maintenance can no longer rely only on handoff checks.

We added Back button behavior to our post-launch checklist, record suspicious behavior as Feedback directly on the screen, and keep tag history in the Wiki so we can isolate possible causes more quickly.

At the same time, the final judgment cannot be left entirely to tools.

Whether a Back action is obstructing the user depends on the page’s purpose, the role of the tag, and the actual user experience.

For production agencies managing client sites, checking not only how a page looks, but also how it behaves, is becoming an essential part of post-launch website operation.