Publishing should be the last step in a controlled system, not the moment you discover a page is malformed.
That is the core reason validation belongs between generation and publication. Once a page is public, every defect becomes harder to unwind: bad metadata can be indexed, broken canonicals can pollute crawl signals, missing internal links can leave the page isolated, and thin or duplicated variants can enter the index before anyone notices. Pre-publication validation is the gate that turns content generation into a safe release process.
What validation is actually doing
For SEO pages, validation is not just spellchecking or approval. It is the process of confirming that a page instance is structurally publishable. A page can be perfectly written and still fail if its URL is unstable, its canonical points somewhere unexpected, its template is missing required fields, or its data source produced a combination that should never have existed in the first place.
A useful way to think about the system is this:
- Generation creates a draft page from source data, prompts, templates, or editorial input.
- Validation checks whether the draft satisfies the rules needed for indexable publication.
- Publication moves only approved pages into the live site, sitemap, and deployment workflow.
That middle step matters because it separates page creation from page release. If you skip it, your pipeline becomes a write-through system with no control surface.
If you are building the broader pipeline around this, the structure described in How to Build Programmatic SEO Pages is the right companion piece. This article focuses on the gate itself: what to validate, how to organize the checks, and how to decide whether a page is blocked, repaired, or published.
Validate the page against its intended type, not against a generic checklist
A validation system should know what kind of page it is approving. An ecommerce category page, a SaaS integration page, and a location page do not need the same rules. They may share a core schema, but their publish criteria should differ.
That means validation should start with page-type metadata: template name, content model, required fields, indexability policy, canonical source, and any business rules that make the page eligible. A page should not just be “valid” in the abstract; it should be valid for a specific page type and a specific search intent.
This is where a structured content model helps. If your lifecycle states are already explicit, as described in How to Model Content Status in an SEO CMS, validation can move a page from generated to ready_for_review, needs_fix, or approved without guessing what happened.
What the validation layer should check
The exact rule set will vary, but most systems need the same families of checks.
1. Structural completeness
A page should contain every field required by its template.
That usually includes:
- title tag and meta description
- H1
- canonical URL
- slug or route
- body content or rendered content blocks
- indexation directive
- internal-link targets, if links are injected automatically
- structured data fields, if the page type emits schema
A missing field should fail hard if the page cannot safely publish without it. Soft warnings are useful for non-blocking issues, but they should not blur the line between acceptable and unsafe.
2. URL and canonical integrity
The page must resolve to the right URL, and the canonical must match the publishing strategy.
This is more than checking for a string. Validation should confirm:
- the slug is normalized and unique
- no reserved path or collision exists
- the canonical is self-referential when intended
- canonical overrides are deliberate, not accidental
- parameterized duplicates are not being emitted as indexable pages
If you are managing canonical logic centrally, the patterns in How to Manage Canonical URLs at Scale are directly relevant here. Canonical errors are often easier to prevent than to repair after indexation.
3. Duplicate and near-duplicate detection
A page can be structurally complete and still be a bad candidate for publication if it too closely matches another page.
Validation should compare the draft against sibling pages and known canonicals. For programmatic systems, this often means checking whether the content changes materially across the fields that matter: headline, supporting copy, data modules, tables, FAQs, or inventory slices. If two pages differ only by a swapped city name or product label and everything else is identical, that is a signal to block, consolidate, or noindex.
A dedicated thin-content check is worth having here. How to Automatically Detect Thin SEO Pages covers the broader detection problem; pre-publication validation is the earlier, more conservative version of the same idea.
4. Internal linking readiness
A page should not publish into isolation unless that is intentional.
Validation can check whether the page has:
- at least one valid parent link
- related-page links that resolve to indexable URLs
- no links to drafts, redirects, or retired pages
- anchor text that matches the target page type and intent
This is especially useful when internal links are generated automatically. If you are already planning links before publishing, How to Plan Internal Links Before You Publish pairs naturally with this validation step. The validator should be the last chance to catch orphan-prone pages before they go live.
5. Schema and rendering sanity
Structured data should be validated as output, not just as input. A JSON-LD block that exists but contains empty values or invalid fields is not useful.
At minimum, confirm:
- the schema type matches the page type
- required properties are present
- values are in the right format
- rendered HTML contains the expected content blocks
- server-side or static rendering exposes the key fields you want crawlers to see
If the page is generated from a database or CMS, the validation layer should compare the source record to the rendered output. Mismatches are often how quiet publishing bugs survive.
6. Business-rule eligibility
Not every generated page deserves publication.
This is where you encode the rules that keep the site coherent:
- only publish if the underlying record is active
- only publish if there is enough unique source data
- only publish if the query demand or business value clears a threshold
- only publish if the page belongs to an approved site section
- only publish if its dependency graph is satisfied
These rules are often what distinguish a scalable publishing system from a content factory. They prevent the pipeline from producing pages simply because data exists.
Where the validation architecture should live
The best pattern is usually a separate validation service or validation stage, not a pile of checks buried inside the template.
That service should sit after generation and before publication, with access to:
- the draft page payload
- template metadata
- source record identifiers
- prior versions, if you support regeneration
- page-type rules
- related pages and canonical targets
- logs from any failed checks
A staged architecture gives you better control over failure modes:
- Deterministic checks can run first: required fields, URL rules, canonical rules, schema structure, link targets, and content length thresholds.
- Comparative checks can run next: duplication, uniqueness, sibling similarity, or template overuse.
- Human review can follow only when needed, rather than for every page.
That order matters. You do not want a reviewer spending time on a page that already fails a basic canonical or routing rule.
If your system also uses AI-generated drafts, a validation gate becomes even more important. The distinction between generation and publication is the same one described in How to Separate Content Generation From Publishing: generated output should remain non-public until it passes the controls that make publication safe.
Decide what happens when validation fails
A validation system is only useful if failure states are explicit.
A page that fails should be routed into one of a few outcomes:
- repairable automatically: missing metadata, malformed schema, broken internal link target, non-normalized slug
- repairable manually: weak differentiation, ambiguous canonical choice, incomplete source data
- terminal: the page should not exist, because the underlying record is not eligible or the combination is invalid
That classification prevents the queue from filling with vague “failed” items that nobody knows how to handle. It also keeps your publishing operation from silently retrying the same bad input.
The most useful validation systems leave an audit trail: which rule failed, what field triggered it, whether the page was retried, and who approved any override. That record is valuable both operationally and editorially.
A practical rule set is better than perfect coverage
It is tempting to build a validator that checks everything. In practice, that often produces a system nobody trusts because it is noisy, slow, or impossible to maintain.
A better approach is to start with the rules that prevent irreversible mistakes:
- bad URL or slug generation
- wrong canonical
- missing required metadata
- accidental duplicates
- broken indexability settings
- missing or malformed structured data
- orphaned publication state
Then add higher-level checks only if they change decisions. If a rule does not block a bad page, help a reviewer make a better decision, or prevent a repair cycle later, it is probably not worth automating yet.
That is the real job of validation: not to prove a page is perfect, but to make publication a deliberate action rather than a side effect of generation.
If you are thinking about the full system around this gate, How to Build Automated QA Gates for SEO Content is the broader pattern, and What Should an Automated SEO Content Validator Check? goes deeper into individual rule categories. Together with generation, publishing, and post-launch monitoring, they form the part of the stack that keeps scale from turning into drift.