A useful content review does not end with a score. Before publishing, you need to know whether the page answers its intended question, whether its claims can be checked, whether its structure survives the rendered page, and which decisions still require a human editor.
This checklist turns those questions into a repeatable workflow. It checks observable evidence and records uncertainty instead of inventing an overall SEO, helpfulness, or E-E-A-T grade.
Start With a Small Editorial Brief
Write the brief before analysing the draft. If the intended outcome is unclear, most later checks become arbitrary.
| Field | Question to answer |
|---|---|
| Audience | Who is trying to complete this task? |
| Primary intent | What should the reader understand or do after this page? |
| Page type | Tool, guide, comparison, product page, policy, or another format? |
| Evidence | Which original example, test, dataset, or source supports the page? |
| Conversion | What is the next useful step, if any? |
| Limitations | What can this page or method not prove? |
| Owner | Who is responsible for factual and editorial approval? |
Do not start with a target word count. Length follows from the task, evidence, and explanation required.
The Pre-Publication Checklist
| Area | Review question | Evidence to record |
|---|---|---|
| Intent | Does the opening answer the primary question directly? | Quote the opening and the intended answer |
| Scope | Does every major section support the same task? | Flag tangents and competing intents |
| Title | Does the HTML title describe this specific page? | Proposed title and visible H1 |
| Headings | Does the outline represent real section relationships? | H1-H6 outline and detected skips |
| Direct answers | Can important conclusions stand without surrounding marketing copy? | Relevant paragraph or list |
| Claims | Which statements could materially mislead a reader if wrong? | Claim, source, date, reviewer |
| Experience | Is first-hand work shown where it matters? | Screenshot, example, test method, or disclosure |
| Links | Does each internal link continue a useful task? | Source section, anchor, destination |
| Limitations | Are uncertainty and method boundaries visible? | Exact limitation text |
| Metadata | Are title, description, canonical URL, and robots state intentional? | Rendered <head> values |
| Accessibility | Are structure, focus, labels, contrast, and alternatives reviewed? | Manual and automated observations |
| Mobile | Does the real page work at a narrow viewport? | Viewport, screenshot, overflow result |
| Measurement | Is the publish or material-update date recorded? | URL and 28-/56-day review dates |
The Google people-first content guidance provides self-assessment questions about originality, sourcing, expertise, and whether a reader leaves feeling they achieved their goal. Google presents these as questions, not as a public numeric scoring formula.
Step 1: Review the Copy Without a Synthetic Score
Paste the draft text or inert HTML into the SEO Content Analyzer. Use it to inspect observable features such as:
- headings and skipped levels present in the supplied content;
- title and description length;
- paragraphs, sentences, links, and visible phrases;
- direct-answer candidates;
- internal and external link classification when a page host is supplied;
- editorial observations that require review.
The analyser cannot verify accuracy, originality, expertise, search demand, or ranking potential. A detected phrase is evidence that the phrase exists, not proof that it is well written or strategically important.
Record each observation as one of:
- pass – supported by visible evidence;
- change – the editor accepts a specific correction;
- needs review – a human decision or missing source is required;
- not applicable – the check does not fit this page type.
Do not collapse those states into one percentage.
Step 2: Inspect the Heading Outline Separately
Use the Heading Structure Checker when you need a focused H1-H6 outline. The W3C WAI headings tutorial explains that headings communicate page organization and should represent nested sections.
Check:
- whether the page title is exposed as a heading;
- whether heading text identifies the section without generic labels;
- whether an H2-to-H4 jump represents a genuinely missing level;
- whether headings were selected for visual size rather than meaning;
- whether scripts or widgets add headings in the rendered DOM;
- whether the outline remains understandable when read without body copy.
A clean sequence does not prove accessibility or SEO quality. It confirms only the structure found in the supplied input.
Step 3: Review Evidence and Responsibility
Run the draft through the E-E-A-T Evidence Checker to prompt a structured review of visible evidence. Use the result as a question list, not as a Google score.
For consequential claims, record:
- the exact claim;
- the source URL or first-hand method;
- when the source was checked;
- whether the source directly supports the nearby wording;
- the author or reviewer responsible for approval;
- any unresolved qualification.
Higher-risk subjects need stronger evidence and, where appropriate, a qualified reviewer. A developer’s experience can support a description of browser processing; it does not automatically support medical, legal, or financial advice.
Worked Example: Text Character Counter
This demonstration uses repository evidence for the existing Text Character Counter. It does not claim a fresh live-browser audit.
| Check | Evidence available | Status |
|---|---|---|
| Primary task | Registry and page copy identify Unicode-aware character counting and configurable limits | Pass |
| Counting semantics | Implementation uses Array.from(text).length, which counts Unicode code points rather than UTF-16 units | Pass |
| Grapheme limitation | Guide copy states that one visible grapheme can contain multiple counted code points | Pass |
| Word-boundary shortening | Automated tests cover non-destructive shortening and optional ellipsis | Pass |
| Worked example | Guide contains a reproducible description-shortening example | Pass |
| One rendered H1 | Shared page template owns the page H1; tool interface starts with H2 | Pass in repository render tests |
| Complete live outline | Requires inspection of the final rendered production DOM | Not verified |
| 320 px layout after the next content change | Requires a new browser preview of that revision | Not verified |
| Google ranking effect | Cannot be established by this workflow | Not verified |
The example shows why evidence labels matter. Repository tests support several implementation claims, while final layout and search effects require different evidence. Writing "SEO score: 92" would erase those distinctions.
Step 4: Check Metadata and the Rendered Page
Review the actual preview or staging URL, not only the editor canvas.
- Confirm one intentional document title and meta description.
- Confirm a self-referencing canonical URL unless an approved alternative is required.
- Check robots directives and accidental
noindexsettings. - Inspect Open Graph and social-image fields.
- Confirm structured data matches visible content and does not invent ratings, reviews, prices, or authors.
- Test keyboard navigation, visible focus, form labels, error states, and alternative text.
- Review desktop and a narrow mobile viewport for clipping and horizontal overflow.
- Confirm advertising or consent layers do not cover the primary task.
Save the evidence that supports the check: HTML excerpt, screenshot, test output, or manual-review note. "Looks fine" is not a reproducible result.
Step 5: Record Publication and Revisit the Page
For each new article or material update, record:
- final URL;
- primary intent;
- publication or update date;
- index status;
- internal links added;
- 28-day Search Console result;
- 56-day Search Console result;
- decision: improve, consolidate, leave stable, or plan an approved redirect.
Search performance is delayed and noisy. A few impressions or clicks do not prove that one editorial change caused the movement. Compare the same URL-prefix property and search type, and inspect page and query data rather than only sitewide totals.
What This Checklist Cannot Prove
- It cannot guarantee crawling, indexing, rankings, traffic, citations, or conversions.
- It cannot prove that content is helpful to every reader.
- It cannot replace subject-matter review for high-risk claims.
- It cannot detect plagiarism or factual errors from structure alone.
- It cannot turn E-E-A-T into a single Google score.
- It cannot reproduce every browser, assistive technology, search interface, or query.
Its purpose is narrower: make the editorial decision traceable, expose missing evidence, and prevent avoidable publishing mistakes.
Frequently Asked Questions
Does passing every check guarantee higher rankings?
No. The checklist improves the quality and traceability of the publishing process. It makes no ranking guarantee.
Should I optimise for an E-E-A-T score?
No universal Google E-E-A-T score is exposed for publishers. Review the experience, expertise, authority, and especially trust evidence relevant to the page’s purpose and risk.
Can an analyser decide whether an article is helpful?
It can surface observable features and missing evidence. A responsible editor must still evaluate accuracy, usefulness, originality, audience fit, and the quality of the underlying work.
Do I need to complete every row for every page?
Use the checks proportionally. A password generator, editorial guide, product offer, and medical article do not carry the same evidence requirements. Mark genuinely irrelevant checks as not applicable rather than forcing decorative content onto the page.
Sources and Review Date
- Sources reviewed on 19 October 2026.
- Google Search Central: Creating helpful, reliable, people-first content – publisher self-assessment questions concerning originality, sourcing, expertise, and reader value.
- W3C WAI: Headings – headings as a representation of page organization and nested sections.
How this guide was prepared: Gemini produced the initial checklist using the TomSEOTools Content Editor Gem. The TomSEOTools maintainer replaced invented tool results with repository evidence and explicit Not verified states, expanded the production QA and measurement workflow, reviewed the cited primary sources, and retained responsibility for the final draft.