Pre-Publish Content QA Checklist: Check the Page, Not Just the Draft

Key takeaways

• Review the rendered page because formatting, links, images and schema can change after the draft is saved.
• Use pass, repair or hold decisions instead of a vague “looks fine”.
• Test usefulness, evidence, search metadata, accessibility and mobile layout as separate checks.
• Record the exact version, reviewer, failures and repairs so publication can be repeated safely.

Finishing a draft feels like the end of the job. It is not. The article still has to survive the journey through your content editor, theme, SEO settings, image handling, automatic links and the reader’s device.

A sentence can be correct in the draft but separated from its qualification on the page. A heading can become an awkward jump in the outline. A wide table can push the mobile layout sideways. A question can be rewritten in the visible copy while the old version remains in structured data. Those are publication problems, not writing problems.

This checklist sits between your wider content governance rules and the final publish action. It assumes you have already decided who owns the page and used a content source log for claims that need evidence.

Why should you check the rendered page instead of only the draft?

The rendered page is the real product. It combines your copy with the title tag, canonical URL, theme styles, image files, captions, internal links, structured data and mobile behaviour. A document review cannot prove that those pieces work together.

Google’s SEO Starter Guide recommends clear, accurate page titles, useful link text and high-quality images placed near relevant text. Its developer guidance also stresses that pages should be accessible, fast and usable on all devices. These are not magic ranking switches. They are practical signals that a page can be understood and used.

Accessibility guidance points in the same direction. The W3C advises using headings to communicate structure, meaningful text for links and appropriate alternatives for informative images. Its images tutorial also makes an important distinction: informative images need an alternative that conveys their purpose, while purely decorative images should not be burdened with redundant descriptions.

What should a pre-publish content QA check cover?

Use six separate stages. A page passes only when every material issue is resolved or consciously accepted by the person with publishing authority.

1. Does the page answer the reader before it expands?

Read the title, opening and first useful section as a new visitor. You should be able to say what the page helps with, who it is for and what the reader can do next. Keep the direct answer close to the top, then add reasoning, examples and exceptions.

This answer-first pattern helps human readers scan and gives answer engines a clear, attributable passage. It does not guarantee an AI citation. The goal is a useful page with specific language, explicit boundaries and enough context to quote without changing the meaning.

2. Do important claims still match their evidence?

Open the evidence behind prices, availability, rules, research findings, comparisons and results. Check the exact live wording, not only the note in your source log. Confirm that dates and scope remain visible: country, plan, account type, sample, method or other limits.

If a claim is only partly supported, narrow it. If the source has changed materially, repair the page or hold publication. “We added a citation” is not a pass when the citation does not support the sentence.

3. Are the search elements accurate and useful?

Check the title and description against the page readers will receive. They should describe this page, not the broader category. Confirm one preferred canonical URL, normal indexability, a clean slug and working internal and outbound links. Use anchor text that describes the destination instead of repeating “click here”.

Link to the live content marketing system when a reader needs the wider method, and to a specific support article when it solves the next task. Avoid inventing URLs for planned pages. Your internal-link maintenance process can handle future changes after publication.

4. Does the structure match the visible content?

Scan only the headings. They should create a sensible outline without requiring the paragraphs to explain what each section is about. Remove accidental empty blocks and isolated one-item lists. Use a real table for a comparison, a numbered method for a sequence and paragraphs for reasoning.

Then compare structured data with what readers can see. Google’s general structured data guidelines say markup should represent the main visible content and warn that valid markup does not guarantee a rich result. If you publish an FAQPage, its questions and answers should match the visible Q&A after normalising punctuation and spacing.

5. Are the intended images present and understandable?

Verify the actual files, not placeholders. Check dimensions, compression, crop, filename, caption, alignment and alternative text. An informative image needs an alt description that communicates its purpose in this article. Do not stuff keywords into it or describe irrelevant visual detail.

Keep important instructions in nearby text. A diagram can reinforce the six stages, but the article must still explain them for readers who cannot see the image or choose not to load it.

6. Does the narrow page work without hiding problems?

Open the real rendered page at a narrow mobile viewport and scroll through it. Look for page-level horizontal overflow, clipped tables, oversized callouts, awkward image crops, tiny text and controls that are difficult to tap. Tables may use their own horizontal scroll container when the data genuinely needs width; the whole page should not slide sideways.

Do not hide a broken layout with a global overflow-x:hidden rule. That can make content unreachable while the defect remains. Fix or contain the element that is actually too wide.

How do you run the QA check without turning it into bureaucracy?

Run it in two passes. The first pass is editorial: usefulness, evidence, qualifications and structure. The second pass is rendered: metadata, links, images, schema and narrow-screen behaviour.

1. Freeze the candidate. Record the draft or post ID and time so everyone checks the same version.
2. Read the opening cold. Confirm the main question is answered before background expands.
3. Check high-impact claims. Compare the live wording with the source log and open each contextual source.
4. Inspect the outline and links. Scan headings, test destinations and confirm internal links point to published pages.
5. Compare visible Q&A and schema. Count schema blocks and verify exact question-and-answer parity.
6. Load every intended image. Check crop, caption, alt text, file size and placement beside relevant copy.
7. Test a narrow viewport. Scroll to load deferred media and look for overflow or awkward controls.
8. Choose pass, repair or hold. Record failures specifically. Repair the same article and repeat the failed checks.

What does a pass-or-hold decision look like?

Imagine a fictional two-person consultancy preparing an article called “Five Project Tools for Client Work”. The draft is readable and the writer has added links to each supplier.

During editorial QA, the reviewer finds that “Tool A includes unlimited automations” came from an older pricing page. Current documentation lists usage limits by plan. That is a hold because the claim could affect a buying decision. The writer replaces it with a plan-specific statement, adds the verification date and records a pricing-change review trigger.

During rendered QA, the reviewer finds that the comparison table pushes the page 120 pixels wider than the mobile viewport. The table itself is useful, so it is placed inside a labelled horizontal scroll container rather than flattened into a misleading list. The reviewer also notices that one image caption says the team “tested” every tool even though the example is research-based. The caption is corrected.

After those repairs, the reviewer reloads the same candidate, repeats the evidence and mobile checks, and records a pass. No replacement article is created and the first failed attempt is not treated as a publication.

What should the pre-publish QA record contain?

Keep the record short enough to use and precise enough to recover. Copy this into a shared document, spreadsheet row or content-management note:

Content ID / post ID:
Working title and intended canonical:
Candidate version and checked time:
Primary reader question:
Promised outcome:

1. Reader usefulness — pass / repair / hold:
2. Evidence and qualifications — pass / repair / hold:
3. Title, description, canonical, indexability and links — pass / repair / hold:
4. Heading structure and visible-copy/schema parity — pass / repair / hold:
5. Image files, crop, caption and alt text — pass / repair / hold:
6. Narrow-screen layout and interactions — pass / repair / hold:

Failures found:
Exact repairs made:
Checks repeated:
Reviewer / publisher:
Final decision and time:
Post-publication verification still required:

The final line matters. A clean preview does not prove the public page works. After publishing, freshly open the canonical URL and confirm status, content, images, metadata, schema, internal links, mobile layout and sitemap discovery. Track “public” separately from “editorially verified”.

A bounded AI prompt for an extra review pass

AI can help identify possible gaps, but it cannot prove that a link, schema block or mobile page works unless it is given and allowed to inspect the real rendered output. Use it as a reviewer, not as the publication authority.

You are reviewing a candidate article before publication.

Primary reader question: [paste]
Promised outcome: [paste]
Article text or rendered-page extract: [paste]
Verified source notes: [paste]

Report:
1. Where the main answer is delayed, vague or incomplete.
2. Claims that need a source, date, scope or qualification.
3. Headings that do not describe the section beneath them.
4. Links or image descriptions that are unclear from their text alone.
5. Visible Q&A items that must match FAQ schema exactly.
6. Anything you cannot verify from the supplied material.

Do not invent sources, performance results, legal conclusions or checks you did not perform. Label every uncertainty.

Review the suggestions yourself. A prompt can expose ambiguity; it cannot turn an untested page into a passed page.

Which common QA shortcuts create false confidence?

Checking only word count

Length cannot prove usefulness or completeness. A shorter article can answer a narrow question well, while a long one can repeat caveats and miss the decision the reader came to make.

Trusting a green plugin score

A plugin can flag missing fields or patterns. It cannot decide whether a claim is supported, a comparison is fair or an example is genuinely useful. Treat scores as diagnostics, not publication authority.

Testing the editor instead of the page

The editor may show a tidy table while the theme makes it overflow. It may show an image that fails from the public delivery URL. Preview and public verification are separate gates.

Validating schema but ignoring parity

Valid JSON-LD can still misrepresent the page. Check that the marked-up questions, answers, title, dates and image belong to the visible article. Structured data eligibility never guarantees a search enhancement.

Repairing by creating a replacement

When an article has an established post ID or draft, fix that same item. Replacements create duplicate URLs, split evidence and make it harder to know which version was approved.

Reader Q&A

Do I need a different QA checklist for every article type?

Keep the six core stages, then add checks for the risk and format. A product comparison needs stronger price and claim verification; a tutorial needs complete steps; a high-consequence topic needs appropriately qualified review.

Who should perform the pre-publish check?

A second person is useful for material claims and commercial comparisons. A solo operator can still separate drafting from checking by pausing, reviewing the rendered page in a fresh session and bringing in specialist help where the consequences require it.

Should a failed check always block publication?

A material failure should. Broken media, unsupported claims, wrong canonicals, accidental noindex rules, truncation and misleading schema all justify a hold. A harmless stylistic preference can be recorded without stopping the page.

Is a mobile emulator enough?

It is useful, but a real browser at a defined narrow viewport gives stronger evidence. Scroll the full page so lazy-loaded images appear, check page-level overflow and test links and controls. Use a physical device as an additional check when the page has complex interactions.

Does valid schema guarantee a rich result or AI citation?

No. Valid structured data can help systems understand a page, but search platforms decide whether to show enhanced results. Clear, accurate and useful visible content remains the priority, and no checklist can guarantee a ranking or citation.

Should I run the checklist again after publishing?

Yes. Freshly load the public canonical and repeat the material checks. Confirm the article is complete, intended images and links work, visible Q&A matches schema, the page is indexable, the narrow layout holds and the URL appears in the site’s actual discovery paths.

The bottom line

A reliable pre-publish check turns “looks ready” into evidence. Review the answer, claims, page signals, structure, images and narrow-screen experience as separate stages. Hold material failures, repair the same article and verify the fresh public page after publication.

Start with the next substantial article. Save the candidate version, run the six checks and record one clear decision. Over time, the record will show which failures your team repeats and where the publishing process needs a stronger control.

Related posts

• Content Marketing for Small Businesses: A Practical System
• Create a Content Governance Checklist for a Small Team
• Build a Content Source Log Before Claims Become Hard to Check
• How to Refresh Old Content Without Losing Its Purpose

Garry Knight

I'm Garry Knight, the person behind Prodify Digital. I write about email list building, email marketing, SEO, AI search and the tools that connect them. My aim is to make online marketing easier to understand, so creators and small business owners can make informed decisions about building an audience and keeping people engaged. Here you'll find straightforward guides and product reviews that explain what something does, where it fits and which limitations matter. The focus is on clear explanations and useful next steps—not hype, shortcuts or promises of easy earnings.

See Full Bio