A search engine cannot rank the page your own website cannot describe consistently.

Give every useful page one stable public identity.

A page needs a readable URL, a successful response, a self-referencing canonical and content that describes the same subject. Variants created by filters, tracking parameters or old platform paths should either resolve to the intended canonical or remain outside the index when they do not add a distinct page.

Unknown routes must return a real missing-page response. An empty template with a successful status can be indexed as if it were content and is harder to detect than an ordinary missing page. Dynamic routes should validate the requested item instead of trusting that a build-time list prevents every unknown address.

Keep the route meaning stable. If a page moves, use a permanent redirect to the closest relevant destination and update internal links to point directly there. A redirect is a safety net for old references, not the site's normal navigation path.

Structure the document around the questions the page answers.

Use one h1 for the page's main subject, then headings that describe the sections beneath them. Do not choose heading levels for their default size. The visual system can style any semantic level, while assistive technology and crawlers depend on the document structure to understand how the ideas relate.

Put the direct answer near the beginning and keep essential copy in the server-rendered document. Important content should not depend on a click, an animation or client-side request before it exists. Interactive details can still improve the page, but the subject and useful answer need to be available in the initial response.

1. 1. Set the page intent

   Write the one question the page answers and make the title, h1, introduction and canonical route agree with it.

2. 2. Build a meaningful heading outline

   Use section headings for real subdivisions of the answer and keep visual sizing independent from the semantic order.

3. 3. Link from related pages

   Use ordinary crawlable anchors with descriptive text. A page no other page reaches is difficult for people and crawlers to discover.

4. 4. Return honest status codes

   Serve successful content, permanent redirects and real missing responses according to what happened. Do not disguise an unknown item as an empty success.

Structured data must describe what the visitor can see.

Use structured data builders tied to the same content the page renders. An FAQ block should come from the visible questions. A breadcrumb should match the trail on the page. A service description should not add claims or locations that never appear in the copy.

Choose a type because it represents the page, not because a rich result would be useful. Organisation and website identity belong at the site root. Articles, breadcrumbs, collections and services belong on the relevant pages. Repeating the same organisation block everywhere creates noise without changing what the page is.

Validate the output in the built page and inspect the source values. Syntactically valid markup can still be misleading when it describes a hidden question, the wrong canonical address or an image that belongs to another page.

The sitemap should describe the site that actually serves.

Generate the sitemap from the same content and route sources used to build public pages. That keeps a new page from being forgotten and a drafted or deleted page from remaining listed. Then check every listed URL against the production build for a successful response and a real page heading.

A sitemap helps discovery. It does not replace internal links or override a blocked route. Indexing headers, robots rules, canonicals and the sitemap should express the same decision about whether a page is public. When a page should remain private or temporary, exclude it deliberately in every relevant control.

Separate public pages from test routes, previews, mockups and form endpoints. The build can contain operational routes that a crawler should never treat as content. A route inventory makes that boundary reviewable instead of relying on someone to remember every exception.

Protect performance and monitor the structure after launch.

Fast rendering, stable layout and usable mobile pages affect whether people can consume the content the technical structure exposes. Optimise image delivery, keep font and script weight proportionate and avoid delaying the primary text behind client-side work. Measure the built page on ordinary devices, not only a local development screen.

After launch, monitor missing routes, redirect chains, canonical changes, blocked pages, sitemap differences and search crawl reports. Content changes can create technical problems too: removing a parent, changing a slug or marking a proof item as draft may alter several derived routes and links.

We make these checks part of the build and release process rather than a one-time audit. That is the important difference. A site remains search-readable because the same rules run when the next page is added, not because the launch spreadsheet once had green cells.

Keep a small regression set of the routes and page types that matter most. Check their status, heading, canonical, structured data and internal reach after shared template or routing changes. A technical rule is valuable when it catches drift during ordinary publishing, not only when a specialist remembers to rerun an annual review.