Pre-Publish SEO Checklist

Pre-publish quality assurance (QA) is the final release gate in the SEO process . It is where three contracts meet: post-type conformance, correct element use, and completion of the preceding research, evidence, implementation, and review work. A page that fails any applicable item returns for correction.

Gate: final pre-publish QA. Timebox: 60–90 minutes for a standard page; add specialist time for regulated, security, financial, medical, or technically consequential claims. Owner: one editor, content lead, or SEO lead who did not make the final implementation and has authority to block release.

A soft checklist is not a checklist because “mostly done” has no stable meaning. Under deadline, optional wording becomes a memory aid and difficult checks disappear. Name the release authority before QA starts. The QA owner can pass or fail; only the named head of content, SEO lead, or equivalent can approve a written exception or rule an item inapplicable. They cannot waive a false claim, missing required element, placeholder asset, broken canonical, or blocked indexability to meet a date.

Why this gate exists, and why it runs here

This gate consumes the approved post-type specification, element contracts, source record, final copy, implemented candidate, and specialist approvals. It runs after those inputs are frozen because QA cannot verify a moving target, and before publication because a defect can be copied as soon as the URL is live.

Earlier QA certifies a draft that may change. Skipping it leaves later auditors unable to distinguish page drift, a changed specification, and a page never checked. Post-publication QA turns cheap corrections into public defects.

Inputs and outputs

The output is a contract, not a chat message. The publisher must be able to act on it without reconstructing the review.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

The checklist

Every item below includes the action, reason, method, tool, and observable done-when condition. “SEO checked” or “looks good” is never acceptable evidence.

1. Post type conformance

Confirm the selected post type and scope. What: match the candidate to one entry in the post-type library and remove material belonging to a sibling type. Why: page type determines intent, structure, evidence, and conversion behavior. How: label each section with the reader decision it supports and compare it with the type’s purpose and exclusions. Tool: approved brief, topical map, and post-type pages. Done when: exactly one primary type is recorded, the opening, body, and CTA serve it, and zero sections exist solely for another type’s job.

Trace required structure and word bands. What: map every required section to the rendered candidate and count its words against the specified band. Why: missing sections create unanswered questions, while uncontrolled length hides gaps behind volume. How: use a requirement-to-heading matrix and automated counts, then inspect boundary cases manually. Tool: post-type specification, source, and rendered page. Done when: zero required sections are missing and every section is inside its stated minimum and maximum.

2. Element conformance

Verify elements, positions, and parameters. What: compare the element map with source and render. Why: position and fields are part of function; a buried direct answer no longer answers first, and malformed parameters can break output. How: inspect top to bottom and validate allowed fields, values, nesting, and syntax. Tool: element specifications, validator, and browser. Done when: every mandatory element is in its required position, every parameter is valid, and no unexplained duplicate remains.

Enforce typed-element precedence. What: apply the element writing rules wherever a passage has a registered purpose. Why: free text may look similar but cannot carry the component identity, fields, accessibility behavior, or structured output. How: state each block’s job as a verb—define, warn, compare, instruct, summarize—and check for a matching element. Tool: element library and source inspector. Done when: zero passages use free text where a typed element is mandatory.

3. Content quality

Test the answer in isolation. What: read the direct answer block without its heading or surrounding paragraphs. Why: search and AI retrieval systems may extract only that passage. How: check that it names the subject, answers the question, includes necessary qualification, and does not rely on “this,” “it,” or “as above.” Tool: isolated text view and human reviewer. Done when: the answer is self-contained, accurate, and inside its specified 40–60-word band when that element is required.

Verify claims, language, and uniqueness. What: trace material claims to evidence, explain jargon on first use, and compare the candidate with pages serving the same intent. Why: unsupported claims damage trust, while near-duplicates compete and drift. How: flag names, dates, numbers, causal claims, product behavior, and similarity candidates; support, qualify, consolidate, or remove them. Tool: evidence register, primary sources, site search, and similarity report. Done when: zero material claims lack support, zero specialist terms remain unexplained, and no existing page answers the same intent and scope without a consolidation plan.

4. Frontmatter

Validate identity and preview fields. What: apply the frontmatter specification to title, description, keywords, entity, and post-type joins. Why: these fields drive routing, previews, schemas, and relationships without reading the body. How: run field and length validation, then compare meaning with the visible page. Tool: frontmatter linter and human preview. Done when: the title is unique and accurate, description is 150–160 characters, keywords contain 6–8 relevant entries, and entity matches the post-type contract.

Verify governance and FAQ fields. What: check dates, author, reviewer, ownership, and visible FAQ structure against frontmatter. Why: anonymous records prevent accountability, while FAQ drift makes visible and structured answers disagree. How: compare fields with the release trail and normalized visible text. Tool: source parser, tracker, and rendered page. Done when: required dates and owners are valid, the human reviewer is named where required, FAQ count meets the type minimum, every pair matches, and zero hidden or empty entries remain.

5. Structured data

Require the correct schema. What: confirm that applicable schema markup exists for the page and its visible elements. Why: missing or generic markup discards machine-readable meaning that the content model already provides. How: compare emitted types and properties with the post-type and element contracts. Tool: rendered HTML and schema validator. Done when: every required schema type is present once, required properties are populated, and no inapplicable type is emitted.

Validate parity, not only syntax. What: compare schema names, dates, author, entity, FAQ, steps, and claims with visible content. Why: valid syntax can still describe invisible or contradictory information. How: validate JSON-LD, then compare values with the page. Tool: structured-data test and human review. Done when: there are zero errors and zero facts in schema that contradict or exceed visible content.

6. Internal linking

Link up and out. What: provide a route to the relevant pillar and contextual routes to related nodes. Why: hierarchy helps readers and crawlers understand where the page belongs, while lateral links continue the reader’s task. How: map each internal link to a genuine next question rather than filling a quota. Tool: link graph and rendered page. Done when: the page has at least one link to its pillar, at least one relevant lateral link where a related node exists, and at least one existing page links into it before or at publication so it is not orphaned.

Inspect destinations and anchors. What: open every destination and review its anchor text . Why: a plausible URL may be missing, redirected, or unrelated, and generic labels hide the destination’s purpose. How: run an internal-link checker, then manually inspect anchors in sentence context. Tool: crawler and browser. Done when: zero internal links return an error, every destination supports the surrounding claim, and no standalone “click here,” raw URL, or misleading exact-match anchor remains.

7. Media

Verify assets, alternatives, and currency. What: confirm every image exists, has meaningful alt text or a justified empty alternative, and reflects the current interface. Why: broken, vague, placeholder, or stale media removes information and can make instructions unusable. How: disable images, inspect paths, reproduce product steps, and compare labels, values, cropping, and redaction. Tool: asset checker, accessibility audit, live product, and browser. Done when: zero assets are missing or placeholders, alternatives are accurate, and every screenshot represents the current step.

8. Technical release

Verify routing, indexability, and replacement. What: check slug, one self-referencing canonical URL , status, robots behavior, indexability , and redirects. Why: content cannot perform at the wrong route, behind noindex, or after old URLs are stranded. How: inspect the rendered head and response, compare the registry, and follow every replaced route. Tool: header checker, redirect map, source inspector, and URL inspection. Done when: the approved URL returns 200 with one intended canonical and no block; each replaced URL takes one permanent hop to the closest valid replacement.

Test mobile stability. What: inspect narrow-width reading, interaction, overflow, and Cumulative Layout Shift . Why: components that work on desktop can hide controls, clip tables, or move content as media loads. How: test representative mobile widths and load the page with throttling. Tool: browser device mode and performance report. Done when: all content and controls remain usable without horizontal page overflow and measured CLS is 0.1 or lower.

9. AI readiness

Test extraction and initial HTML. What: inspect answers, definitions, key facts, comparisons, and conclusions as independent passages in server-delivered HTML. Why: retrieval systems may select one passage and may not execute client-side code. How: fetch initial HTML, remove surrounding context, and check entity names, qualifiers, units, and pronouns. Tool: HTML fetch, passage extractor, browser, and AmICited audit. Done when: every priority fact is present without JavaScript and retains its subject, meaning, and limitations alone.

Expose procedural structure. What: verify that FAQ pairs and ordered steps are encoded as recognizable fields and remain visible. Why: headings and styled boxes can look correct while machines receive unstructured prose. How: compare element output, accessible structure, and schema with the visible sequence. Tool: accessibility tree and structured-data validator. Done when: every required FAQ is machine-readable as a question-answer pair and every required procedure preserves ordered steps in visible and structured output.

Tools in AmICited

Use the product to inspect the candidate and establish handoff evidence; it does not replace human judgment.

1. Open the agent-readiness audit alongside AI Accessibility and Agent Readiness to inspect accessibility, crawler reachability, sitemap coverage, and agent-readable content.
2. Inspect the candidate URL with URL Inspection to verify index status, mobile usability, and rich-results verdict. Assign live inspection in the handoff for a new URL.
3. Open the freshness audit with Content Freshness to give time-sensitive pages a maintenance signal and next review date. History starts when tracking begins; no history does not mean no change.
4. Use SEO MCP through the workspace connection for repeatable read-only URL, freshness, Web Vitals, and accessibility checks. Store the output or run identifier.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Automation: script the deterministic checks, preserve human decisions

A check that can be scripted but remains manual will be skipped under pressure. Automate stable, machine-observable results; require a human for purpose, truth, and context.

Automation writes evidence, not approval. Failure blocks the gate; a passing script does not pass the human columns.

Decision rules

“Bad” must be observable. Use these thresholds unless the selected post type or element defines a stricter one; the more specific contract wins.

N/A is not a softer pass. It is valid only when the item genuinely does not apply—for example, no redirect is needed because no URL is being replaced—and the record states why. An exception must name the changed rule, business reason, risk, approver, correction owner, and expiry. The release authority signs it; the QA reviewer does not self-approve it.

Deliverable: the pass record

Attach one immutable record to the exact candidate. A later audit must be able to distinguish “never checked” from “checked and passed under specification version 1.” Store structured fields rather than a screenshot of green checkmarks.

Page path / canonical:
Release candidate ID or content hash:
Post type and entity:
Specification version:
QA owner:
Release authority:
Started / completed (timestamp):

Checks:
- Group / item:
- Result: PASS | FAIL | N/A
- Evidence: validator output, source location, destination, or observation
- Checked by / at:

Exceptions:
- Rule and scope:
- Reason and risk:
- Approver:
- Correction owner / expiry:

Decision: PASS — PUBLISH | FAIL — HOLD
Live verification owner and deadline:
Next maintenance review date:

A pass record is append-only. A changed specification or candidate gets a new audit, not rewritten history.

What happens on failure

Failure starts a correction loop, not a negotiation in the review thread.

1. The QA owner marks the candidate FAIL — HOLD, records evidence, and stops at the point where continuing would test a version certain to change.
2. The content owner fixes post-type, element, copy, metadata, and evidence failures. The implementation owner fixes schema, links, media, routing, rendering, and automation failures. A specialist rechecks claims in their domain.
3. The fixer identifies every changed surface. The QA owner reruns the failed item, its dependent items, and any group affected by the change. A rewritten answer, for example, reopens claims, element conformance, schema parity, and AI extraction.
4. The QA owner creates a new timestamped result. Publication remains blocked until every applicable item passes and every N/A or exception has valid authority.

The author does not certify their correction. QA owns the record, production owns corrections, specialists own domain approval, and the release authority owns exceptions.

What goes wrong

• Treating the gate as proofreading. Grammar can be flawless while the page uses the wrong post type, contradicts its schema, or cannot be indexed.
• Testing source instead of the release candidate. Valid Markdown does not prove that templates emitted the intended canonical, accessible structure, or responsive layout.
• Making every item manual. Reviewers repeatedly click deterministic checks until a deadline teaches them to skip the list.
• Making every item automated. A green validator cannot decide whether evidence supports a causal claim or whether a comparison answers the reader’s decision.
• Accepting “will fix after launch.” That converts a pre-publish gate into an undocumented backlog and erases the meaning of PASS.
• Allowing the same person to implement and approve. Self-review misses assumptions because the reviewer remembers intended behavior rather than observing actual output.

Handoff

The next state is publication and live verification. QA hands over the approved candidate, PASS record, canonical route, redirect map, release window, and approved exceptions. The publisher returns the live URL and deployment time; the live-verification owner repeats status, canonical, indexability, redirects, schema, links, media, mobile, and CTA checks.

If production differs, affected checks reopen. If it matches, add the live URL and evidence without overwriting the candidate result. Later audits use the stored specification version to distinguish drift from a changed standard.

FAQ

Frequently asked questions

Pass means the candidate conforms to the current contract with inspectable evidence. Anything else is a hold. The academy layout’s closing CTA follows this FAQ.