One defensible job per page: the core of on-page SEO best practice

What to take away

A page earns its place when a specific reader finishes a specific task on it.

Name the job before you name the keyword

Write one sentence: this page exists so that [audience] can [task] and then [next action]. If you cannot fill all three blanks, the page is not ready to draft.

A pricing page exists so a buyer can understand what they pay and how to qualify. A troubleshooting page exists so an operator can diagnose a fault and fix it. Two pages chasing the same job should merge, not compete.

Titles: what Google actually pulls

Google generates title links from several sources: the title element, the visible H1, prominent body text, anchor text pointing at the page, and structured data. You influence the pool, you do not control the pick.

So make every candidate good. A title element that says one thing and an H1 that says another splits the pool and weakens both. Keep the page's own words consistent with its purpose, and drop the habit of stuffing a second keyword phrase into the H1.

For example, a title element that reads "Gutter cleaning steps for two-story homes" and an H1 that reads "Gutter cleaning steps for two-story homes" agree. A title element that reads "Gutter cleaning steps for two-story homes" and an H1 that reads "Roof and gutter services" split the pool.

Aim for about 60 characters in the title element. Treat that as a rendering target, not a hard limit.

Place the primary phrase in the H1, in the first sentence of the opening paragraph, and in at least one subhead. Once in each place is enough. Extra repetition reads as filler and can weaken the snippet.

Snippets are extracted, not declared

The meta description is a suggestion. Google often quotes a sentence from the page instead, chosen to match the query. Write the description anyway, then read your first two paragraphs and ask whether they would survive being lifted out of context.

For example, a meta description for the gutter page might read: "Clean two-story gutters safely with a step-by-step order, a tool list, and height checks." The first body sentence should carry the same promise.

Never bury a qualification that changes the meaning of the page. "Prices exclude installation" belongs in the body, not only in metadata. A snippet that omits it misleads the click.

Links: crawlable, resolvable, named

Google's crawlable-links guidance covers the mechanics: use conventional anchor elements, point at resolvable destinations, write descriptive anchor text, and keep link volume restrained. A link that needs JavaScript to fire is not a link until you verify it renders.

Anchor text should name the destination. "Click here" tells a reader nothing and a crawler less. If the anchor only makes sense with the sentence around it, rewrite the anchor.

For example, write "gutter cleaning steps" as the anchor and point it at /gutter-cleaning/. A typical working range is 2 to 5 contextual internal links per 1,000 words. Treat that as a norm, not a rule. Put them where the reader would naturally move next, not in a footer block.

Test link purpose before release

The W3C's WCAG explanation of link purpose requires that a reader can tell where a link goes from its text alone, or from text plus programmatically associated context. Ambiguous purposes get an exception, not a free pass.

Test on the rendered page, not the source. Tab through in order and watch the focus ring. Check repeated labels: six links all reading "Read more" fail the test even when each goes somewhere useful. Check image links for alt text that carries the destination.

Do not guess internal links in a draft

A draft with placeholder links is worse than a draft with none. You cannot verify the destination, the canonical URL, the anchor context or the chronology, so the link either ships broken or ships wrong.

Add internal links at publishing, once the target page is live and its URL is settled. This article carries no internal links for that reason.

Release with evidence

Capture the baseline before you change anything: impressions, clicks, qualified actions, error rates. Write down the hypothesis, the pages touched, the release date and the window you will judge it in.

Example window: judge a title change over 28 days, or until each variant has 100 qualified sessions, before you accept the result. Use Search Console for impressions and clicks, and your own analytics for qualified actions.

Judge query-task alignment, qualified actions and downstream value together. A test that moved nothing is still a result. Keep it in the record.

Decision table

Who owns what on a publishing team

The NIST Privacy Framework starting guide describes a voluntary process for identifying and managing privacy risk. On a publishing team, use its structure to name one owner per page for data intake, factual claims and the next action the page promises. That owner signs off before release.

The CISA business-system logging guidance explains how event records support security review. Apply the same habit to publishing: log who changed a title, when, and what evidence supported the change. Logging proves what happened; it does not prove a metric is right.

Common questions

What is the most durable on-page SEO best practice?

Serve one real customer task with an accurate, maintained page, then measure whether discovery produces a useful outcome. No single markup trick substitutes for that.

Should a draft include guessed internal links?

No. Add internal links at publishing, once the live destination, canonical URL and anchor context are verified. A guessed link is a broken link waiting to ship.

Does truthful structured data guarantee a rich result?

No. Valid structured data can make a page eligible for a supported feature, and the search system still decides whether to display it. Keep the visible content complete on its own.