After the Google Spam Update: What We Changed Across 1,300 pSEO Pages

Introduction

On May 5, 2026 we crawled our own site again: 1,316 pages, 1,270 URLs in the sitemap, 100% sitemap coverage and a 94/100 score in our internal SEO crawler. On paper, that looked healthy. The useful lesson was not the score. The crawler surfaced exactly the signals Google has become stricter about after recent spam updates: missing static params, thin utility pages, too much template overlap and pages that technically exist but still need stronger editorial value.

This is not a generic SEO checklist. It is a practical account of what we changed on a Next.js site with more than 1,300 crawled URLs, including pSEO pages, blog posts, tools, comparison tables and landing pages. The context matters: Google’s spam policies call out scaled content abuse. Not AI itself. Not pSEO itself. Content created at scale primarily to manipulate search results and offer little value. That distinction determines whether pSEO becomes an asset or a liability.

What changed in 2026?

"Google does not treat AI content as spam by default. The spam question is whether content is produced at scale to manipulate rankings while adding little user value."

— Summary of Google Search Central spam policies, reviewed in May 2026

Google defines scaled content abuse as content created at scale with the primary purpose of manipulating search rankings. The production method is secondary. AI can support a strong editorial process, but a generator that publishes hundreds of near-identical pages with only a city, tool or keyword swapped sits directly in the risk zone.

That is uncomfortable for companies running programmatic SEO because pSEO depends on repeatable structures. A comparison page, location page or template page naturally has fixed elements. The question is not whether templates may exist. The question is whether each page adds enough original, useful context on top of the template. A page about software development in Haarlem should not be the Breda page with the city name changed. It needs a separate reason to exist.

The first real fix: pre-rendered HTML for crawlers

The sharpest technical finding was not a writing problem. Our crawler reported that the dynamic Next.js `[locale]` segment had no `generateStaticParams` at layout level. That meant dozens of locale routes could render on demand instead of shipping fully pre-rendered HTML. For normal users, this can appear fine. For crawlers, AI indexers and fast snapshot tools, it is less reliable.

The fix was small but important: add `generateStaticParams()` to `src/app/[locale]/layout.tsx` with the supported locales (`nl` and `en`). That covers all descendant routes, from `/blog` to `/calculator` and `/tech-stack`. This is exactly the type of SEO issue traditional crawlers often miss. The page returns 200, the title is present, the sitemap is correct, yet the rendering strategy weakens what crawlers receive.

For clients using Next.js, App Router and international routes, we now check this by default. If you build pSEO or content hubs, request-time rendering should be a deliberate choice, not the accidental fallback. Pre-rendering gives crawlers faster, more stable and more complete HTML. That is not just SEO. It is reliability.

The second fix: move boilerplate down and unique value up

The crawler found four pages where boilerplate dominated too much of the visible text, including the blog index and an English alternatives hub. The top shared phrases came from recurring blocks: client projects, blog updates, navigation-like text and shared sections that appear across many pages. Not catastrophic, but a useful signal. When the first paragraphs of a page are mostly reusable blocks, the page looks less distinct.

Our fix was not to remove every shared component. That would hurt the user experience. We added unique intros and answer sections above or inside the primary content instead. Tool pages received concrete explanations of how the tool works, when to use it and where its limits are. The comparison matrix received extra sections on categories, scoring and update frequency. The calculator received explanation about pricing inputs and accuracy.

That is the core pSEO lesson: boilerplate is not forbidden, but it cannot carry the page. The template should provide structure. The unique content should provide the answer. If you reverse that order, you are creating scalable spam risk.

Why structured data is not cosmetic

Three routes lacked JSON-LD: tech-stack, careers and the comparison matrix. That sounds small next to 1,300 pages, but the pattern matters. Structured data tells search engines what the primary entity of a page is. A tool page is not just any web page. A careers page serves a different purpose than a blog post. A matrix is an interactive utility with its own context.

We added `WebPage` schema through the same schema factory used by the rest of the site. Not because JSON-LD guarantees rankings by itself, but because it creates consistency. On a large site, metadata cannot be improvised page by page. It needs to come from the same source as canonicals, hreflang and sitemap logic. Otherwise drift appears slowly: one page has correct schema, another does not; one uses the correct locale URL, another points to the wrong variant.

For custom software projects, this is where technical SEO and engineering meet. The problem is rarely that someone cannot write a meta description. The problem is that the software has no reliable system for producing SEO signals consistently. That is the type of tooling we build.

What we deliberately did not fix

A useful audit is not just a task list. It is also a filter. The same crawl reported hundreds of titles slightly above 60 characters and hundreds of meta descriptions slightly above 160 characters. That information is useful, but it is not a reason to cut good titles into worse ones. The audit itself called many cases borderline. We only fixed extreme cases, not everything.

The same applies to freshness. Some older blog posts had not been updated for more than a year. We could set every `updatedAt` value to today and make the audit greener. We did not. Google has warned for years against misleading freshness signals. Changing a date without a real revision is not a quality improvement. It is cosmetic. In 2026, that is exactly the behavior you do not want to automate.

The discipline is in not fixing everything. You want to solve technical errors quickly, improve content depth where pages are genuinely thin, and schedule editorial updates where facts are stale. You do not want to chase every SEO signal as if it is a bug. That makes sites less natural, not better.

Our anti-spam framework for pSEO in 2026

We now use five checks before a pSEO page is allowed to remain indexable. One: the page has a distinct search intent that does not fully overlap with another page. Two: the first 200 words contain specific context that does not come from the template. Three: internal links help the reader rather than merely distribute PageRank. Four: schema, canonical and hreflang are generated centrally. Five: the page has an owner, a date and a reason to stay current.

For location pages, that means local context. For comparisons, it means real trade-offs and criteria. For tools, it means explaining input, output and limitations. For templates, it means showing examples of use and mistakes people make in practice. The pattern is simple: every page must solve something a generic hub cannot solve.

If you already have pSEO, do not start with rewriting. Start with measurement. Crawl the site. Cluster pages by template. Look for duplicate body text, title overlap, thin pages, menu-only inbound links, missing schema and status codes. Then decide which templates need editorial work and which technical fixes can ship immediately.

When do you need custom tooling?

A standard SEO crawler is fine for small sites. With pSEO, multilingual Next.js projects or content programs with hundreds of pages, you quickly hit limits. You want to map source files to URLs, detect routes from the App Router, validate locale prefixes, compare sitemap coverage with crawl data and automate schema validation. That is software engineering, not a manual checklist.

At MG Software, we build this kind of internal tooling for ourselves and for clients. Sometimes it is a CLI running in CI. Sometimes it is a dashboard with trends per template. Sometimes it is a crawler that tells you exactly which file caused an issue. If your site is supposed to generate revenue, you do not want to discover these signals after rankings drop. You want to catch them before deployment.

If you operate a large content site, SaaS platform or pSEO program that matters for lead generation, technical SEO is not just a marketing task. It is an engineering task. Send us your situation. We will tell you honestly whether existing tools are enough or whether custom checks would reduce risk.

Conclusion

The 2026 Google spam update does not kill pSEO. It makes bad pSEO more expensive. Pages that exist only because a keyword appears in a database become more vulnerable. Pages built around clear intent, technical reliability and real editorial value remain defensible.

Our own audit showed that the biggest gains often come from the combination: rendering strategy, structured data, internal links, unique intros and editorial discipline. No single fix is magic. Together they make the difference between a scalable content system and scalable spam risk.