In early 2025, Ezy Peazy looked healthy from the outside.
We were publishing localised blogs, building targeted service pages across New Zealand, improving our technical health, and following the SEO playbook that had worked for us for years.
But the numbers were telling a different story.
I’m writing this because we made a series of SEO decisions that looked logical at the time. Some worked. Some backfired badly. This is not a “look how smart we are” post. It is a founder-level post-mortem of what we changed, what the data showed, and what we are doing now to recover.
Our inputs were increasing, but our organic growth had started to flatten. In Google Search Console, our average position was broadly stable, which meant we were not simply “ranking lower”. The bigger issue was click-through rate. Impressions were still there, rankings were still there, but fewer people were clicking through to the site.
That was the first warning sign.
At the time, we saw it as a content and architecture problem. Looking back, it was probably a mix of three things:
This blog is the post-mortem of what we changed, what improved, what broke, and what we are now doing to recover.
This was the first major disconnect we had to understand: rankings were not falling in the same way clicks were falling.
For some informational queries, the search results had clearly changed. More answers were being surfaced directly on Google through featured snippets, richer SERP layouts, and AI-style summaries. In those cases, holding an average position was no longer enough. A page could still rank, still earn impressions, and still lose clicks.
That explained part of the decline, especially across blog and “how-to” content.
But it did not explain everything.
If the issue was only zero-click search, we would expect mostly informational pages to suffer. What concerned us was that the softness was also starting to affect the broader organic engine. That pushed us to look deeper into the structure of the site, not just the content we were publishing.
The following images shows even where average position and impressions remained relatively stable, clicks were trending down.
To understand whether this was only a SERP problem or also a site problem, we ran a deeper crawl in Sitebulb.
That audit showed us something we could not ignore: Ezy Peazy had become too scattered.
We had useful pages, but they were not always organised in a way that clearly supported our main commercial clusters. Service pages, suburb pages, completed task pages, worker profiles, and blog posts were all connected, but the relationships were not clean enough. In many places, the site did not clearly show which pages were the main hubs, which pages were supporting pages, and which pages were proof points.
In simple terms, we had content, but we did not have enough structure.
The first crawl visual made the problem obvious. The site had clusters, but many of them were loosely connected and difficult to interpret.
So we started consolidating. We tightened categories, improved parent-child relationships, and focused more internal links around the pages that mattered most commercially.
After the first round of changes, the crawl visual looked cleaner. The clusters were more defined, and the site started to look less like a scattered web and more like a structured marketplace.
Another round of tightenning, and we built a beautifully clustered architecture.
The result was encouraging.
After the first round of consolidation, organic traffic started to recover. The timing was hard to ignore. We had tightened the structure, improved the way clusters connected to each other, and made the site easier to understand from a crawl perspective. Soon after, the traffic trend began moving in the right direction.
That improvement gave us confidence.
In hindsight, maybe too much confidence.
We took the early recovery as a sign that the site needed even more cleanup. The lesson we learned later was more nuanced: better structure helped, but that did not mean every “messy” part of the marketplace was bad.
This was the moment where a good SEO decision slowly turned into an overcorrection.
The problem:
Organic growth had started to flatten. Average position was broadly stable, but CTR and clicks were weakening. Part of this looked like a SERP/zero-click issue, but the Sitebulb crawl also showed that our architecture was too scattered.
The idea:
Run a deeper crawl, tighten the site structure, improve cluster relationships, and use internal links to make our main service pages easier to understand.
Expected result:
Clearer topical clusters, ber commercial hubs, and better crawl paths between service pages, location pages, blogs, and marketplace proof.
Actual result:
Organic traffic started to recover after the first round of consolidation.
The lesson:
Structural consolidation can work, especially when a site has grown organically over time. But an early win can create a dangerous bias: you start believing that every messy page, link, or marketplace footprint is a problem to remove. For us, that belief became the start of the next mistake.
After the first round of consolidation worked, we made a much more aggressive call.
In May 2025, we looked at more than 10,000 completed task pages and 500+ worker profile pages and judged them mostly by their direct search performance. Across six months, those pages had generated roughly 72,000 impressions but only around 600 clicks.
On paper, the decision looked sensible.
The pages were thin in places. Many completed tasks had short descriptions, limited unique content, and low CTR. From a traditional crawl-budget mindset, they looked like clutter. We believed that by applying noindex to these pages, we would help Google focus more on our main service pages, city pages, and blog content.
In hindsight, this was the mistake.
We evaluated those pages as weak landing pages, but we underestimated their second job: they were marketplace proof.
They showed that real people were posting real jobs, real workers were completing them, and Ezy Peazy was not just an SEO-built service directory. By hiding them from search, we didn’t just remove low-performing pages. We reduced the visible evidence that our marketplace was active.
At the time, we thought we were trimming dead weight.
What we had actually done was start a site-wide stress test.
The first side effect was not rankings. It was performance visibility.
Many of the completed task pages were lightweight. They were not perfect pages from a content point of view, but they were relatively simple pages for crawlers and performance tools to process.
Once we removed thousands of them from the indexable part of the site, our reporting picture changed. The crawlable sample became more concentrated around our heavier pages: service pages, city pages, and blog content. These pages carried more JavaScript, more layout complexity, and more commercial components.
That exposed a problem we had not taken seriously enough.
Our average response time doubled.
This was the first uncomfortable lesson from the cleanup: removing weak pages can make a site look cleaner, but it can also expose problems that were previously hidden inside blended reporting. Ofcourse, that was a good discovery for the long run.
The noindex decision exposed a performance problem, so we moved into a technical sprint across July and August.
We focused on two areas.
First, speed optimisation.
We worked on the slower page templates that had become more visible after the noindex move, especially service pages, city pages, and blog pages.
Second, internal link engineering.
We improved the links between our consolidated money pages and started strengthening the relationships between parent services, sub-services, city pages, and supporting blogs. This was a big job because Ezy Peazy had more than 400 money pages across multiple clusters, so we could not complete everything in one sprint.
The result looked positive.
By September 2025, traffic had recovered and reached a new peak. From the outside, it looked like the strategy was working: fewer weak pages, faster templates, cleaner clusters, and stronger internal links between commercial pages.
Ahrefs also showed a healthier-looking trend during this period, which reinforced the belief that removing low-value pages had been the right move.
But this was where the data became dangerous.
The recovery made us believe the cleanup strategy was working as a whole. In reality, some parts were helping, especially speed and internal linking, while other parts were quietly weakening the site’s marketplace signals.
The September peak did not last.
Around the same period, Google rolled out major updates, and our traffic began a steady decline from its high point. We cannot say with certainty that one update caused the drop. SEO rarely gives that kind of clean evidence.
But the timing forced us to re-examine the strategy.
By this stage, Ezy Peazy looked much cleaner from a crawl and indexation point of view. The obvious clutter had been reduced. The site was faster. The clusters were tighter. Our commercial pages were better connected than before.
But something else had changed too.
The marketplace looked quieter.
From an E-E-A-T perspective, this mattered. Ezy Peazy’s strongest “Experience” signal was not a perfectly written blog post. It was the messy, real-world footprint of the marketplace: completed jobs, worker profiles, customer reviews, suburbs, job descriptions, questions, offers, and proof that people were actively using the platform.
By noindexing thousands of completed tasks and worker profiles, we may have reduced the visible evidence of that experience.
We had not removed the business activity itself. Customers were still posting jobs. Workers were still completing them. Reviews were still coming in. But from a search engine’s point of view, much of that proof had become harder to discover, crawl, and connect back to our core service pages.
That created a new hypothesis:
Maybe we had improved the site as an SEO structure, but weakened it as a marketplace entity.
In other words, we had made Ezy Peazy easier to crawl, but harder to verify.
The problem:
We saw more than 10,000 completed task pages and 500+ worker profiles as crawl bloat because their direct search performance looked weak. Across six months, they generated roughly 72,000 impressions and only around 600 clicks.
The idea:
Apply noindex to completed tasks and worker profiles so Google would spend more attention on our service pages, city pages, and blog content.
Expected result:
A cleaner index, better crawl efficiency, and stronger focus on the pages that mattered most commercially.
Actual result:
The cleanup exposed performance issues on our heavier page templates, and after the September peak, traffic began declining again. Our working hypothesis is that while the site became cleaner, it also lost some of the visible marketplace proof that supported our E-E-A-T and long-tail footprint.
The lesson:
Marketplace pages should not be judged only by their direct clicks. Some pages may look weak as standalone landing pages, but still play an important role as proof, internal-link sources, long-tail entry points, and experience signals. The answer is not to index everything or hide everything. The answer is selective indexation.
We did not noindex thousands of pages and simply hope for the best.
The strategy was more deliberate than that.
Our main service pages had always included live marketplace proof: recently completed tasks, customer reviews, worker activity, and examples of real jobs being done through Ezy Peazy. This was our “proof of life” section. It showed users that the marketplace was active, not just a set of static SEO landing pages.
In 2025, we tried to make that proof easier for search engines to understand by adding more structured data around it. The idea was to use schema to summarise the activity already visible on our money pages, especially around services, reviews, and completed work.
On paper, this made sense.
If our task pages were too thin to keep indexed at scale, maybe our service pages could carry the summary of that trust instead.
Our hypothesis was simple: could schema help us keep the authority of marketplace activity without keeping every marketplace page indexed?
We wanted the best of both worlds.
On page like Handyman Auckland , users could still see recent completed jobs, reviews, worker activity, and service-specific proof. By adding structured data around that information, we hoped search engines would better understand that these money pages were backed by real marketplace activity.
We were not trying to fake activity. The activity was real.
But we were trying to compress it.
Instead of allowing Google to index every thin completed task page, we wanted the main service pages to carry the summary of that proof. In our minds, schema could act like a bridge between the messy reality of the marketplace and the cleaner structure we wanted in search.
The problem was that schema is not a substitute for crawlable architecture.
It can help describe what exists on a page, but it does not replace the need for discoverable pages, followed links, and visible evidence that supports the claims being made.
For a few months, the traffic recovery made the strategy look like it was working.
But later, as traffic started declining again, we had to separate what was actually helping from what only looked helpful.
The speed improvements helped.
The cleaner clusters helped.
The stronger internal links between money pages helped.
But the schema layer could not fully replace the pages and links we had removed from the crawlable ecosystem.
There were two problems.
1. The verification gap
Our money pages still showed users recent tasks, reviews, and marketplace activity. That was good for trust and conversion.
But many of the deeper proof pages behind that activity were either noindexed, nofollowed, or harder for Google to treat as part of the public site architecture.
That created a gap between the summary and the evidence.
The service page could say, “Here is recent marketplace activity, ” and schema could help describe that activity. But if the supporting URLs were not indexable or followable, the wider proof network was much weaker than it looked on the surface.
2. The internal-link gap
Schema can help search engines understand content, but it does not replace internal links.
By noindexing and nofollowing large parts of the task/profile ecosystem, we reduced the natural flow of internal signals between completed work, worker expertise, service categories, suburbs, and money pages.
In practical terms, we had described the marketplace better in code, but weakened the crawlable wiring that connected the marketplace together.
That was the core failure of the schema bet.
We were trying to summarise our proof without keeping enough of the proof itself discoverable.
The problem:
We wanted to show high-frequency marketplace activity without keeping every completed task and worker profile indexed.
The idea:
Use structured data on our main service pages to summarise live tasks, reviews, and service activity, while keeping many of the individual task and profile pages noindexed.
Expected result:
A leaner index with the same perceived marketplace trust. In theory, our money pages would keep the benefit of recent jobs and reviews without the index bloat of thousands of thin supporting pages.
Actual result:
The schema layer helped describe the activity, but it could not replace the underlying crawlable proof. Once many of the supporting pages became noindexed, nofollowed, or harder to discover, the connection between our money pages and the marketplace activity behind them became weaker.
The lesson:
Structured data should reinforce visible, crawlable proof. It should not be used as a substitute for it. For a marketplace, the strongest trust signal is not only what is summarised on the money page, but whether the ecosystem behind that summary can be discovered, followed, and understood.
By late 2025, we had become obsessed with crawl control.
After the noindex and schema experiments, we looked again at the internal structure of the marketplace and saw another problem: the site had a huge internal link graph, but very little prioritisation.
Every completed task connected to multiple parts of the marketplace. A task linked to the customer who posted it and to several workers who had offered on the job. Worker profiles then linked back to many of their completed tasks. Those completed tasks linked out again, and the loop continued.
At scale, this created a massive multi-directional network of more than 100,000 internal links.
From a marketplace point of view, this made sense. It reflected the real activity happening on the platform.
From a crawl-prioritisation point of view, it looked messy.
In Google Search Console crawl data, we were seeing frequent crawler activity across task and user-profile URLs, while our commercial service pages and newer blog pages did not always appear to get the attention we wanted.
That led us to a dangerous conclusion.
We believed the spiderweb was trapping crawlers in low-value loops. We thought old tasks and profiles were consuming crawl attention that should have gone to our money pages.
So instead of improving the hierarchy, we tried to hide the maze.
To regain crawl control, we made a major technical change between December 2025 and January 2026.
We replaced thousands of standard HTML href links with JavaScript onclick events.
The thinking was simple: users could still move through the marketplace normally, but crawlers would be less likely to spend time following every task-to-profile and profile-to-task loop.
We wanted to guide Googlebot back toward the main roads of the site: service pages, city pages, sub-service pages, and supporting blogs.
But we underestimated the trade-off.
Those links were not just crawl paths. They were also context paths.
They helped search engines understand which workers had experience in which services, which jobs belonged to which categories, which suburbs had activity, and how completed work connected back to our commercial pages.
By turning too many of those links into JavaScript actions, we did not simply reduce crawl waste.
We weakened the internal map of the marketplace.
The impact became visible within weeks.
By May 2026, our search tools showed a major drop in internal connectivity. The number of detected internal links had fallen from more than 100,000 to around 28,000.
That was the moment the mistake became obvious.
We had not just cleaned the pipes. We had performed a site-wide bypass.
The pages were still there. The marketplace activity was still happening. Users could still navigate through the site. But the crawlable link graph that connected our marketplace together had been heavily reduced.
That created three problems.
1. Schema still could not carry the system
Structured data could describe activity, but it could not replace the internal links that connected tasks, workers, reviews, suburbs, and services.
2. Service pages became weaker hubs
Our money pages no longer had the same volume of supporting links and contextual signals coming from completed tasks and worker profiles. They became cleaner, but also more isolated.
3. The marketplace lost part of its crawlable pulse
A marketplace is not meant to look static. Its strength comes from repeated activity: jobs posted, offers made, workers hired, reviews left, and services completed across real locations. By cutting too many crawlable paths, we made that activity harder for search engines to follow.
The lesson was painful: internal links are not just navigation. They are the connective tissue that helps a marketplace prove what it does, where it does it, and who is doing the work.
The biggest loss was not only internal connectivity.
It was long-tail reach.
While we were focused on high-volume money pages like Handyman Auckland , we underestimated the search value of completed task pages.
In a marketplace, completed tasks are not just operational records. They can also act as landing pages for highly specific searches. A page about a real job, in a real suburb, with a real description, can match the kind of long-tail query that a polished service page never naturally targets.
For example, someone searching for something like “repair broken wooden fence gate in Ponsonby” is not always looking for a generic handyman page. They may be looking for evidence that someone has solved a similar problem nearby.
That is where completed task pages had value.
By noindexing many of them, and then reducing the crawlable links pointing through the task/profile ecosystem, we removed thousands of small search entry points. Individually, many of those pages did not look impressive. Collectively, they helped Ezy Peazy appear across a wide range of specific, messy, high-intent searches.
We had been trying to compete better on clean, high-volume keywords.
But in the process, we weakened our ability to capture the ugly long-tail queries that marketplaces are naturally good at winning.
The site became cleaner, but the keyword footprint became narrower.
The problem:
Ezy Peazy had a huge internal-link network across completed tasks, worker profiles, customers, services, and locations. We feared that this 100,000+ link graph was pulling crawl attention away from our most important money pages.
The idea:
Replace large numbers of standard HTML href links with JavaScript onclick events, so users could still navigate the marketplace while crawlers would be guided more strongly toward service pages, city pages, sub-service pages, and blogs.
Expected result:
A cleaner crawl path, less crawler waste, and more attention on our highest-value commercial pages.
Actual result:
Detected internal links dropped from more than 100,000 to around 28,000. The site became cleaner, but the marketplace became less connected. We weakened the crawlable relationships between tasks, workers, reviews, services, suburbs, and money pages. At the same time, we reduced our long-tail search footprint by removing or hiding many of the specific pages that matched messy, high-intent queries.
The lesson:
Internal links are not just crawl paths. They are relationship signals. For a marketplace, they show what work is being done, where it is happening, who is doing it, and which services those jobs support. Reducing crawl waste is smart, but cutting too much of the link graph can starve the site of the very signals that make it look active, trusted, and specific.
The better approach is not full exposure or full suppression. It is selective crawlability: keep the best proof discoverable, keep the weakest pages controlled, and make sure every valuable task or profile strengthens the right service cluster.
As of May 2026, we are no longer treating marketplace SEO as a simple cleanup exercise.
The mistake was not that we tried to improve crawl efficiency. That part still matters. The mistake was going too far in one direction: noindexing too broadly, relying too heavily on schema summaries, and reducing too many crawlable links across the task and worker ecosystem.
We are not planning to reverse everything blindly.
Indexing every task page would create the same quality and crawl problems we were originally trying to solve. But hiding almost everything removes too much proof, too much long-tail reach, and too many internal relationship signals.
So the new strategy is selective authority.
The goal is to expose the best parts of the marketplace to search engines while keeping weak, thin, or repetitive pages controlled. In other words, we want Google to see the strongest evidence of real activity without opening the floodgates to every low-value page.
This is the shift:
From “clean the index at all costs” to “make the best proof discoverable.”
To recover without recreating the original crawl-bloat problem, we are rebuilding the marketplace footprint around four principles.
1. Conditional indexing of “Gold” tasks
We are moving away from a binary rule where all completed tasks are either hidden or exposed.
Instead, completed task pages will earn indexation only when they meet a quality threshold. A task is more likely to be indexable if it has a clear job description, a completed outcome, useful location/service context, customer or worker signals, and enough detail to provide information gain.
A one-line completed task does not need to be in Google’s index.
But a detailed, real-world job that shows what was done, where it happened, and which service it relates to can become a valuable long-tail landing page and experience signal.
2. Vetted worker profiles
We are also being more selective with worker profiles.
Not every profile deserves to be crawlable. Empty, inactive, or low-proof profiles can weaken the site if they are opened to search at scale.
The profiles we want Google to discover are the ones that show real expertise: completed jobs, verified reviews, relevant service experience, and enough activity to prove that the worker is part of a functioning marketplace.
This turns worker profiles from thin user pages into evidence of experience.
3. Selective href restoration
We are restoring standard HTML links where they create useful SEO context.
That does not mean turning every old task/profile loop back on. The goal is to rebuild the crawlable paths that matter most: links from strong worker profiles to their best completed jobs, links from completed jobs to relevant service pages, and links between service clusters where the relationship is useful.
The deep archive can stay controlled.
The best proof should be crawlable. For example, a detailed completed furniture assembly job should support the relevant furniture assembly service page, not sit isolated from the commercial cluster.
4. Closing the authority loop
The final piece is making sure proof flows back to the right commercial pages.
A strong completed task should not sit alone. It should connect back to its parent service, relevant sub-service, and location where appropriate. For example, a high-quality fence repair task in Auckland should help reinforce the relevant fence repair, handyman, or Auckland service cluster.
This is how we turn marketplace activity into structured authority.
The task proves the work happened.
The worker profile proves who did it.
The review supports trust.
The internal links connect that proof back to the money page.
That is the recovery model.
Now we wait for the data.
The recovery plan is live, but we are not pretending the outcome is guaranteed. SEO does not work that cleanly, especially for a marketplace with thousands of moving parts.
What we do know is this: the old approach was too aggressive. We tried to solve crawl bloat by hiding too much of the marketplace. In doing so, we reduced some of the very signals that made Ezy Peazy useful, specific, and real.
The new approach is more selective.
We are restoring crawlable proof where it deserves to exist. We are keeping weak pages controlled. We are reconnecting strong completed tasks, vetted worker profiles, reviews, services, and locations into a cleaner internal structure.
Over the next few months, we will be watching:
This post is Part 1: the post-mortem. Part 2 will be the results: what recovered, what failed, and what we would still do differently.
For now, the lesson is simple:
A marketplace should not try to look too clean. Sometimes the messy proof is the moat.