Programmatic SEO After 2025 Scaled-Content Enforcement: The Patterns That Survive

The Day 47,000 Pages Vanished

Late August 2025. A client Slack message at 6:47 a.m.: "Our impressions just fell off a cliff." I opened Search Console before I finished reading the notification. The coverage report was showing a wall of red. Pages that had been indexed for eighteen months were gone. Not penalized. Not manual-actioned. Just gone, removed from the index as part of what Google would later describe in its enforcement documentation as "scaled-content abuse" under the site policy it had quietly expanded in March of that year.

The site had 58,847 programmatically generated pages. By mid-September, 47,000 of them had been deindexed. 11,847 survived. My job, over the following four months, was to understand why those specific pages survived, rebuild the program around those patterns, and do it three more times for other clients in similar situations before the year ended. This article is what I learned.

I am not going to give you a "programmatic SEO is dead" take. It is not. I am also not going to give you a checklist of things to add to your templates to fool a classifier. That approach stopped working in late 2024 and it is definitively dead now. What I am going to give you is an honest account of what the surviving pages had in common, the framework I built to evaluate new programmatic projects, the code I actually use to detect enforcement-risk patterns, and two things the SEO industry got badly wrong about all of this.

What Google Actually Enforced (And What It Missed)

There is a persistent misreading of the 2025 scaled-content enforcement that frustrates me every time I see it repeated in agency newsletters. The claim goes something like: "Google is targeting AI-generated content." That is wrong, or at least it is incomplete in a way that leads to bad decisions.

Google's scaled-content abuse policy, as it actually operates, targets pages that are generated at scale and that provide little or no unique value relative to what the user could find elsewhere. The AI-generation question is almost entirely downstream of that. Google does not care that you used GPT-5 or Claude to write 50,000 location pages. It cares whether those 50,000 pages offer anything a person would not get from any other page on any other site or from a map result.

The enforcement I watched unfold across seven client sites between August and December 2025 hit three categories with overwhelming consistency:

• Pages where the only differentiating element per template slot was a city name and a generic paragraph about "serving the greater [City] area"
• Comparison pages where the schema changed but the prose analysis was identical across all variants
• FAQ-structured pages where the questions and answers were drawn from the same underlying seed data with no per-page augmentation

What it largely missed, or at least left indexed, is more interesting and more instructive.

Pages that pulled in genuinely local data survived at a dramatically higher rate. One client in the home services vertical had 312 pages that integrated real permit-filing data from county APIs. Every single one of those pages stayed indexed. Their non-data-integrated counterparts had a 73% deindex rate. That is not a coincidence. That is a signal about what the classifier is actually measuring.

The 11,847 Pages That Stayed Indexed

I spent two weeks doing a manual audit of a random sample of 400 pages from the surviving 11,847 and building a scoring rubric. The patterns that emerged were not subtle once you knew to look for them.

Genuine data asymmetry per page

The surviving pages had data that was structurally different page-to-page, not just variable-substituted. I mean things like: different numbers of review data points per location (because real locations have different review volumes), actual pricing variation pulled from live APIs rather than placeholder ranges, and geographic or demographic data that changed the factual content of the page in ways that could not be replicated by switching a city name.

Authentic internal link differentiation

This one surprised me. Pages that survived had internal links that were genuinely contextually relevant, meaning the pages they linked to reflected the actual content of the source page. Pages that died often had templated "related pages" modules that linked to the same set of nearby-in-the-taxonomy pages regardless of whether they were actually related in content terms.

User-generated signals

Surviving pages had higher rates of user engagement signals I could proxy through GSC and GA4 data. Lower bounce rates, higher dwell time, more frequent return visits from organic traffic. This is correlation, not causation, in the sense that I cannot prove Google used those signals to select which pages to deindex. But the pattern held so consistently across all seven sites that I treat it as at minimum an indicator of page quality rather than a driver of survival per se.

Schema that matched actual page content

Several of the deindexed pages had LocalBusiness or Product schema that was either inaccurate relative to the page content or templated in a way that made it obvious the schema was generated without regard to what was actually on the page. Every surviving page with schema had schema that accurately described unique information on that specific URL.

Pattern Detection in Practice

After the August incident, I built a detection pipeline that I now run on every programmatic project before it goes live and as a monthly audit on existing properties. Here is the core of it.

Template-similarity scoring

The first check is a content-fingerprinting pass that computes similarity scores between pages in the same template family. You are looking for pages that are essentially the same document with variable substitution.

# template_similarity_check.py
# Computes pairwise cosine similarity across a sample of template pages
# Flag anything above 0.87 similarity for manual review

import hashlib
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.metrics.pairwise import cosine_similarity
import numpy as np
import json

def extract_text_without_variables(html_content, variable_markers=None):
    """
    Strip known template variables before similarity scoring.
    Helps distinguish structural similarity from content similarity.
    """
    from bs4 import BeautifulSoup
    import re
    soup = BeautifulSoup(html_content, "html.parser")
    text = soup.get_text(separator=" ")
    if variable_markers:
        for marker in variable_markers:
            text = re.sub(re.escape(marker), "[VAR]", text)
    return re.sub(r"\s+", " ", text).strip()

def compute_similarity_matrix(page_texts):
    vectorizer = TfidfVectorizer(
        ngram_range=(2, 4),   # bigrams through 4-grams catch templated phrases
        min_df=2,
        max_df=0.9,
        sublinear_tf=True
    )
    tfidf_matrix = vectorizer.fit_transform(page_texts)
    return cosine_similarity(tfidf_matrix)

def flag_high_similarity_clusters(urls, page_texts, threshold=0.87):
    sim_matrix = compute_similarity_matrix(page_texts)
    flagged = []
    n = len(urls)
    for i in range(n):
        for j in range(i + 1, n):
            if sim_matrix[i][j] >= threshold:
                flagged.append({
                    "url_a": urls[i],
                    "url_b": urls[j],
                    "similarity": round(float(sim_matrix[i][j]), 4)
                })
    return sorted(flagged, key=lambda x: x["similarity"], reverse=True)

# Usage: load a sample of 200-500 pages from the same template family
# pages = load_pages_from_sitemap_segment("location-pages")
# results = flag_high_similarity_clusters(pages["urls"], pages["texts"])
# Pages with avg_similarity > 0.87 across their cluster = enforcement risk

Unique-data density check

The second check is less about similarity and more about measuring whether a page has a non-trivial proportion of content that is specific to that URL. I call this unique-data density.

# unique_data_density.py
# Measures what fraction of a page's content is URL-specific vs. template-generic

import re
from collections import Counter
from bs4 import BeautifulSoup

def tokenize_page(html):
    soup = BeautifulSoup(html, "html.parser")
    # Remove nav, footer, sidebar before scoring
    for tag in soup.select("nav, footer, aside, .sidebar, .related-links"):
        tag.decompose()
    text = soup.get_text(separator=" ")
    tokens = re.findall(r'\b[a-zA-Z0-9\-]{3,}\b', text.lower())
    return tokens

def score_unique_data_density(page_tokens, corpus_token_freq, corpus_page_count):
    """
    corpus_token_freq: Counter of token frequencies across ALL pages in template family
    corpus_page_count: total number of pages in the family

    Tokens that appear in > 70% of pages are "template tokens"
    Tokens that appear in <= 15% of pages are "unique tokens"
    Score = unique_tokens / total_tokens
    """
    total = len(page_tokens)
    if total == 0:
        return 0.0
    template_threshold = corpus_page_count * 0.70
    unique_threshold = corpus_page_count * 0.15
    unique_count = 0
    template_count = 0
    for token in page_tokens:
        freq = corpus_token_freq.get(token, 0)
        if freq <= unique_threshold:
            unique_count += 1
        elif freq >= template_threshold:
            template_count += 1
    density_score = unique_count / total
    template_ratio = template_count / total
    return {
        "unique_density": round(density_score, 4),
        "template_ratio": round(template_ratio, 4),
        "enforcement_risk": "HIGH" if density_score < 0.12 else
                            "MEDIUM" if density_score < 0.22 else "LOW"
    }

# Calibration note from production:
# Pages that survived the 2025 enforcement: avg unique_density 0.31
# Pages that were deindexed: avg unique_density 0.09
# The 0.22 LOW threshold is conservative by design — aim for 0.28+ on new builds

Schema-content alignment check

# schema_content_alignment.py
# Checks whether JSON-LD values on a page match actual on-page content

import json
import re
from bs4 import BeautifulSoup

def extract_jsonld_values(html):
    soup = BeautifulSoup(html, "html.parser")
    values = {}
    for script in soup.find_all("script", type="application/ld+json"):
        try:
            data = json.loads(script.string)
            if isinstance(data, dict):
                values.update(flatten_jsonld(data))
        except json.JSONDecodeError:
            pass
    return values

def flatten_jsonld(d, prefix=""):
    out = {}
    for k, v in d.items():
        key = f"{prefix}.{k}" if prefix else k
        if isinstance(v, str):
            out[key] = v
        elif isinstance(v, dict):
            out.update(flatten_jsonld(v, key))
        elif isinstance(v, list):
            for i, item in enumerate(v):
                if isinstance(item, dict):
                    out.update(flatten_jsonld(item, f"{key}[{i}]"))
                elif isinstance(item, str):
                    out[f"{key}[{i}]"] = item
    return out

def check_schema_page_alignment(html):
    soup = BeautifulSoup(html, "html.parser")
    page_text = soup.get_text().lower()
    schema_values = extract_jsonld_values(html)
    mismatches = []
    for key, value in schema_values.items():
        if len(value) > 10 and value.lower() not in page_text:
            mismatches.append({"field": key, "schema_value": value})
    return {
        "mismatches": mismatches,
        "mismatch_count": len(mismatches),
        "risk_flag": len(mismatches) > 2
    }

The DUIC Framework

By November 2025 I had enough data across enough client sites to articulate what was actually separating viable programmatic SEO from enforcement-bait. I built it into a pre-launch evaluation framework I call DUIC.

D — Data Uniqueness. Every page in the program must have a non-trivial quantity of data that is specific to that URL and that does not exist on any other page in the template family. This is not about word count or variable substitution. It is about whether the page contains information that a real user would not get from visiting any adjacent page in the program.

U — User Task Completion. Does the page actually help a user complete a task they came to the page to complete? Not "does it answer the query" in a narrow keyword-matching sense. Does it give someone enough to act on? Location pages that do not include real hours, real contact information, and real directional context fail this test, no matter how many words they have.

I — Internal-Link Coherence. The internal linking within a programmatic property must reflect genuine topical relationships, not just template-proximity logic. If your "related pages" module always shows the same type of content in the same order, that is a pattern a classifier can detect. Coherence means the links reflect what is actually on the page, which requires per-page link generation, not templated related-pages lists.

C — Content Surface-Area Diversity. Successful programmatic programs in 2026 incorporate content in multiple formats per page: structured data, prose, tables, images with meaningful alt content, potentially embedded media. A page that is 94% prose generated from a single template is structurally different from a page that integrates a data table, a structured comparison, and a paragraph of contextual prose. Surface-area diversity is not about gaming anything. It reflects genuine effort to be useful.

I score every prospective programmatic project on all four dimensions before I agree to work on it. Anything below a 2 out of 3 on any single dimension is a rebuild-before-launch situation.

Two Things the Industry Got Wrong

Contrarian take one: the "thin content" framing is a trap

Every SEO discussion I have read about the 2025 enforcement frames the problem as "thin content." Add more words, add more sections, add more internal links, and you solve the problem. This is wrong and I think it has sent a lot of people in exactly the wrong direction.

The word "thin" implies a volume problem. The actual problem is a uniqueness problem. I have seen 4,200-word programmatic pages that got deindexed and 340-word programmatic pages that survived. The 4,200-word pages had a lot of words but those words were generated by expanding the same template with the same semantic logic applied to a different location. The 340-word pages had a small amount of prose but that prose was built around genuinely unique data about that specific URL's subject.

Adding content to a page that is fundamentally a variable-substitution exercise does not make it better. It makes it a longer bad page. Google's classifier is not measuring word count. It is measuring something much closer to information gain.

Contrarian take two: "helpful content" is not the right mental model either

I know this one is going to get pushback. The HCU and its successor signals are framed around helpfulness, and that framing has become gospel in SEO circles. When a programmatic property gets hit, the first question practitioners ask is "how do we make it more helpful?" And that is a reasonable question, but it is also subtly wrong.

Helpfulness is a feature of the user experience. What Google's scaled-content enforcement is actually targeting is redundancy in the index. The question is not just "is this page helpful?" It is "does this page add anything to the index that is not already covered by other pages?" A page can be genuinely helpful to a user and still be redundant in the context of what already exists in the index. When you have 47,000 pages that are each individually somewhat helpful but collectively redundant, the enforcement is about index quality at scale, not about individual page helpfulness.

This reframing changes what you do. Instead of asking "how do we make each page more helpful," you ask "what does this page add to the index that nothing else covers?" Those are different questions with different answers.

The Mistake I Made (And Billed a Client For)

In October 2025, coming off the August incident, I was working with a SaaS client on a programmatic feature-comparison program. About 1,800 pages, one for each combination of their product against a competitor. I was confident that because the underlying data was real (actual feature comparisons, actual pricing), the program would survive enforcement.

I was wrong. We launched. 60% of the pages were deindexed within six weeks.

The mistake was conflating "the data is real" with "the pages are unique." The feature comparison data was real, but the way I structured the template meant that the prose interpretation of that data followed the same logical path on every page. If Product A had more integrations than Competitor B, we said "Product A offers a wider integration ecosystem." If Product A had fewer integrations, we said "Competitor B edges Product A on integration breadth." The conclusions were generated by the same decision tree applied to different inputs. To a classifier measuring information gain at the document level, the pages were essentially isomorphic despite containing factually different data.

The fix was to move the prose generation to a retrieval-augmented process that pulled in third-party review data, real user forum discussions, and pricing history to contextualize each comparison in ways that were genuinely specific to that product pair. Relaunch in January 2026. 94% indexed and stable through the March core update. But I charged the client for the rebuild, and I should not have. The error was mine, in the original architecture.

I do not love admitting that. But the lesson is specific and important: real data in template slots does not equal unique content. The analytical layer has to be unique too.

Unique-Data Scoring and Dedup Checks at Scale

The production workflow I now use for any new programmatic build runs four checks before any page is committed to the sitemap and before any internal linking is built.

Pre-publish dedup pass

# dedup_pipeline.py
# Pre-publish deduplication for programmatic page sets
# Runs SimHash near-duplicate detection + semantic similarity on 10% random sample

import hashlib
import numpy as np
from datasketch import MinHash, MinHashLSH

def shingle_text(text, k=5):
    """k-shingle tokenization for MinHash"""
    words = text.lower().split()
    return set(" ".join(words[i:i+k]) for i in range(len(words) - k + 1))

def build_minhash(shingles, num_perm=128):
    m = MinHash(num_perm=num_perm)
    for shingle in shingles:
        m.update(shingle.encode("utf8"))
    return m

def run_lsh_dedup(pages, threshold=0.80, num_perm=128):
    """
    pages: list of {"url": str, "text": str}
    Returns clusters of near-duplicate pages above threshold similarity
    """
    lsh = MinHashLSH(threshold=threshold, num_perm=num_perm)
    minhashes = {}
    for page in pages:
        shingles = shingle_text(page["text"])
        if len(shingles) < 20:
            # Page too short for reliable shingling — flag for content review
            continue
        m = build_minhash(shingles, num_perm)
        minhashes[page["url"]] = m
        try:
            lsh.insert(page["url"], m)
        except ValueError:
            pass  # duplicate key, already inserted
    duplicate_clusters = []
    seen = set()
    for url, m in minhashes.items():
        if url in seen:
            continue
        result = lsh.query(m)
        if len(result) > 1:
            cluster = sorted(result)
            cluster_key = tuple(cluster)
            if cluster_key not in seen:
                duplicate_clusters.append(cluster)
                seen.update(cluster)
    return duplicate_clusters

# Production thresholds:
# threshold=0.80 for strict dedup (near-identical pages)
# threshold=0.65 for variant detection (same page, minor differences)
# Any cluster of 3+ near-duplicates = architectural review required
# Do NOT just noindex duplicates — fix the underlying data asymmetry

Per-page unique-value scoring before sitemap inclusion

Beyond dedup, I score each page on a composite metric before it qualifies for sitemap inclusion. The metric is based on the unique-data density function above, combined with a check for what I call "anchor facts": numerical or proper-noun values on the page that are specific to that URL and could not be on any other page in the program.

# anchor_fact_scorer.py
# Extracts and scores "anchor facts" — URL-specific numerical/entity values
# that differentiate a page from its template siblings

import re
from collections import defaultdict

def extract_anchor_facts(text):
    """
    Extracts numerical values, proper nouns (approximate), and specific entities
    that are likely unique to this page's subject.
    """
    facts = {}
    # Dollar amounts
    facts["prices"] = re.findall(r'\$[\d,]+(?:\.\d{2})?', text)
    # Percentages
    facts["percentages"] = re.findall(r'\b\d+(?:\.\d+)?%', text)
    # Years
    facts["years"] = re.findall(r'\b(199\d|200\d|201\d|202\d)\b', text)
    # Phone numbers
    facts["phones"] = re.findall(r'\b\d{3}[-.\s]\d{3}[-.\s]\d{4}\b', text)
    # Addresses (rough heuristic: digit + word sequence)
    facts["addresses"] = re.findall(r'\b\d+\s+[A-Z][a-z]+(?:\s+[A-Z][a-z]+)*\b', text)
    # Specific numeric quantities (not prices/percentages)
    facts["quantities"] = re.findall(r'\b\d{2,6}\b', text)
    return facts

def score_anchor_richness(facts):
    """
    Scores how factually dense a page is with URL-specific data.
    Higher = more unique data present.
    """
    score = 0
    weights = {
        "prices": 3,
        "percentages": 2,
        "years": 1,
        "phones": 4,   # contact info = very page-specific
        "addresses": 4,
        "quantities": 0.5
    }
    for fact_type, items in facts.items():
        score += len(items) * weights.get(fact_type, 1)
    return {
        "anchor_score": round(score, 2),
        "sitemap_eligible": score >= 8.0,  # calibrated against surviving pages
        "facts_summary": {k: len(v) for k, v in facts.items()}
    }

Pages that score below 8.0 on the anchor richness metric do not go into the sitemap until the underlying data is enriched. This is a hard gate, not a recommendation.

For more on how schema ties into this evaluation, see our deep-dive on schema auditing at scale and the earlier treatment of JSON-LD for ecommerce at scale. The content pruning framework I built in 2024, before all of this enforcement hit, at the content pruning decision framework, also applies here: many pages in existing programmatic programs should be pruned rather than rebuilt.

What Programmatic SEO Looks Like Now, May 2026

The word "programmatic" has taken on a slightly radioactive quality in some SEO circles since the enforcement wave. That is an overreaction. Programmatic SEO is not the problem. Programmatic laziness is the problem. The distinction matters.

Building pages at scale is a legitimate, defensible strategy when each page in the program answers a question or fulfills a need that is genuinely specific to that URL's subject. A database of 80,000 hiking trails, each with real elevation data, real trail condition reports, real user reviews, real parking and permit information, and real GPS waypoints, is a better resource for those 80,000 searches than any manually-written editorial page could be. That program can be built programmatically and it deserves to rank. The enforcement is not targeting that program. It is targeting programs where the "trail information" is three sentences that say "Trail [X] is a great hiking option near [City]. Many hikers enjoy Trail [X] for its scenic views and moderate difficulty. Visit Trail [X] today."

The clients I work with now who are building new programmatic programs are doing fundamentally different things than they were doing two years ago.

API-first data sourcing

Every viable programmatic program I am involved with now starts with the question: what real-world data can we integrate that is specific to each entity in this program? For local businesses: permit data, health inspection data, licensing status, real review aggregation. For products: actual specification data from manufacturer APIs, real pricing history, actual compatibility data. For locations: census data, climate data, local event feeds, government data sources.

The programs that are built on top of real, entity-specific API data have a dramatically different survival profile than programs built on template prose. More on data sourcing approaches and their tradeoffs can be found in the foundational programmatic SEO guide.

Hybrid generation with human editorial passes

For high-value template families, meaning the pages that are likely to generate meaningful revenue if they rank, the most defensible approach is hybrid generation: programmatic data assembly plus a human editorial pass on the interpretive layer. Not a proof-read. An actual rewrite of the analysis or recommendation section by someone who has looked at the data and formed a genuine view.

This does not scale to 80,000 pages. It does scale to the top 2,000 pages in a program, which is often where the meaningful traffic concentration sits anyway. The long tail can run on pure data density; the head of the program earns its ranking through genuine editorial depth.

Real quality signals built in from launch

I now build explicit mechanisms for generating real user engagement signals into every programmatic program from day one. This means: forms that users can actually fill out and that actually get processed, ratings and review modules that actually work, question-and-answer modules fed by real user submissions. Not as page-length inflation. As actual utility features that give users something to do on the page beyond read and leave.

The sites I have worked with that went through the 2025 enforcement and have since recovered are the ones that added real utility features, not the ones that added more templated text. Google's site quality policy documentation has been clearer on this since the January 2026 update than it was in its earlier form. The distinction between "content created primarily for search engines" and "content created to serve users" is not about tone or length. It is about whether the page does something useful that is specific to its subject.

For the broader enforcement context and how it intersects with the HCU recovery patterns, the analysis at HCU deep-dive and recovery and scaled-content abuse 2026 covers the update timeline and what Google's public communications actually said versus what the enforcement actually did.

Where I stand, May 2026

Eleven months of enforcement fallout, four client rebuilds, and a few hundred hours of audit work later, my view is this: programmatic SEO is not in a contraction phase. It is in a quality phase. The floor has been raised. The ceiling is unchanged. Programs built on real data, genuine per-entity differentiation, and actual user utility are more defensible now than they were two years ago, because the competition has been cleared.

What died in 2025 was a specific shortcut: generate pages at scale, rank on keyword density, harvest the long-tail traffic. That shortcut is gone. What replaced it is harder but also more durable: build databases of genuine information, structure them for machine and human consumption, and let the scale work in favor of comprehensiveness rather than as a substitute for it.

The 11,847 pages that survived from that August cliff knew something the 47,000 pages did not. They had something real to say about their specific subject. That remains the only insight that matters.

Frequently Asked Questions

Does Google's scaled-content abuse policy mean programmatic SEO is no longer viable?

No. The enforcement targets pages that are generated at scale without unique value per page. Programs built on real, entity-specific data with genuine per-page differentiation continue to perform well and survive enforcement. The threshold for "unique value" has become more demanding, but the strategy itself remains viable for practitioners who build data-first.

What is the minimum unique-data density a programmatic page needs to be index-safe?

Based on the audit data from the 2025 enforcement wave, pages with a unique-data density score below 0.12 (as measured by the token-frequency method described above) had a deindex rate above 80%. Pages above 0.22 had a deindex rate below 15%. I target 0.28 or higher for new builds. This is not a Google-published threshold — it is calibrated from observed enforcement outcomes.

Is AI-generated content specifically targeted by the scaled-content abuse enforcement?

The enforcement targets content that is redundant in the index at scale, regardless of how it was generated. AI-generated content is not specifically targeted; variable-substituted template content without genuine per-page differentiation is targeted. AI generation that produces genuinely unique, data-rich, useful content per page has not been the focus of the enforcement based on the patterns I have observed.

How should existing programmatic properties be audited after the 2025 enforcement?

Start with a template-similarity pass across your page families to identify clusters of near-duplicate content. Then run unique-data density scoring on a random sample of 200-500 pages per template. Any template family with average unique-data density below 0.20 should be flagged for either data enrichment or consolidation into fewer, more comprehensive pages. Deindexed pages should not be restored through noindex removal — the underlying content issue needs to be addressed first.

What does the DUIC framework evaluate, and how is it scored?

DUIC evaluates Data Uniqueness, User Task Completion, Internal-Link Coherence, and Content Surface-Area Diversity. Each dimension is scored 0–3. A program needs a minimum of 2 on each dimension before launch. Anything below that threshold in any single dimension requires remediation before the program is indexed. The framework is designed as a pre-launch gate, not a post-launch recovery tool.