On-page SEO

On-page work has a reputation for being a checklist, and the checklist version reliably produces pages that tick every box and help nobody. Title present. Headings in order. Keyword in the first hundred words. All true, all satisfied, and the page still loses to something written by a person who understood what the reader wanted.

The reason is that every item on that list is downstream of a decision most pages never make. Who is this for, what are they trying to finish, and what does this page provide that they cannot get from the four other pages already ranking?

That decision is the page promise, and it is worth writing as an actual sentence before anything else happens. Once it exists, most of the on-page checklist answers itself, because a title is easy to write when you know precisely what the page is for.

A title cannot rescue a page with no distinct purpose. Write the promise first and the page mostly writes itself.

What a page promise contains

Write it as one paragraph and keep it at the top of the brief. Every later decision on the page gets tested against it: does this section serve the promise, does this link serve the promise, does this image serve the promise. Sections that fail that test are why long pages are often worse than short ones.

Claims need an owner before they need copy. Anything the page asserts that a reader could challenge, particularly on money, outcomes, timelines, or safety, needs a named person who can support it. Deciding that after the draft exists is how legal review turns into a rewrite.

The Austin page does not estimate settlements

Horizon's Austin service page promises provider evaluation. Somebody is deciding whether this firm can handle their case, and the page has to carry local service details, case fit, fees, process, proof, and a way to start a consultation. That is a full page's work and it is a coherent one.

Settlement estimation is a different promise and it lives in the calculator. The temptation to fold it in is strong, because the query has volume and the topic is adjacent. Doing it produces a page that half-evaluates a provider and half-estimates a number, and a reader with either job finds a page that keeps interrupting itself.

Two promises on one page is the most common cause of a page that ranks and does not convert. It usually attracts the easier audience, which is the one further from buying, and then measures its own failure as a conversion problem. The fix is upstream, in module 3's format decision, not in more on-page work.

Inventory the page before you rewrite it

Before touching any wording, walk the page section by section and record four things about each one. This takes twenty minutes and it consistently finds the problem faster than reading the page as prose does.

The pattern this exposes most often is right content under the wrong label: a section that genuinely defines what the product does, headed with a phrase from a positioning deck nobody has ever searched for. Reading the page top to bottom hides it, because the words underneath the heading are fine.

Write the promise

Four lines before any copy exists. If you cannot write them, the page is not ready to be written.

1. Name the audience and their task.Carry it forward from the intent work in module 3 rather than inventing a new one here. A page whose audience disagrees with the map is a sign one of the two is wrong.
2. State what this page provides that no other page does.Local detail, original data, a working tool, a process nobody else documents. If the honest answer is nothing, the page is a duplicate and the decision belongs back in the architecture.
3. Name the next action.What a satisfied reader does next, which is not always a form. Sometimes the right next action is another page, and pretending otherwise produces a call to action everybody ignores.
4. List the claims that need support.Assign an owner to each one now. Claims discovered during review are the ones that hold a page for two weeks while somebody finds a source.

You do not control the title link on the result page and you do not control the snippet. Search systems generate both, using your title element, your headings, your visible content, and the query somebody typed. What you write is an input with real influence and no guarantee.

Accepting that changes what good work looks like here. The goal is not to author a fixed advertisement. It is to make the page trivially easy to identify and describe correctly, so that whatever gets generated is accurate and recognizable.

You supply inputs, not appearances. Write something true and specific, and let the generated version be right.

Writing an input rather than an advertisement

A title rewritten by the engine is not a failure. It usually means the engine found something on the page that matched the query better than your title did, which is information: either your title is vague, or the page is serving a query you did not write it for.

Both of those are worth investigating and neither is fixed by adding characters. Length rules are the most persistent superstition in this part of the job. There is a truncation width, it varies by device and query, and it is a presentation constraint rather than a ranking input.

What makes a title work

Best is the claim worth removing. Unless a defensible comparison exists somewhere a reader can check, best is a word that costs nothing to write and provides nothing to believe. It also invites a comparison the page has not done and cannot win.

The description is a summary, not a pitch

A meta description earns its place when it summarizes what the page actually contains, in terms somebody scanning results would recognize. It gets used when it fits the query, and ignored when the page contains something that fits better, which is the correct behavior.

The failure mode is a description that promises something the page does not deliver. That produces a click, then an immediate return to the results, and it teaches everyone involved the wrong lesson. Duplicate descriptions across a template are a smaller version of the same problem: they make every page look identical at exactly the moment somebody is choosing between them.

Draft and check the metadata

Six checks, and the last two are the ones people skip because they require looking at other pages.

1. Write the title from the page promise.The promise names the task and the audience, which is most of a good title already. Writing from the keyword instead is where stuffing comes from.
2. Put the distinguishing word first.Whatever separates this page from its siblings should survive truncation. For a location page that is the location, not the service everyone else also offers.
3. Align the visible heading with it.The H1 and the title should make the same promise. When they disagree, the engine has two candidate descriptions of your page and will pick whichever suits the query, which may not be the one you meant.
4. Write a description that summarizes the real content.Describe what is there, including the specific thing nobody else has. A generic summary is a wasted opportunity to be chosen from a list.
5. Check for duplicates across the template.Titles and descriptions that vary only by a swapped word are a template problem, not a copy problem, and they surface as a template fix in module 4's queue.
6. Remove claims the page cannot support.Best, fastest, cheapest, and number one. Each one needs evidence on the page or it needs deleting, and deleting is usually faster.

This is the part of on-page work with the worst folk wisdom attached. Keyword density, exact-match repetition, a target word count, and a rule about how many internal links a page should carry. None of these describe how a page becomes useful, and several of them actively damage it.

The useful version is simpler and harder. Answer the task early, cover the decisions the reader actually has to make, provide something original, and put links where somebody's job changes.

Coverage and clarity, not repetition. A page earns its place by containing something that is not available elsewhere.

Answer the task early

Somebody arriving on the Austin page wants to know whether this firm handles cases like theirs. Making them read four paragraphs of context before that becomes clear is a choice, and it is the choice most service pages make, usually because the page was written in the order the author thought about it.

Put the answer near the top and use the rest of the page to support it. This costs nothing in depth. A reader who is satisfied in the first screen and keeps reading is a reader who trusts the page, and readers who bounce from the first screen were never going to reach paragraph five.

Original evidence is the whole differentiator

Everything else on a page can be assembled from what already ranks. Original evidence cannot, and it is the only durable reason for a page to exist. It is also the part that gets cut first when a deadline moves.

Horizon's version is specific and cheap to produce. A short fee section written in plain terms, a claim-process diagram drawn from how the firm actually works, and case detail that shows familiarity with local courts. None of that requires research budget. It requires asking somebody in the business twenty minutes of questions.

The anti-pattern is six near-identical city paragraphs. It looks like coverage and adds nothing a reader in any of those cities can use, which is the same failure as the city-swap pages from module 3 happening inside a single page instead of across several.

Links belong where the task changes

Links in navigation and footers are not contextual links and do not do this job. They are the same on every page, which means they cannot respond to where a particular reader is in a particular task.

Images that carry information

An image earns its place when it communicates something the text would take a paragraph to say. A diagram of the claim process qualifies. A stock photograph of a handshake does not, and it costs load time to say nothing.

Alt text describes the role, not the keyword. For the claim-process diagram, write what the diagram shows and why it matters, in a sentence a person listening to it would understand. Stuffing it with terms produces text that fails its actual audience while providing no benefit to the one people imagine it is for. Genuinely decorative images take empty alt text, which is the correct answer rather than a missed opportunity.

Filenames, dimensions, and captions are worth getting right for the same reason. A caption is read far more often than body copy, which makes it one of the most valuable places on the page to say something specific.

Improve the page

Seven passes over one page. Each one is a separate read, because trying to do them together means doing the easy ones and calling it finished.

1. Move the answer to the primary task upward.Find where the page currently answers it and ask what the material above it is doing. Usually it is context the author needed and the reader does not.
2. Organize the rest under descriptive headings.Headings that name the decision a reader is making, so somebody scanning can find their question. Clever headings cost the scanner time and buy nothing.
3. Add the original evidence.The fee detail, the process diagram, the local specifics. This is the step that makes the page worth keeping, so it is the one to do before you run out of time rather than after.
4. Cut the sections that do not serve the promise.Length is not coverage. A section that exists because a competitor has one is a section the reader scrolls past on the way to something they wanted.
5. Place contextual links where the task changes.Then check each anchor describes its destination. Both halves matter, and the second one is where most link work quietly fails.
6. Replace decorative images with informative ones.Or remove them. An image that communicates nothing is load time spent on nothing, which shows up later as a performance finding nobody can explain.
7. Write alt text for a person who cannot see the image.That audience is real and specific, and writing for them produces better text than writing for a crawler that was never the intended reader.

Structured data has acquired a second, false reputation: that it is the switch you flip to get mentioned by AI systems. It is not, and treating it as one produces a specific kind of waste, because markup is cheap to add and its failure is silent.

Module 4 covered auditing schema that already exists. This lesson is about writing it, and the two constraints that decide whether it was worth writing at all.

Markup describes a page. It never improves one, and eligibility is not an appearance.

Choosing a type and filling it honestly

Pick a type that genuinely describes what the page is, and prefer the boring ones. Horizon uses Organization for identity and BreadcrumbList for navigation, both of which describe things a visitor can see, and both of which are stable across template changes.

Include the required properties, then the recommended ones that happen to be true. Recommended is not a target to hit. A property filled with something approximately accurate in order to complete a set is worse than an absent property, because it is a claim rather than an omission.

Match the visible page in meaning, not just in string. The facts in the markup have to agree with what a reader can find on the page. FAQ markup describing answers hidden behind an accordion nobody opens, or reviews that appear nowhere, is the version of this that draws manual attention.

Four things schema does not do

The fourth is the one that costs real money. A team ships markup for a feature whose underlying page is broken, the validator passes, the enhancement report stays empty, and six weeks disappear before anybody connects the silence to the rendering failure underneath it.

Why the citation belief persists

It is worth understanding where the myth comes from, because dismissing it without an explanation loses the argument in the room. Sites that get cited by answer engines do tend to use structured data. That correlation is real and it is not causal: both are downstream of being a well-built site run by an organization that maintains it.

Those same sites have clear headings, content that survives rendering, facts that agree across pages, and somebody responsible for keeping them current. Any one of those is a more plausible reason to be retrieved and quoted than a block of JSON in the head, and all of them take real work, which is precisely why markup looks attractive by comparison.

Add it because it describes your page accurately. That reason holds up on its own, requires no promise anybody has to keep, and survives the next time a vendor blog announces the mechanism has changed.

Markup fails silently, so give it an owner

Every other on-page element announces its own breakage. A missing title is visible. A broken image is visible. Structured data that stopped matching the page after a template change looks exactly like structured data that is working, from every angle except a validator nobody has run in eight months.

That makes it the one part of a page needing a scheduled check rather than an incidental one. Put the enhancement report on a review cadence and re-validate the affected templates whenever the front end ships a change to them. A property that quietly started emitting an empty string is not a small problem when the property is describing prices.

Add markup you can defend

Four steps, and the third is the one that separates useful markup from a liability.

1. Confirm the feature is documented and the page qualifies.Start from the documented appearance you are trying to become eligible for, then work back to the type. Starting from the type produces valid markup for nothing in particular.
2. Fill required properties, then true recommended ones.Stop when the true ones run out. Completeness is not the goal; accuracy is, and an approximated property is a claim you will have to defend.
3. Read the markup against the rendered page.Every fact in it should be findable by a person looking at the page. Anything only present in the markup is a discrepancy waiting to be found.
4. Validate, then watch the enhancement report.Syntax validation says the markup parses. The enhancement report over the following weeks is the only evidence about whether it did anything, and it is where a silently broken deploy shows up.