On-page SEO is a sequence, not a checklist
On-page SEO is every choice baked into one URL. The title tag, the headings, the body copy, the internal links, the structured data, the Core Web Vitals scores. Most guides present those choices as a flat checklist, ranked by what looks technical instead of what actually moves the needle. The work has a priority order, and shipping the order is what compounds.
This chapter covers the per-page craft for anyone building something on the web. Crawling, indexing, and ranking (the three jobs of a search engine, covered in chapter 1 on how search engines work) define why on-page matters at all. Sitemaps, canonicals, and internal-link architecture (covered in chapter 2 on SEO basics) build the scaffolding around it. On-page SEO is what fills each URL inside that scaffolding, in priority order.
The four to five hours of attention that go into one page are budgeted by priority. The top of the order pays more than the bottom, and most of the bottom is already taken care of by a modern host like Vercel, Netlify, or Cloudflare Pages. Ship the order, not the checklist.
The title tag is the only line Google might keep verbatim
The title tag is the HTML element that names the page The title tag lives inside the <head> of a page as <title>...</title>. It is the line shown in the browser tab, the SERP, the social share preview, and the AI answer engine’s page label. One tag per page, no fallback. It is commonly called the “meta title”, though the spec name is just “title”. and the single highest-leverage edit on the whole ladder. It is the line on the SERP a user actually clicks, the label an LLM uses to refer back to the page in a synthesized answer, and the one edit that can move ranking and click-through inside a week. No other on-page element moves that fast.
As of 2026, Ahrefs reports Google rewrites title tags 61.6 percent of the time across the SERPs they analyzed, which feels like an argument for not bothering. It is the opposite. The original title still influences ranking even when Google replaces it on the SERP, and the rewrites tend to compress and reorder, not invent, at least in my experience. A weak title rewritten still trades on the weak version’s bones, a strong title is the floor Google rewrites toward.
<!-- Before, the launch default -->
<title>Home | RunFit</title>
<!-- After, the title that earns clicks and citations -->
<title>Best running shoes for flat feet (2026 picks) - RunFit</title>The rewrite locks three things into one line, in this order:
- The query the page targets goes first, taken from the keyword research stage covered in chapter 3 on picking the query that earns this page.
- A specific that makes the page concrete sits inside parentheses or a comma clause, in this case the year and the format.
- The brand name closes the line so the user recognizes the source on a scanned SERP.
Forty-six characters, under the truncation limit on desktop and mobile. If a title runs long, the brand tag is the first thing to drop, since the source domain is visible on the SERP regardless and the query terms earn the click.
As of 2026, Backlinko’s analysis of title sentiment puts emotional titles at a 4.1 percent absolute CTR lift over neutral ones, which is large in a category where most teams chase fractions of a percent. Positive sentiment beats negative on average, but only when honest. A title claiming “the best” on a page that lists three options is fine, a title claiming “you have been doing this wrong” on a page that does not actually call out the wrong thing loses trust on the first scroll. The dishonest emotional title earns the click and forfeits the citation, because the LLM that read the page can tell the title overpromised.
Meta descriptions earn the click when Google bothers to show them
The meta description is the short summary tag below the title in the SERP, and it decides which result a user picks when several pages look similar at a glance. It is not a ranking factor, Google has confirmed the tag has not been one since 2009, and yet the field is worth writing on every page that earns paid attention. As of 2026, Ahrefs reports meta descriptions appear in SERPs 37.22 percent of the time across their sample, which means almost two out of three impressions show a Google-rewritten snippet instead. The third where it shows is the third where the click is decided by sales copy, not by SERP-generated text.
<meta name="description" content="Three stability shoes our reviewers tested on flat-footed runners in 2026, with the arch notes and fit checks that decided each pick.">The number that makes the field worth the five minutes is the click delta. As of 2026, Mangools found pages with meta descriptions get 5.8 percent more clicks than pages without, averaged across queries in their sample. A page that ships without a meta description is a page that left a tax on the table, because the auto-generated snippet rarely sells the way an intentional sentence does. The failure mode is the opposite extreme: a meta description that promises something the page does not deliver loses the second click and earns a bounce, which Google reads as a negative signal.
The cap is 160 characters on desktop and 120 on mobile, and Google clips beyond the limit without a softer cutoff. The honest move is writing for mobile first, which is the cap that holds across surfaces. A 120-character description does not feel cramped if it leads with a number and a specific.
Heading structure is the page’s table of contents for humans and machines
Headings are the H1, H2, and H3 tags that segment any page into navigable units. Together they form a tree, and the tree is the page’s table of contents for screen readers, for crawlers, and for the passage-extraction layer of every AI answer engine. A page with one H1, three H2s, and a sprinkle of H3s under each is easy to chunk. A page with five H1s because the designer liked the size is a page no chunker can resolve.
<h1>Best running shoes for flat feet</h1>
<h2>Why flat feet need a stability shoe</h2>
<h3>Overpronation explained</h3>
<h3>Arch support vs medial post</h3>
<h2>Our three picks</h2>
<h3>Brooks Adrenaline GTS</h3>
<h3>Asics Gel-Kayano</h3>
<h3>Hoka Arahi</h3>
<h2>How to test the fit at home</h2>The hierarchy matters because the content brief that produced the heading outline (covered in chapter 4 on SEO content) is the same outline the model sees when it lifts a passage. An LLM answering “what is overpronation” wants a passage tagged with that exact phrasing. It looks for a heading that names the concept. It checks that the page sits inside a site with topical authority around running shoes. Three matching layers route the model straight to the paragraph worth citing.
H1 is a special case. One per page, the same topic the title tag promises, ideally close to but not identical to the title text. A title tag that reads “Best running shoes for flat feet (2026 picks) - RunFit” pairs cleanly with an H1 that reads “Best running shoes for flat feet”. The repetition without duplication tells the engine and the reader that they have arrived at the right page.
Anchor text routes attention, internal links route ranking
An internal link is a hyperlink from one page on your site to another, and the anchor text is the visible label on that link. The link itself routes ranking authority, the anchor text labels the destination for both readers and search engines. Site architecture (which pages connect to which, covered in chapter 2 on the silo structure that compounds) decides the link graph, this section decides what each connection says inside that graph.
Three things change when the anchor reads like the destination. The search engine learns what the destination page is about from the inbound anchors, which is one of the oldest and most durable signals in ranking. The reader scans the link and decides whether to follow it, which is the difference between a click and a hover. The screen reader announces a coherent label instead of “learn more, link, learn more, link”, which is an accessibility win that costs nothing.
The opposite extreme also fails. Anchors that are exact-match keyword stuffing (“buy running shoes for flat feet cheap online”) read as manipulation to Google’s spam systems and can earn an algorithmic demotion, especially when repeated across a site. The honest target is a descriptive phrase that names the destination page in the same words a reader would use, not a phrase engineered to repeat the target keyword. Three internal anchors saying “running shoes for flat feet” across one product site is fine, 30,000 saying it across the same site is a flag.
Two anchors that look the same are not the same. An anchor inside body copy carries more weight than the same words in a footer or sidebar, because the engine reads body anchors as editorial choices and navigation anchors (the ones in the header, footer, and sidebar) as boilerplate that appears on every page. A footer linking to “running shoes for flat feet” still helps a little, an in-paragraph link to the same page helps materially more. The cheap upgrade on most sites is moving the second and third links out of the footer and into the prose where they belong.
Schema is how the page introduces itself to machines
Schema markup is a small block of JSON-LD that labels what the page is in a vocabulary machines understand JSON-LD is the format Google recommends for structured data, embedded inside a <script type="application/ld+json"> block in the page head or body. The vocabulary comes from schema.org, a shared standard maintained by Google, Microsoft, Yahoo, and Yandex. . The schema tells a crawler that the page is an Article, with an author, a publish date, a headline, and a topic. The crawler already guesses most of that from the HTML, schema makes the guesses cheap and unambiguous.
For a builder running an editorial product (a sizing guide, a curated review, a how-to), Article schema is the right entry point. For a builder running a transactional product (a single shoe product page, a SaaS pricing page), Product or SoftwareApplication schema is closer to the truth. The two are mutually exclusive on a single URL, and picking the wrong type tells the engine the page is something it is not.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Best running shoes for flat feet (2026 picks)",
"author": {
"@type": "Person",
"name": "RunFit Editorial"
},
"publisher": {
"@type": "Organization",
"name": "RunFit",
"url": "https://runfit.example.com"
},
"datePublished": "2026-05-12",
"dateModified": "2026-05-12",
"mainEntityOfPage": "https://runfit.example.com/running-shoes/best-for-flat-feet"
}
</script>The block above is twelve lines of declared truth. Each field maps to a specific signal an AI answer engine looks for at retrieval time. The headline matches the H1 and the title tag. The author and publisher confirm the entity behind the words, which is one of the rougher signals models use to weight credibility. The datePublished and dateModified pair tells the model how fresh the content is, which is checked against the page body to catch fake date bumps. The freshness check also reads visible date language inside the prose, “as of May 2026”, “tested in 2026”, version numbers, so a page where the schema dates and the body dates disagree survives less well than a page where they line up.
For a single shoe product page, the Product schema below carries more weight than Article, because the page is an offer to buy, not a piece of editorial.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Brooks Adrenaline GTS 24",
"image": "https://runfit.example.com/img/brooks-adrenaline-gts-24.jpg",
"description": "Stability shoe with a holistic support system, tested on flat-footed runners in 2026.",
"brand": { "@type": "Brand", "name": "Brooks" },
"sku": "BR-AD-GTS-24-M9",
"offers": {
"@type": "Offer",
"url": "https://runfit.example.com/shop/brooks-adrenaline-gts-24",
"priceCurrency": "USD",
"price": "140.00",
"availability": "https://schema.org/InStock"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "182"
}
}
</script>The Product block carries different fields than Article for a reason. Offer, price, availability, and aggregateRating give a retrieval layer the structured signals it needs to surface the shoe inside a price-and-availability query, which is the kind of question an agent answering “where can I buy stability running shoes for flat feet” cares about. Reviews and ratings only ship inside the schema when they exist in the visible body too, the same rule as FAQPage.
Schema validators are cheap and free. Google’s Rich Results Test catches malformed JSON-LD before it ships, the Schema.org validator catches type mismatches. Run both before the deploy, run them again after any template change, and treat any error as a deploy blocker. A page with broken schema is worse than a page with no schema, because the engine reads the malformed block as a signal that the publisher does not know what they are doing. The opposite failure is over-marking: stacking Article, Product, FAQPage, HowTo, and Course on the same page does not increase ranking, it increases the cost of any single misclassification because the engine cross-validates the claims against the body content.
LLM-friendly chunking is the on-page work that wins citations
Chunking is the structural choice that makes one URL citable in many ways. AI answer engines retrieve at the passage level, not the page level, which means a 3,000-word page is read by the model as ten to fifteen short passages competing on their own merits. The pages that win citations are the ones structured so each passage answers one question cleanly, instead of one page sprawling across one topic.
Query fan-out is the mechanism behind why this matters. When a user asks ChatGPT or Perplexity “what running shoes work for flat feet and a first marathon”, the model rewrites the prompt into three or four search queries, retrieves a handful of pages for each, and synthesizes one answer. A single page that addresses three of the fan-out queries from three of its own passages can earn three citations from one retrieval pass, which is the upper bound for that page.
Five habits make a passage citable on its own. The subject of the passage is named in the first sentence, with no backward pronoun. The middle sentence carries the densest information, a number, a date, a name, or a mechanism. The closing sentence draws the implication, which is the cheapest hook for a model to lift verbatim. The passage names its own scope (“for flat-footed runners under 200 lbs”, “for a marathon under four hours”) so a retriever pulling it in isolation knows who the advice applies to. The whole passage runs 50 to 90 words, which fits inside a chat answer without truncation.
The inverse is just as predictable. Passages over 120 words get truncated in chat responses and lose pairwise comparisons to shorter competitors. Passages that bury the subject in the third sentence are unretrievable because the retriever cannot resolve what the passage is about from its first line. Passages that open with a backward pronoun (“This means”, “They argue”, “It works because”) cannot be lifted out of context, because the antecedent sits in the previous paragraph the model never read. Passages that argue one side without acknowledging the failure mode read as biased to the retriever, which is trained to flag single-sided sources.
The shape ties back to the citation-pull pattern observed in chapter 4 on SEO content, which explains that roughly 44 percent of citations land in the first third of the page, 31 percent in the middle, and 25 percent in the closing third (averages from a mid-2026 sample, treat the ratio as directional, not fixed). Chunking is what gives every third of the page passages worth pulling. Without it, the first third becomes the only third the model bothers to read, and the rest of the page sits unread no matter how long it runs.
Core Web Vitals matter, just not as much as you think
Core Web Vitals are three performance metrics Google reports for every URL The three Core Web Vitals as of 2026 are Largest Contentful Paint (LCP, how fast the main content loads, threshold 2.5 seconds), Interaction to Next Paint (INP, click responsiveness, threshold 200 milliseconds), and Cumulative Layout Shift (CLS, how much the layout jumps, threshold 0.1). The data is from real Chrome users, not synthetic tests. . They are a real ranking signal, and they are also the part of on-page SEO that people tend to overspend on. A whole Saturday on Lighthouse rarely changes the page’s position the way a fresher title tag does, because Vitals are a tiebreaker between pages already similar on content, not a lever that pulls a poor page upward.
The mobile share is the number that decides which rendering to measure first. Siteimprove reports mobile share at 62 percent of internet traffic in Q4 2024, and Google’s mobile-first indexing has been the default since 2019. The Lighthouse score that matters is the mobile one, on a throttled 4G connection, not the desktop score that the dev machine generates over fiber. A static site on a CDN passes the mobile run without intervention, a heavy single-page app with client-side data fetching often does not.
The three Vitals also reward different fixes. LCP usually improves by serving the hero image as a properly sized, modern-format file from a CDN, the first time. INP usually improves by deferring non-critical JavaScript, especially analytics and chat widgets that block the main thread. CLS usually improves by setting explicit width and height on images and embeds, so the browser reserves the space before the asset arrives. None of the three requires a framework rewrite, all three require one careful afternoon.
On-page SEO compounds when you ship the sequence in order
The same /running-shoes/best-for-flat-feet URL evolves layer by layer through the chapter. The title tag rewrites from “Home | RunFit” into a line that earns clicks and labels the page for LLMs. The meta description gets written, not generated. The H1 and H2s tighten into a tree that doubles as the passage map. The anchors on internal links stop saying “learn more” and start saying what they link to. Article schema confirms the entity, the author, the dates. Passages chunk into 50 to 90 word units. Core Web Vitals get checked once the rest is right.
The sequence compounds because each layer assumes the one beneath it is in place. A title tag that earns a click pays nothing if the page below it cannot hold the reader, the heading tree is what holds attention. A heading tree designed for passages pays nothing if the schema does not label the entity, schema is what labels it. A labeled entity with chunked passages still leaks ranking authority if the anchors on internal links read “learn more”, the anchors are what aim the signal. Vitals are the last polish, useful only because the four layers above are right.
The on-page work hands off cleanly to the rest of the guide. Chapter 6 covers off-page work, the links and mentions that arrive from other sites, which combines with on-page craft to set the ceiling on what any one URL can rank for. Chapter 7 covers the technical layer, the indexing health and rendering choices that decide whether on-page craft even reaches the index. Chapter 8 covers the AEO surfaces specifically, where the chunking habit, the schema, and the title tag are read by retrieval layers that did not exist five years ago. The on-page sequence in this chapter is the spine, the rest of the guide is the muscle around it.
Ship one URL through the sequence, in order, and watch it move. Then ship the next one. Compounds.