Pre-Publish Content QA: Checking the Page Readers Actually Get

Most pre-publish checklists are written for the draft. Spelling, the keyword in the first hundred words, alt text, links that resolve, a meta description of the right length. Every item is reasonable. Then the article gets pasted into a CMS, wrapped in a template, given a slug and pushed through a build, and what a reader or a crawler receives is a different object from the one the editor signed off on. The checklist approved the Google Doc. Nobody approved the page.

We found this out on our own site.

In a September 2026 crawl, twenty of our URLs came back flagged for titles that were too long. The titles in the source files looked fine. But the site layout appends “| ContentBrief.io” to every page title, eighteen extra characters that never appear in the document anyone reviews, and the rendered titles ran from 61 to 107 characters. None of that is visible in a human read of the draft. This guide covers the QA stage that would have caught it, and the part of QA that no script can do for you. It picks up where the publish step in our SEO content workflow leaves off.

What the usual checklist gets right

Read the guides that rank for this topic and they agree on a core: verify the facts, proofread, confirm the on-page SEO fields, test the links, check images for alt text and size, make the formatting consistent with the brand. Some add a plagiarism scan. A few add analytics tagging. None of that is wrong, and if your team does none of it today, start there.

The trouble is where those checks happen. Almost all of them are performed on the draft, by the editor who just finished editing it, in the same sitting. That person has read the piece four times and will read what they expect to see. And the draft can be perfect while the published URL is broken, because the template and the build both get a vote on the final HTML.

Run QA on the rendered page

Open the preview or staging URL. View the source. The fields that matter to search and to answer engines are the ones in the rendered HTML, and they routinely differ from what was typed into the CMS.

The title tag. Check its full rendered length, suffix included. A 50-character headline plus a brand suffix is a 68-character title, and the truncation lands wherever the search engine decides.

The meta description. Templates sometimes fall back to the first paragraph when the field is empty, and some CMS plugins override it silently. Read the one that actually rendered.

Inherited directives. A page can inherit settings from its parent layout that nobody chose for it. One of our app routes shipped declaring itself indexable while robots.txt blocked the same path, because a client-side layout cannot export its own metadata and quietly took the site default. Editorial pages fall into the same hole with canonicals and noindex flags carried over from a template.

Structured data. Paste the URL into a rich results tester and read what comes back. Article markup missing an author or a modified date is invisible on the page and very visible to the systems deciding whom to cite.

Then look at it on a phone, scroll to the bottom and click two internal links. Five minutes.

Check the page against the brief, one last time

The second gap is editorial, and the top-ranking checklists skip it entirely. They ask whether the article is clear and optimized. They never ask whether it is still the article that was assigned.

It drifts more than you would expect between final edit and publish. An SEO lead adds a section to catch a related query. Legal softens the one claim that gave the piece its edge. Someone trims the intro to fit above an embedded form, and the trimmed sentence was the one that named who the article is for. Each change is small and was made by someone with good reasons, but nobody holds the full agreement in their head anymore.

So the final pass reopens the brief. Does the page still serve the search intent the brief specified? Is the angle intact, or did a late edit sand it down into the same thing page one already says? Are the excluded topics still excluded? Does every required question still have an answer on the page? This is the same comparison an editor makes during revisions, as described in how to give editorial feedback, run once more against the live artifact instead of the draft. It only works if the brief was specific enough to check against, which is most of the argument for the fields that make a good brief.

Move every mechanical check into the build

Our firmest opinion on this subject: if a script can verify an item, it should come off the human checklist completely. People are bad at counting characters. They are very good at noticing that a paragraph makes a promise the next paragraph breaks, and every minute spent on the first job comes out of the second.

This site enforces its own rules that way. The production build fails if any page renders a title longer than 60 characters after the suffix. It fails if a blog post ships Article markup without a headline, publish date, modified date or publisher. It fails if a public page has no breadcrumb trail, a check we added after finding that 37 of 38 sampled pages had shipped without one. These are exactly the items a tired reviewer ticks in good faith at six in the evening.

You do not need a custom build to get most of this. A weekly crawl with any site auditor catches most of the list above. A hard character limit on the CMS title field catches the rest of the title problem. Either one beats a checkbox.

The checklist, split by who runs it

Machine checks, run on every publish, ideally by the build or a scheduled crawl:

• Rendered title length, including any template suffix
• Meta description present and under your length limit
• Exactly one H1, and no skipped heading levels
• Canonical URL points at itself unless you meant otherwise
• No noindex inherited from a parent layout or staging config
• Article structured data with author, publish date and modified date
• Every internal link returns a 200, and the new URL is in the sitemap
• Images have alt text and are not multi-megabyte originals

Human checks, done by someone who did not edit the piece:

• The page still matches the brief’s intent, audience, angle and exclusions
• Every number and named claim traces to a source the team can produce on request
• Quoted people have approved their quotes in writing
• The intro tells the intended reader, specifically, why this is for them
• The page reads correctly on a phone, including any embeds or tables

The second list is shorter on purpose. It is also slower, and it is where the risk lives. Facts and intent are the two things a search engine cannot fix for you and a reader will not forgive.

Who runs it

Not the editor. The editor is the person least able to see the page fresh, and fresh eyes are the whole value of this stage. On small teams that can mean writers QA each other’s pieces, or the strategist who wrote the brief does the final brief comparison, since they hold the original intent better than anyone. If the same person must do everything, put a night between the edit and the QA pass. It helps more than any list.

A rule about Friday afternoons

Nothing goes live after four on a Friday unless a second person opens the live URL on their own phone, because the person who hit publish will not, and the broken hero image will sit there all weekend.

Feed failures back upstream

Keep a short log of what QA catches. When the same miss shows up three times, the fix belongs somewhere earlier. A brief that keeps losing its angle in late edits needs an angle sentence stakeholders can see, which is a job for the brief approval workflow. A recurring formatting error belongs in the editorial style guide. A recurring technical error belongs in the build. The goal is a QA stage that finds less every month, because each thing it finds gets fixed one step earlier.