Home โ€บ Guides โ€บ A Pre-Publish SEO Checklist for Any New Page

A Pre-Publish SEO Checklist for Any New Page

Nine checks that take under ten minutes and catch the mistakes that are invisible after publishing. Ordered so that the cheap ones come first.

Why a checklist rather than a tool

Every item here has a dedicated tool on this site, and you can run them in any order. The reason to work from a list is that the failure mode is not a broken page โ€” it is a page that looks finished. A missing canonical, a duplicate H1, a description that gets truncated: none of these produce a visible symptom. The page renders, the content is good, and the problem is only discoverable weeks later in a report nobody reads closely.

The order below is deliberate. Structural checks first, because fixing them often changes the text, and re-running content checks after a rewrite wastes the first pass.

1. Does the page have exactly one H1?

Not zero, not two. Zero usually means the title was styled with a class rather than a heading element. Two usually means a template printed the site name as an H1 and the page title as another. Both are invisible in a browser and both make the page's main subject ambiguous.

Run the HTML through the heading analyzer and read the outline rather than the warnings. If the H2 list reads like a table of contents for the page, the structure is sound.

2. Do the heading levels descend without skipping?

An H2 followed by an H4 tells a reader that a level is missing. Sometimes a level genuinely is missing and the outline is still correct โ€” but more often the H4 was chosen for its smaller font size. Choose levels for meaning and style them in CSS; nothing in HTML requires an H2 to be visually larger than an H3.

3. Is the title tag specific to this page?

Open ten tabs of your site and read the titles. If several are identical, those pages compete with each other for the same query and none of them wins clearly. A title should describe what this page specifically covers, not the category it belongs to.

4. Will the description survive truncation?

The widely quoted 155-character limit is an average, not a rule โ€” the real constraint is rendered pixel width, and mobile is narrower than desktop. Put the sentence that must survive in the first 120 characters and treat the rest as elaboration. See the full explanation if you want the details.

Preview it rather than counting: the SERP preview tool measures in pixels and shows exactly where the cut lands.

5. Does the canonical point at itself?

A page's canonical should be its own URL, in the same form the page is served at. Trailing-slash mismatches are the common case: if /tools redirects to /tools/, the canonical must say /tools/, or you are telling Google that the real page is a URL that redirects.

Check this on index pages specifically. They are the ones most often generated with a canonical that omits the trailing slash.

6. Is the page in the sitemap, with the right URL form?

Same trailing-slash question. A sitemap entry that redirects is a wasted crawl. If your sitemap is generated, generate the canonical at the same time from the same value โ€” two independent string constructions will eventually disagree.

7. Are the internal links real and useful?

Every new page should link to at least two existing pages, and at least one existing page should link to it. A page that nothing links to is a page that is hard to find, and internal links are the only navigation signal you fully control.

Link with descriptive anchor text. "Read the guide" tells a reader nothing about where it goes; the text should describe the destination.

8. Do images have dimensions and alt text?

Set explicit width and height attributes on every image. Without them the browser cannot reserve space, and the page shifts as images load โ€” which is the single most common cause of a poor layout-shift score.

Alt text describes the image for someone who cannot see it. If the image is purely decorative, an empty alt="" is correct and better than a description nobody needs.

9. Does the structured data describe this page accurately?

If you mark up an Article, the headline should match the visible title and the dates should be real. If you mark up an FAQ, those questions must be visible on the page โ€” markup describing content that is not there is a violation, not an optimisation.

See the @graph guide for how to keep the nodes consistent, or generate the markup with the schema generator.

What is deliberately not on this list

Keyword density. There is no target to hit, and writing to one produces worse text. Run the density checker only to see whether the page is actually about the topic you intended โ€” if the top phrases surprise you, that is a content problem, not a density problem.

Word count. Length is a consequence of covering the subject, not a goal. A page that answers the question in 400 words is finished; padding it to 1200 makes it worse.

Meta keywords. They have been ignored for over a decade.

About the author

Hongtao Ren (ไปปๅฎๆถ›) โ€” Developer based in Xi'an, China. Builds browser-based tools and JetBrains IDE plugins. He built and maintains SerpPrism.

Corrections are the most useful thing you can send. If a tool or guide here gives you a wrong answer, that is a bug, not a judgement call โ€” use the contact page.

Questions

How long should this take?

Under ten minutes once you are used to it. The tool runs are seconds each; most of the time goes into reading the heading outline and checking the canonical form.

Should I run this before or after publishing?

Before, on a staging URL if you have one. Canonical and sitemap checks are easier when the URL form is not yet live, because there is nothing to compare against.

Is this list complete?

It covers the checks that catch invisible problems. Technical performance, accessibility and content quality all matter and are separate disciplines.