Before You Publish 500 AI Pages, Prove They Serve 500 Distinct Needs

Fast production can turn one useful idea into hundreds of interchangeable pages. Before publishing a batch, ask what each page helps someone do, what supports its answer, and what the reader can do with it. If the only defensible difference is the keyword, the batch is not ready.

“Distinct needs” does not mean 500 unrelated search intents or 500 different calls to action. Two buyers may ask the same question about different integrations and need separate, specific answers. The test is whether each URL makes a useful contribution—not whether its wording is unique.

For a founder or marketing leader approving AI content at scale, that changes the production brief. Do not start with how many pages the team can generate. Start with how many cases the available evidence can genuinely support.

What Google calls scaled content abuse

Google defines scaled content abuse as generating many pages primarily to manipulate search rankings rather than help users. Its policy focuses on large amounts of unoriginal content that provides little or no value, regardless of how it is created.

That is not a blanket ban on AI-written pages. Nor does adding a human editor automatically make a batch useful. The relevant distinction is purpose and value, not simply authorship.

Google’s generative-AI content guidance acknowledges useful applications such as research and structuring original content. It also warns that generating many pages without adding user value may violate the scaled content abuse policy. The guidance calls for manual fact-checking and review, including titles, descriptions, structured data and image alt text.

There is no safe page quota in that definition. Publishing 500 pages is not, by itself, proof of abuse; publishing fewer is not proof of quality. And an unhelpful page is not automatically evidence of a spam violation. Editorial usefulness and policy compliance are related questions, not interchangeable verdicts.

The practical job is to build a standard the team can apply before publication. The test below is an editorial release gate, not a Google scoring system or a ranking guarantee.

Give every proposed URL a reason to exist

Before generating the full batch, write one sentence for each proposed page:

This page helps [reader] complete [task] in [specific context], using [evidence or useful functionality], so they can [make progress].

Compare these two briefs:

Weak: “Target ‘CRM automation for manufacturers’ with a 1,200-word SEO page.”

Stronger: “Help a manufacturing sales-operations lead assess whether our CRM workflow can handle distributor handoffs, using a verified workflow example and documented limits, so they can decide what to test.”

The stronger brief creates an obligation. If the team does not have that workflow example or cannot verify the limits, it has found a research gap—not a reason to ask the model for more persuasive copy.

Rothenhall’s note on starting with a recognisable buyer problem makes the same distinction in messaging: a concrete situation gives the promise something to answer to. At page level, it gives the URL a reason to exist.

Use the task–evidence–action test

1. Task: what changes for this reader?

Name the question the page must resolve. “Learn about automation” is too broad. “Check which fields this integration synchronises and what happens when a record fails” is something a reader can complete.

Then identify the closest sibling page. Does the reader face a different decision, constraint or entity-specific question here? If the underlying task is shared, does this page provide the specific answer needed for this case?

A page about one software connector and a page about another may serve the same kind of task. Separate pages can still make sense because permissions, supported objects and setup steps differ. Conversely, “sales automation software,” “software for sales automation” and “automate sales software” may be three query variations for one useful answer.

Do not confuse a changed phrase with a changed need.

2. Evidence: what makes this answer defensible?

Identify the inputs before approving the prose. Depending on the page, these might include current product documentation, tested setup steps, a maintained dataset, a worked calculation or a properly scoped customer example.

Evidence need not be a new research study on every URL. A reliable structured record can support a useful templated page. What matters is that the inputs actually substantiate the answer and that the page adds value through their organisation, explanation or use.

Record the source, relevant version or date, and who owns verification. If a connector has not been tested, do not describe a successful setup as first-hand experience. If a capability is planned, do not let generated copy present it as available.

Google’s people-first content questions ask whether a page offers original information or analysis, adds substantial value rather than merely rewriting sources, and leaves readers with enough information to achieve their goal. A source link is useful; it is not a substitute for doing that work.

3. Action: what can someone do with the answer?

The action is not necessarily a conversion button. It might be checking compatibility, identifying a missing permission, calculating a cost or ruling out an unsuitable product.

Ask whether someone can make that progress on the page. If the headline promises setup instructions but the page offers only “book a demo,” it has postponed the task rather than answered it.

Multiple pages can share the same commercial call to action. They still need to deliver the answer that makes the next step informed. A shared “contact us” button neither proves nor disproves usefulness.

The principle also appears in Rothenhall’s buyer-learning path guide: organise material around the questions someone needs to resolve, then connect each answer to evidence and an appropriate next step.

Legitimate templates versus hollow variations

The examples below are hypothetical publishing decisions, not assessments of named companies or claims about ranking outcomes.

Integration pages: repeat the structure, not the answer

A software vendor uses one template for two CRM integrations: prerequisites, supported objects, field mapping, setup, failure handling and limitations.

That template can be useful when each page contains verified details for the actual integration. The reader can assess compatibility or follow the relevant setup path without reverse-engineering a generic explanation.

The hollow version swaps the platform name while repeating “connect your tools and streamline your workflow.” The page looks specific in search but becomes generic when opened.

Release question: Could a technical evaluator identify something this connector supports, requires or cannot do that is not established by the sibling page?

Industry pages: show a changed workflow, not a changed label

A workflow vendor proposes separate pages for distributors and professional-services firms. Both can use the same page design. Separate treatment earns its place if the workflows differ in meaningful ways—for example, order handoffs versus project approvals—and the vendor can show how its product handles those differences.

The hollow version changes the industry noun and adds an unsourced sentence about “unique challenges.” Identical benefits follow, with no explanation of what changes in implementation or fit.

Release question: What would the reader misunderstand if they used the other industry’s page instead? If nothing important changes, one stronger page with relevant examples may be enough.

Location pages: local usefulness has to be real

A service provider may have useful city pages where delivery areas, local teams, availability or service constraints genuinely differ. Those facts should be accurate and material to choosing or using the service. A city name in a testimonial is not, by itself, a local service proposition.

The hollow version creates a page for every city but offers no meaningful local information and funnels everyone toward the same generic destination. Google’s separate doorway abuse policy includes regional or city-targeted pages that funnel users to one page and substantially similar pages that function as intermediaries rather than useful destinations.

Release question: Does this page help a person assess the actual service in this location, or merely catch the location query?

A programmatic SEO quality checklist before release

Programmatic SEO uses templates and structured inputs to produce pages. That can organise useful information efficiently. It also makes a weak input or misleading claim repeatable. Review both the publishing system and the pages it produces.

1. Map every proposed URL. Record its reader task, nearest sibling, useful difference, supporting inputs and responsible owner. A blank “useful difference” is a reason to hold or combine the proposal, not generate filler.
2. Build contrasting examples first. Test each template on a well-supported case, a sparse case and an awkward exception. Do not approve a template solely from its best-looking output.
3. Define missing-data behaviour. Decide which fields are essential and when the system must withhold a page. Missing information must not become a plausible-sounding claim. An honest “not supported” answer may itself be useful when it is verified and explains the consequence.
4. Run the sibling-swap test. Exchange names, industries or locations with the nearest sibling. If most of the answer remains equally applicable and no important information is lost, investigate whether separate pages are justified. Shared explanations are fine; a whole page with no case-specific contribution is the warning.
5. Check claims and metadata. Review capabilities, prices, dates, sources and limitations, along with titles, descriptions, structured data and alt text. Automated checks can flag empty fields or repeated passages; they cannot establish that a buyer’s question has been answered.
6. Assign a release decision. Publish when the task, evidence and useful answer are clear. Combine overlapping proposals. Hold pages with missing proof. Drop keyword variations that add no reader value. Name who will maintain changing inputs after release.

Sampling can expose a broken template; it cannot certify every page in the batch. Check required inputs across the full proposed set, manually verify generated claims before publication, and give exceptions and higher-risk claims closer expert review. If the review capacity does not exist, reduce the batch.

There is no sensible universal percentage of “unique text” to aim for here. A short page with verified specifications may be more useful than a long, differently worded essay. Google also explicitly says it has no preferred word count in its people-first guidance.

Make volume the result, not the brief

A team that plans 500 pages and finds evidence for only 40 should not treat the remaining 460 as a copywriting problem. It has learned the current boundary of its coverage.

Publish the supported pages. Combine cases that share an answer. Research the important gaps. Leave the rest unpublished until there is a useful reason for someone to visit them.

After release, inspect whether pages help readers complete the intended task and where answers remain incomplete. Search Console clicks and impressions describe the site’s search performance, not total market demand or proof of user value. A quiet page is not automatically spam, just as an impression is not proof that its answer helped.

AI can reduce the time needed to draft and organise material. It cannot supply missing product facts, create evidence of customer outcomes or make interchangeable pages serve distinct needs.

Before approving 500 URLs, ask the team to show the task, the evidence and the useful answer behind each one. Let the page count follow what they can support.