“Search Traffic Is Falling, but We Don’t Know What to Fix” — The WebOps Process We Rebuilt for the AI Search Era

“Search traffic is gradually falling, but we don’t know what to fix first.”

We have been hearing this kind of concern more often from teams involved in website operations.

The content itself has not changed much.
Search rankings have not suddenly collapsed.
And yet, fewer people are making it from search results to the actual page.

We have seen the same thing across both our own site and client sites.

At first, we thought it might just be a temporary dip. But after watching the numbers for several months, the traffic did not bounce back. That was when we started to feel that the premise of search traffic itself was changing.

This article is not about a clever trick to win all that traffic back.

Instead, it explains how we changed our WebOps process: from watching only the “volume” of traffic to maintaining the “state” of published pages so that, when AI or readers arrive, the page is not broken, outdated, or incomplete.

---

Why This Problem Is Happening

When search traffic falls, it is natural to think first about publishing more articles, targeting more keywords, or trying to raise rankings.

Those efforts may still matter.

But in today’s search environment, they are not enough to explain what is happening.

Background 1: Search Is Increasingly “Answering and Ending”

In search, more results now display answers directly on the search page. Users can get what they need without clicking through to any site. This is often called a “zero-click” search.

In the figures covered in the original article, roughly 60% of Google searches end without a click to any site. For queries that display an AI summary, one experiment found that clicks to sites dropped by about 38%. Across publishers as a whole, search-driven traffic fell by roughly 33% in the year through November 2025.

In other words, even when a page is discoverable in search, users may not visit the site in the same way they used to.

At the same time, there was another number we could not ignore: pages cited in AI answers reportedly see click-through rates roughly 35% higher.

So two things are happening at once.

Search traffic as a whole is shrinking.
But pages that are cited by AI may create a different kind of entry point.

That is the reality we had to respond to.

Background 2: Publishing More Content Can Make Maintenance Harder

When traffic first started to slip, our first response was to publish more.

Over six months, we increased our article count by roughly 1.5x. We were working under the assumption that more articles would create more entry points.

But traffic did not recover.

Instead, another problem surfaced.

Because we had increased the publishing pace, each article received a thinner review. Post-publish maintenance was barely happening.

Here is what we found:

• On a case-study page published six months earlier, an external page we linked to had moved, leaving a broken link
• On another article, an embedded image had stopped displaying
• Old pricing and campaign details were still sitting alongside newer information

If AI uses a page like that as the basis for an answer, but the destination is broken or outdated, the opportunity is wasted.

Before creating more entry points, we needed to check whether the entry points we already had were in a condition worth citing.

---

Steps We Took to Change Our WebOps Process

The biggest change was this:

We stopped looking only at traffic volume and started regularly checking the condition of published pages.

STEP 1: Visualize the Current State of Key Pages

First, we identified the pages most likely to be referenced or cited: articles, case studies, service pages, and other important content.

Previously, we had focused heavily on pre-publish checks. But after publishing, we were not consistently checking whether links still worked, images still displayed, measurement tags were in place, or mobile layouts were still intact.

So we started using MONJI+ website anomaly detection to regularly crawl key pages.

We checked for issues such as:

• Broken links
• Failed image loads
• Missing SEO settings such as title and description
• Missing measurement tags
• Layout issues between desktop and mobile

The mobile issues were especially easy to miss.

Many pages looked fine on desktop but had broken images or links only on mobile. Because our own checks had leaned too heavily toward desktop, we had simply not seen them.

On the first pass alone, we found a double-digit number of issues across key pages.

STEP 2: Turn Checks into a Weekly Operational Process

Next, we made sure the detected issues did not end as one-off fixes.

When MONJI+ detected a problem, we filed it as feedback and fixed it. Then we recorded the work in our Wiki.

For each issue, we kept track of things like:

• Which page had the issue
• What was fixed, and when
• What to check next time to avoid repeating the same gap

This helped us see patterns.

For example, if a certain type of page often had mobile display issues, that became part of the next checklist. If broken links appeared repeatedly in older case studies, we knew where to look more carefully.

We began running key-page checks weekly.

As a result, we almost stopped discovering broken pages by accident months later. The gap between noticing and fixing issues shrank from months to about a week.

That was a clear operational change.

STEP 3: Use Several Months of Records to Explain and Improve the Work

We also changed how we used Google Analytics.

Previously, we mainly watched month-on-month search traffic. When traffic rose, we felt encouraged. When it fell, we worried.

But in an environment where search traffic may be structurally declining, that number alone did not lead to action. We could not easily tell whether a decline came from our own operations or from changes on the search side.

So we started using the MONJI+ Google Analytics integration to look at key pages individually.

Instead of focusing only on total traffic, we looked at:

• What changed before and after we fixed a page
• Whether time-on-page or navigation changed after an issue was resolved
• Whether the page remained in a condition worth citing
• Whether the same type of issue appeared again
• Whether we could explain what we had done and why

This also changed how we spoke with clients.

We used to say, “We will grow your search traffic.”

But as the search entry point itself changes, promising total volume no longer felt honest.

Now, we are more likely to say:

“We are not promising to raise rankings. We are keeping your pages from being broken when someone does arrive.”

At first, we worried that this might sound underwhelming.

But in many cases, clients found it easier to understand because the work was concrete. They could see what was being checked, what was being fixed, and what was being recorded.

---

What Actually Changed

This process did not immediately bring all search traffic back.

But it changed what we could see and control.

Before, we were reacting to month-on-month search traffic.
Now, we regularly check the condition of key pages, fix issues, and leave a record of what changed.

The biggest difference was how quickly we could notice problems.

Broken links, missing images, mobile layout issues, missing SEO settings, and missing measurement tags were no longer things we discovered months later by chance. They became issues we could catch through weekly checks.

It also made client communication more specific.

Instead of saying only, “We will increase search traffic,” we could explain the actual operational work:

“We regularly check key pages on desktop and mobile, detect broken links, image issues, missing SEO settings, and missing measurement tags, then record the fixes.”

In an AI search environment, we cannot control every entry point. But we can make the work we do control more visible, repeatable, and easier to explain.

---

Important Limits

This process does not control what AI says.

We cannot decide whether AI cites our site.
We cannot control how AI describes us in an answer.
We cannot guarantee search rankings.
And we cannot stop the broader shift toward zero-click searches or AI summaries.

What we can control is the condition of our own site.

When AI or readers arrive, we can make sure the page is not broken.
We can avoid leaving outdated information, broken links, or missing images unattended.
We can check key pages regularly and leave a record of what we fixed.

For us, that has become a practical first step for WebOps in the AI search era.

Rather than asking only, “How do we make AI cite us?” we now also ask:

“Is this page in a condition where it would be okay if AI or a reader arrived here today?”

---

MONJI+: A WebOps Platform Born on the Ground

The issues described in this article are not limited to one team.

Post-publish checks fall behind.
Pages look fine on desktop but break on mobile.
Broken links and images go unnoticed for months.
And when explaining WebOps work to clients, it can be hard to show what is being maintained on an ongoing basis.

MONJI+ is a WebOps platform born to solve these kinds of problems from the ground up.

MONJI+ brings the people involved in running a website together as one team, and helps solve challenges across every phase of website operations.

We never set out to build a “finished product” from day one.

The problems truly worth solving live in the day-to-day reality of website operations. That is why we have continued listening to real voices from the field.

By taking in those voices one by one, we have layered updates that resolve small points of friction. New features have also grown out of these operational challenges.

Through that accumulation, MONJI+ has become a product supported by users across 77 countries.

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

A world where the people running websites can say, with pride, “I love this work.”

▼ To make that real, we are listening for your voice
https://monji.tech/plus/co-creation/

---

Summary

When search traffic falls, it is tempting to publish more content first. We did that too. Over six months, we increased our article count by roughly 1.5x.

But traffic did not recover. Instead, our post-publish checks became thinner, and we ended up with more pages containing broken links, image issues, and outdated information.

So we changed our focus.

Rather than watching only the “volume” of search traffic, we started watching the “state” of published pages.

We now crawl key pages weekly on both desktop and mobile, detect broken links, broken images, missing SEO settings, and missing measurement tags, then file and fix those issues. We record what changed in the Wiki and use Google Analytics integration to look at the before-and-after of our work page by page.

We cannot decide what AI says.
We cannot guarantee that AI will cite us.
And we cannot stop the way search is changing.

But we can keep our own pages from being broken when AI or readers arrive.

In the AI search era, that may be one of the most practical places for WebOps teams to begin.