A page should not reach production merely because the copy is approved and the layout looks finished. It should reach production when its purpose, content, metadata, crawl behavior and user experience work together.

This is a page-level checklist. It cannot replace a technical review of the website, its templates, rendering model, navigation or indexation controls.

1. Confirm the page has a job

Before checking tags, state the page’s purpose in one sentence.

  • Who is the page for?
  • What problem or decision does it support?
  • What should the visitor understand or do next?
  • Why does this page deserve a separate URL?
  • Which existing page would compete with it?

If the answer is vague, metadata will not rescue the page. Merge it with an existing page, narrow the purpose or stop publication until the distinction is clear.

2. Review the visible content

The main content should satisfy the promise made by the title and introduction. Check that it:

  • answers the primary question directly;
  • provides information beyond generic summaries;
  • distinguishes facts, opinions and assumptions;
  • removes unsupported claims and stale references;
  • uses descriptive headings in a logical order;
  • gives the visitor a useful next step;
  • identifies the author when authorship matters.

There is no preferred word count. The page should be as complete as the visitor’s task requires and no longer than its usefulness supports.

3. Check the title and description

Every indexable page needs a unique, descriptive HTML title. The title should identify the subject without exaggeration or keyword repetition.

The meta description should summarize the page accurately and help a searcher decide whether it is relevant. It is not a ranking promise, and search engines may show a different snippet. Treat it as useful editorial metadata, not a character-count ritual.

Verify both fields in the generated HTML, not only in the content-management interface.

4. Confirm the URL and canonical

The URL should be readable, stable and consistent with the site’s established format. Avoid changing a live URL only to make it marginally shorter.

For a new canonical page, check that:

  • the final production URL is known;
  • internal links use that version;
  • the canonical points to the intended representative URL;
  • HTTP, HTTPS, hostname and trailing-slash variants resolve consistently;
  • redirects do not create chains or loops;
  • parameter or print versions do not become accidental competitors.

Canonical annotations are signals, not a substitute for consistent redirects, internal links and sitemap entries.

5. Decide whether the page should be indexed

Indexation is a publishing decision.

An indexable page should return a successful response, contain its useful content in the public experience and remain accessible to crawlers. A private, duplicate, filtered, temporary or low-value page may require a different treatment.

Check for accidental noindex, robots rules, authentication, staging restrictions and canonical conflicts. Remember that robots.txt controls crawling, while a robots meta tag or response header can control indexing. They solve different problems, as explained in index, noindex, allow and disallow.

The page should not be an orphan.

Add links from relevant pages where a visitor would genuinely benefit from the connection. Use descriptive link text. Link onward to the next useful article, service, category, tool or contact path.

Avoid automatic link blocks that connect everything to everything. Internal links should express hierarchy, importance and meaningful relationships.

7. Review headings, media and structured data

Use one clear H1 for the page’s main title, followed by sequential H2–H6 sections. Do not choose heading levels for their visual size.

For images:

  • include alternative text when the image communicates information;
  • use empty alternative text for genuinely decorative images;
  • provide dimensions to reduce layout movement;
  • compress files responsibly;
  • avoid embedding essential text only inside an image.

Structured data should describe what is visibly present. Do not add review, FAQ, organization, author or product claims the visitor cannot verify on the page.

8. Test the rendered experience

Inspect what the server actually delivers.

  • Is the important content available in the rendered HTML?
  • Does the page work without avoidable client-side dependencies?
  • Is it usable on a narrow mobile screen?
  • Can a keyboard user reach every control and link?
  • Is focus visible?
  • Are labels, errors and instructions understandable?
  • Do links and assets resolve?
  • Does the page remain readable at increased zoom?

Search quality and user experience are not separate release tracks. A page that is difficult to use is not finished.

9. Validate discovery files and status behavior

If the page is canonical and indexable, add it to the XML sitemap and the site’s URL inventory. Use the complete production URL in the sitemap.

Check the response status directly. A styled error page that returns 200 OK is still a technical error. A redirect should use the intended redirect status. A removed URL should not silently behave like a normal page.

10. Check the page after publication

Publication is not the end of QA.

After launch:

  1. Open the production URL under HTTPS.
  2. Inspect the title, description, canonical and robots directives.
  3. Follow representative internal links.
  4. Test forms or interactive elements with valid and invalid input.
  5. Confirm the sitemap contains the correct canonical.
  6. Inspect the URL in the relevant search-engine tools when appropriate.
  7. Record the release so later performance changes have context.

The goal is not to earn a perfect checklist score. It is to prevent avoidable ambiguity and release a page that serves a defined visitor need.

Official references