A Practical SEO Quality Check Before Publishing

Publishing an SEO article is not complete when its draft has been approved or the CMS displays a success message. The public page must accurately present the intended information, show required sources and remain usable on the devices visitors actually use. A practical pre-publish checklist helps a small UK marketing team spot common errors without treating every software warning as equally important. Its purpose is to verify factual quality, page identity, links, images, technical output and the reader's next action. The right process separates approval of content from acceptance of the production page and records anything that cannot be checked.

Check the subject and promise before the markup

Read the H1, HTML title, opening and ending as one piece. Do they describe the same real topic? A technical guide should deliver the process or distinction it promises. A service page should accurately explain the offering and suitability. A comparison should define meaningful alternatives instead of merely listing generic benefits. If the body cannot support the title, rewrite the misleading claim rather than using the title as bait for search traffic.

Check whether the page has a reason to exist separately from other content. Several articles can share terminology whilst answering different questions, but near-duplicates may confuse readers and burden future updates. Record the intended audience and next action. Google people-first content guidance encourages reliable, useful answers; it does not guarantee ranking based on word count or a checklist grade.

Look for invented experiences, statistics and credentials. A named editorial persona may define the article's tone, but it must not be used to fabricate a biography or fieldwork. Review the actual text instead of assuming a polished style means the information is correct. Factual approval needs an owner who understands the service or technical subject.

Verify claims against the right source

Identify important assertions and check that the linked documentation supports them. A Google Search Central article can explain a supported crawler rule; it cannot prove a particular company's services or customer results. A vendor help page can describe a product feature, subject to version and date, but it does not establish that a business has deployed that feature. Keep that distinction visible. If the source is unavailable, qualify the claim or remove it rather than manufacturing evidence.

For legal, medical, financial or other specialist subjects, the organisation may need an authorised expert reviewer. A general marketing editor cannot confer credentials on themselves. Check dates, jurisdiction and product version where they materially affect the advice. Some evergreen explanations remain correct for years; other guides change after a platform release. A recently modified timestamp without research is not evidence of freshness.

Inspect citations for misleading link labels and unrelated destinations. Links should reach a credible source relevant to the sentence they support, not merely the organisation's homepage. Distinguish primary documents from commentary or a historical illustration. Do not claim that a quote or case study came from a client unless its source and reuse approval are established.

Confirm SEO fields align with visible content

The title, description and H1 should accurately represent the destination while using natural language. They need not be identical. Check that the metadata is not copied from a neighbouring article or generated from a stale template. A description may help searchers understand the page, but Google may produce a different snippet for a query; exact display is not guaranteed.

Inspect the canonical URL and any declared preferred representative. A working article should not inadvertently canonicalise to an unrelated homepage. Be cautious with redirects, noindex and robots directives: they control different aspects of access and indexing. A keyword change does not justify rewriting a working URL without a genuine structural need. These issues belong to a technical review of the actual public response, not solely a CMS text field.

Check that the proposed page sits sensibly in the site architecture. A specialist article should have a suitable route from relevant overviews, and internal links should have meaningful anchors. Google's link guidance describes crawlable anchors; it does not require a specified number of exact-match links.

Review headings and the actual editorial structure

Headings should organise real parts of the answer. H2 sections introduce important divisions; H3 sections explain subordinate topics where needed. Do not add repeated headings merely to satisfy a keyword tool. A reader navigating headings alone should understand how the article progresses. Inspect the final rendered markup, because a shared template may insert headings that are absent from the editor preview.

Check for empty sections, duplicate paragraphs and unsupported promises. An article claiming to include a step-by-step checklist should actually give actionable steps and their limitations. An FAQ should answer the questions rather than repeat the introduction. A comparison should tell a reader what distinguishes the options and what evidence supports the conclusion. A minimum word threshold can be verified for a particular publishing standard, but length alone cannot certify that a page is helpful.

Proofread for natural British English where appropriate to the publication, accurate technical terminology and readable sentences. Read numerical units and dates closely. Avoid introducing false certainty through an overly forceful tone. A caveat that changes the practical advice should sit near the relevant claim rather than being buried at the bottom.

Check tables as usable comparisons

A comparison table is worth including only when the page discusses a real choice. Check that columns are identified, rows use comparable criteria and every entry is relevant to the topic. A table with two alternatives and five meaningful criteria is more useful than a long decorative list that simply praises one side. Avoid fabricated numeric performance scores, invented prices or unverified guarantees.

Use semantic table markup, including headers for columns and row labels where appropriate. On a narrow screen, preserve all columns and provide a clearly contained horizontal scroll when needed. Do not allow a wide table to create sideways scrolling across the entire article. Check keyboard navigation for any scrollable region and ensure the source and conclusion are understandable without relying on colour alone.

When citing sources after a table, say which part of the comparison they substantiate. Two references may cover distinct aspects; neither automatically verifies a proprietary preference. A useful final recommendation acknowledges when different circumstances justify different choices.

Confirm images and licence information

Visuals should add relevant information, not merely decorate the page with a generic SEO photograph. A sitemap illustration can support a discussion of architecture. A historical search-result screenshot can illustrate the form of a snippet but cannot prove current ranking behaviour. Check the actual image file, original creator, source page, licence and any requirements for attribution or share-alike reuse. Do not generate a fictional screenshot or use an image whose source cannot be established.

Write alt text that explains the image's purpose and a caption that distinguishes the illustration from evidence about this particular business. The licence statement needs to be accurate and should not be guessed from a search thumbnail. If a visual is modified, confirm that the licence allows the change and disclose it where appropriate. Check that the public image actually loads; a correct database URL is not proof that a browser can retrieve its bytes.

Inspect image size, aspect ratio and wrapping on mobile. Reserve space to limit layout movement, and avoid cropping text within diagrams. Decorative images can sometimes use empty alt text, but meaningful diagrams need useful alternatives. A caption cannot replace a full explanation where the diagram contains important instructions.

Test links and the reader's next action

Open important internal destinations and external references. An apparently valid anchor may redirect to an unrelated page or a missing resource. Check links from the page as well as relevant incoming navigation when a new article is added. A broken contact route is more consequential for a service page than a minor decorative inconsistency.

For an enquiry form, test permitted submission with safe data and confirm the intended system accepts it. A button-click event is not evidence of delivery. Check field labels, validation messages and success feedback. Do not send real confidential customer information through test workflows. If the page offers a downloadable checklist, verify that the correct document opens and is readable.

Check mobile menus, sticky overlays and anchor navigation. The public page may look fine in a screenshot while keyboard focus is hidden or a banner covers the submit button. Define the customer task and perform it end to end, rather than relying on a superficial visual pass.

Inspect public rendering separately from CMS persistence

A successful database write and native READ-BACK show that updated fields were saved. They do not establish that caches, templates or the CDN now show that revision. Check the actual canonical public URL, rendered title, body, comparison, FAQ and images. If the page returns an error or the reader tool cannot access it, record that limitation honestly and use an authorised browser or deployment verification process where available.

Check that editorial notes remain internal. A publishing template that accidentally outputs private review comments has a confidentiality defect. Deleting legitimate private records from the database is not an adequate substitute for fixing the renderer boundary. Verify the editor card is based on approved public metadata rather than exposing internal persona configuration.

For shared component changes, test more than one representative page. An article with unusually long headings or nested tables may reveal a template failure that a short example cannot. Keep acceptance evidence dated and tied to the exact URL or record, not a general assertion that all articles behave identically.

Check responsiveness and accessibility with real content

Use sample widths around 320, 375 and 768 CSS pixels, together with zoom or real devices where practical. Check headings, tables, long links, code examples, navigation and forms for clipping or horizontal overflow. A responsive meta tag alone cannot establish usable layout. Inspect keyboard focus and the accessibility of links and controls.

The W3C Web Accessibility Initiative tutorials provide appropriate patterns for headings, images, links and forms. Automated checks can find certain issues but cannot judge whether all alternative text is meaningful or a customer action succeeds. Use human review for the important task. If a test could not be performed, do not mark it passed.

Close with explicit acceptance states

Separate editorial approval, technical deployment, database persistence, public page verification and later search performance. Each is valuable evidence but answers a different question. A page can be well written while its public image is broken. A correct public page may receive little search traffic because of external demand or indexing decisions. Do not convert one successful state into an unsupported claim about all the others.

Maintain a short record of passed checks, remaining issues, owners and next steps. Prioritise severe defects that prevent reading, accessibility or essential customer action. A usable pre-publish checklist does not exist to create ceremony: it helps a small team produce trustworthy articles consistently, correct the right problems and tell the truth about what has actually been verified.