Process Page Template

A pre-publish QA gate exists because errors become more expensive after a page is indexed, linked, cited, translated, or reused in another answer. The gate is not a final proofreading pass. It is the point where one accountable owner verifies that the page still matches its brief, its evidence is inspectable, its components satisfy their contracts, and the published result can be measured and maintained. This reference demonstrates all ten blocks in the locked process/checklist template.

Phase: final review before publication. Timebox: 45–90 minutes for a standard detail page, extended when a specialist must verify legal, medical, financial, security, or technical claims. Owner: an editor or content lead who did not write the final draft and has authority to block release.

Why this phase comes here

Production separates work across research, briefing, writing, design, subject review, and implementation. Each handoff can preserve local quality while weakening the page as a whole. A writer may follow the brief but use outdated evidence. A designer may create a polished table whose columns no longer compare the same dimension. An implementer may introduce a broken link or malformed JSON. The pre-publish gate recombines those outputs and tests the actual release candidate.

It comes after content, component, evidence, and specialist reviews because QA cannot verify missing work. It comes before publication because that is the last cheap point to correct a title, source, route, schema field, capture, or conversion path. Moving QA earlier creates false confidence; moving it after release turns preventable defects into public incidents.

The phase depends on an approved brief and produces a recorded release decision. If either is missing, the checklist becomes subjective: reviewers debate taste because the intended reader, page job, evidence standard, and done-when rules were never fixed.

Inputs and outputs

Inputs and outputs make the phase auditable. An input is material the reviewer needs to evaluate the candidate. An output is evidence another person can use without repeating the entire review.

QA inputs and outputs

An input is not accepted merely because a file exists. The brief must describe this page, the evidence register must cover the claims actually present, and specialist approval must refer to the candidate being released.

Ready to Monitor Your AI Visibility?

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

Get Started Contact

The checklist

Order reduces rework. Review page purpose before sentence polish, evidence before styling, structure before links, and implementation before the final release decision. A failure early in the sequence may return the page to production; there is no value in perfecting alt text for a page whose intent and comparison frame are wrong.

1. 1
   1. Match the brief

   What: compare the candidate with the approved reader, intent, page type, required blocks, and outcome. Why: a polished page solving the wrong problem should not ship. How: trace each requirement to a visible section or approved exception. Tool: brief and rendered candidate. Done when: every required block has a location and the opening answers the named need.
2. 2
   2. Verify claims and scope

   What: check factual claims, dates, units, versions, plans, markets, and limitations. Why: unsupported or over-broad claims damage trust and can survive extraction without context. How: reconcile the body with the evidence register and primary sources. Tool: evidence register and source pages. Done when: every material claim is supported, qualified, or removed.
3. 3
   3. Test information structure

   What: inspect heading order, direct answer, tables, steps, callouts, and CTA position. Why: each element has a semantic job and order communicates dependency. How: read headings alone, then scan components without surrounding prose. Tool: rendered page. Done when: the page remains understandable in both passes.
4. 4
   4. Validate links and media

   What: open internal links, external evidence, app deep links, and every referenced asset. Why: a plausible path can still be missing, redirected, private, or unrelated. How: compare anchors with frontmatter records and inspect each final destination. Tool: browser and repository paths. Done when: destinations exist, match intent, and images have accurate alt text and dimensions.
5. 5
   5. Check metadata and structured content

   What: verify title, description, keywords, date, join fields, link records, and FAQ parity. Why: metadata drives discovery, templates, relationships, and machine-readable representations. How: compare frontmatter with the rendered page and content contract. Tool: source file and preview. Done when: fields are valid, descriptions are click-worthy, and visible FAQ text exactly matches frontmatter.
6. 6
   6. Review conversion and measurement

   What: test the next action and record the intended measurement chain. Why: visibility is not automatically a useful outcome. How: submit or inspect the CTA, establish the baseline, choose the window, and name the decision rule. Tool: page, analytics, and AmICited reports. Done when: the action works and a monitoring owner can explain what change will trigger a response.
7. 7
   7. Record the release decision

   What: mark publish, hold, or approved exception. Why: an unrecorded verbal decision cannot support accountability or later diagnosis. How: attach failures, owners, evidence, and due dates to the QA record. Tool: delivery tracker. Done when: the publisher has one unambiguous instruction and monitoring handoff.

Each item contains what, why, how, tool, and done-when in one record. Teams may move the fields into a tracker, but they should not reduce the item to a vague checkbox such as “SEO checked.” A binary label without evidence invites different interpretations on every page.

Tools in AmICited

The final review should connect the page to the reports that will be used after publication. Use AmICited’s visibility reporting to define the relevant prompt group, record the current answer and cited sources, and separate brand mention from source citation. Use freshness reporting when the page contains time-sensitive product, price, or procedural facts and needs a review trigger.

Open https://app.amicited.com/reports/cockpit to record the baseline view associated with the page’s intended topic. Open https://app.amicited.com/audit/freshness when the maintenance decision depends on update history. Deep links belong in the checklist record as executable tools, not decorative product references.

When these assets exist, render the first as a large screenshot and the second with workflow-section, pairing the latter with a concise explanation of how the report changes the handoff. Until then, the required screenshot comments prevent broken image references.

Stay Updated on AI Visibility Trends

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

Email address

Subscribe

Decision rules

A threshold turns a finding into a predictable action. “Needs improvement” is not enough; the reviewer needs to know which failures block publication, which can be corrected in the same timebox, and which exceptions require approval.

Release decision rules

“Bad” therefore means more than an imperfect score. It means the page could mislead the reader, cannot be maintained, breaks an essential route, violates the content contract, or lacks evidence needed for the intended decision. Critical failures always block. A deadline does not lower severity.

Deliverable template

The QA record should be compact enough to complete and specific enough to audit. Use one record per release candidate:

Page: [canonical URL or repository path]
Release candidate: [version or timestamp]
Brief owner: [name]
QA owner: [name]
Review started / completed: [timestamps]

Decision: PUBLISH | HOLD | APPROVED EXCEPTION

Checks:
- [PASS/FAIL/N/A] Brief match — evidence:
- [PASS/FAIL/N/A] Claims and scope — evidence:
- [PASS/FAIL/N/A] Structure and element contracts — evidence:
- [PASS/FAIL/N/A] Links, media, and app actions — evidence:
- [PASS/FAIL/N/A] Metadata, joins, and FAQ parity — evidence:
- [PASS/FAIL/N/A] Conversion and measurement — evidence:

Exceptions:
- Scope:
- Reason:
- Approver:
- Correction owner and due date:

Measurement handoff:
- Intended result:
- Baseline:
- Observation window:
- Decision rule:
- Monitoring owner:

Do not paste “looks good” into the evidence field. Point to a source, rendered section, tested destination, screenshot, or recorded value another reviewer could inspect.

What goes wrong

Other failures include proofreading before validating intent, checking source existence without checking what the source supports, accepting a screenshot path that is not on disk, testing only desktop behavior, treating redirecting links as automatically correct, letting visible FAQ answers drift from frontmatter, and recording measurement after publication when no clean baseline remains.

Checklist inflation is another failure. Hundreds of equally weighted checks make reviewers skim. Keep critical decisions prominent, move specialist procedures into linked sub-checklists, and mark not-applicable with a reason instead of deleting the field.

Next phase

The next phase is publication and initial verification. The QA owner hands the publisher the approved candidate, decision record, release window, canonical destination, redirect requirements if any, and known reversible exceptions. The publisher confirms that the deployed page matches the approved candidate and returns the live URL plus deployment time.

The monitoring owner then records the live baseline and begins the observation window defined during QA. Use the SEO results framework to distinguish visibility, selection, engagement, and business outcomes. If deployment changes content, metadata, routes, or components, the affected QA checks reopen; approval does not transfer automatically to a materially different page.

• Publisher receives one candidate — The path or version matches the file reviewed and approved
• Release conditions are visible — Redirects, timing, exceptions, and rollback owner travel with the handoff
• Live verification is assigned — A named person confirms the canonical URL, content, metadata, media, links, and CTA after deployment
• Monitoring begins from a baseline — The owner has the intended result, observation window, and decision rule recorded before interpreting movement

The SEO process treats publication as a handoff, not the end of the work. A page becomes maintainable only when the release evidence, measurement decision, and review owner remain connected.

FAQ

Frequently asked questions

The academy layout appends the closing conversion panel. The checklist itself ends with the release and monitoring handoff because a process page should leave the operator with an accountable next state, not merely a completed list.