Ultimate Guide to On-Page SEO (2026)

On-page SEO is everything a page controls about its own performance in Google: the title, the description, the headings, the words, the images, the internal links, the structured data, and the speed at which all of it renders. This guide is written for founders and practitioners who want to stop guessing at character counts and start verifying against the documents Google actually uses. Every section maps an on-page element to the Google Search Central page that governs it, shows the fix in real HTML, and ends with a live check you can run on your own site right now.

What On-Page SEO Covers in 2026: Elements, Intent, and Where It Fits

On-page SEO is the set of changes you can make to a single page and its HTML so that Google can understand it, trust it, and present it well in search results. It sits between off-page SEO, which is mostly links and mentions from other sites, and technical SEO, which is crawlability, indexing, and site architecture. The distinction matters because it tells you who is responsible for a fix. If a page is not indexed, that is technical. If it ranks but earns no clicks, that is usually on-page. If it loses to a worse page, that is often off-page.

Google Search Essentials define the floor for everything on this list: a page must be accessible to Googlebot, free of cloaking, compliant with the spam policies, and written to be helpful to people rather than to search engines. Google Search Essentials (2022) describe that floor in plain terms, and it is the first thing to check before you optimize anything. Once a page clears that bar, the on-page work is about precision: saying exactly what the page is for, in the places Google looks.

The elements a page controls

A page directly controls the title element, the meta description, the heading structure, the URL slug, the body copy, the image markup and alt text, the internal links it sends out, the structured data it declares, and much of its own load speed and layout stability. Each of these is an on-page element. The common thread is that none of them requires permission from another site, and all of them are testable in a browser or in Search Console.

This guide follows one rule for every element: name the Google document that governs it, state the dated rule, and attach a live check. The map below is the spine of the whole guide, and each row gets its own section later.

On-page vs off-page vs technical SEO

Off-page SEO covers the signals that come from other domains: backlinks, brand mentions, and reviews. Technical SEO covers the machinery that lets a crawler reach and parse a page: crawling, rendering, redirects, and indexation. On-page sits in the middle, and in practice the three overlap. A slow page is a Core Web Vitals problem that you fix in the HTML and hosting, so it is both on-page and technical. The clean split helps you diagnose, not to build silos.

Search intent first, elements second

Before you touch a title or a heading, decide what the page is for. A page that answers a transactional query should say so in its title and offer the product fast. A page that answers an informational query should give the answer in the first screen, not bury it under an introduction. Optimizing the elements without nailing the intent produces a page that is technically tidy and still fails, because it promises one thing and delivers another. Every fix later in this guide assumes you have already matched the page to the query it targets.

How Google Generates Title Links and Snippets From the Rendered Page

The most important shift in on-page SEO over the last few years is that Google no longer simply echoes your HTML. It generates the title link and the snippet from the rendered page, and it may ignore your title element entirely if a better label exists on the page. Google says it uses the title element most of the time, but it can replace it with text from an H1, other prominent descriptive text, or even an anchor on another page. Google title link documentation (2021) states this plainly, and it changes how you should think about every element: you are not writing a title tag in isolation, you are writing a whole page that has to describe itself consistently.

The title link is generated, not just echoed

In August 2021 Google announced an update to how it generates title links, saying it would use text beyond the title element when the title element is missing, boilerplate, or stuffed. Google's title link update (2021) is the source for that change. The practical lesson is that your title element, your H1, and your first sentence all have to agree. When they disagree, Google picks one, and it may not be the one you wrote.

Snippets come from the page, not only the meta description

The same principle applies to the snippet, the two lines of descriptive text under the title link. Google uses the meta description as the snippet in many cases, but it can also pull text from the page itself when the page text better answers the query. Google snippet documentation (2024) confirms the meta description is one source among several, not a guaranteed display field. This means your opening paragraph is a snippet candidate too, and it should be written to survive being cut off mid-sentence and shown out of context.

The word "rendered" matters here. Googlebot executes JavaScript and reads the page as a browser does, so the text it uses for titles and snippets is the text that exists after rendering, not the raw HTML source alone. A title or snippet that depends on client-side JavaScript may or may not be seen the way you intend. The safe pattern is to keep the critical descriptive text in the initial HTML, so the rendered page and the raw source tell the same story. Run your page through the SERP preview tool to see the rendered title and snippet as Google is likely to show them.

The 2026 On-Page SEO Master Checklist: Every Task, Ranked by Impact

This checklist orders the work by how much a typical fix moves rankings or clicks, highest first. It is a starting order, not a law. A page that already has a strong title but broken internal links should skip the title and fix the links. The point of ranking by impact is to stop you from spending an hour on alt text while the title link is still wrong.

Work the list top to bottom on a new page, and use the on-page SEO checker to produce a heading outline and catch the mechanical misses before you publish. The rest of this guide explains each row in the order of the outline, not in the order of impact, so you can read it as a reference as well as a plan.

Title Tag Best Practices: Write Titles Google Will Keep, With Before and After HTML

The title element is the highest-impact text on the page. It is the headline in the search results, the label in the browser tab, and a major input to how Google decides what the page is about. Google's guidance is blunt: use a unique, descriptive title for every page, and avoid long, boilerplate, or keyword-stuffed titles. Google title link documentation (2021) warns against all three failures because they are the ones that trigger a rewrite.

Write for the user, then for the query

A title has one job: tell a searcher whether this page answers their question, and persuade them it does it better than the other results. The query words belong in the title, but they belong in a sentence, not in a list. Put the most important words first, because that is what a scanning reader sees, and because Google weighs the front of the title more heavily in practice. Keep the brand at the end, and drop it entirely when it adds nothing to a page that already ranks for a specific query.

The before and after HTML

Here is a head block with a keyword-stuffed title and description, followed by the same block fixed against Google's rules. The fix keeps the primary keyword, removes the repetition, and writes both fields as sentences a person would actually read.

<!-- Before: keyword-stuffed title and description -->
<head>
  <title>Buy Running Shoes | Best Running Shoes | Cheap Running Shoes Online</title>
  <meta name="description" content="Running shoes, best running shoes, cheap running shoes, buy running shoes online, running shoes for men and women at the lowest prices.">
</head>

<!-- After: one clear title and a description that earns the click -->
<head>
  <title>Trail Running Shoes for Wet Conditions: 9 Tested Pairs</title>
  <meta name="description" content="We ran nine trail shoes through mud, rain, and river crossings. See which pairs grip, drain, and dry fastest, with sizes and weights for each.">
</head>

After you rewrite a title, check it in the SERP preview tool to see where it truncates on a phone and a desktop, and use the meta tag checker to confirm the tag is present and well-formed. Google supports a specific set of meta tags and ignores the rest, so a malformed or unsupported tag is wasted effort. Google's supported meta tags (2024) list the ones worth writing.

Meta Descriptions That Earn the Click: What Is Real vs. the Ranking Myth

The meta description is the most misunderstood field in on-page SEO. It is not a ranking factor, and it never was in the way most advice implies. Google is explicit that the meta description does not affect rankings, and that Google may use it or other page text as the snippet. Google snippet documentation (2024) states both points. What the description does affect is the click, and the click is what you are optimizing for once you already rank.

What a meta description actually does

The description is your chance to write the ad for a page you do not pay for. When Google uses your description, it is because the text is specific enough to help the searcher. When Google ignores it, it is usually because the page text answers the query better. Either way, a well-written description does two jobs at once: it sells the click, and it gives Google a clean snippet candidate that matches the page.

Write for the click, not for a character count

Google has no fixed character count for snippets, and it truncates long title links and meta descriptions to fit the device width, cutting them with an ellipsis. Google snippet documentation (2024) says this directly, which is why the recycled "155 to 160 characters" rule is wrong as a hard limit. Write a description that puts the value and the specific outcome in the first line, then stop when the sentence stops. If it runs long, the important part should already be visible before the cut.

A strong description names the reader's problem and the result the page delivers, in plain words. It is not a list of keywords, and it does not need to repeat the title. Preview it in the SERP preview tool at both phone and desktop widths so you can see exactly where Google will cut it off.

Heading Structure and H1 Rules: One H1, Logical Hierarchy, Real Keywords

Headings do two jobs. They structure the page for readers who scan, and they tell Google which ideas are the main ones and which are subordinate. A heading hierarchy that jumps from H1 to H4, or uses three H1s, sends a muddled signal about what the page is actually about.

One H1 per page

Use a single H1 that states the page's topic, and make it agree with the title element. Google will use the H1 as a candidate for the title link if it decides to rewrite the title, so the H1 carries more than outline weight. Google title link documentation (2021) names the H1 and other prominent text as rewrite sources. One H1, one topic, one promise that the rest of the page keeps.

A logical hierarchy, not a styling shortcut

Headings are semantic, not decorative. Do not pick an H4 because it renders smaller; pick the level that reflects the document structure. A typical page is one H1, several H2 sections, and H3 sub-points under each H2 where the section needs them. Skipping a level, like jumping from H1 to H3, is a small but real signal that the structure is loose. Run the on-page SEO checker to print the heading outline and catch missing or skipped levels in seconds.

Put real keywords in headings, not stuffing

Headings should contain the words a searcher would use, phrased naturally. A heading like "How to choose a running shoe" works. A heading like "Running shoes: how to choose running shoes for running" is stuffing, and it reads as such to both people and Google. Each heading should earn its place by introducing what follows, and the keyword should fall into that sentence without forcing it.

URL Slugs and Crawlable Links: Anchor Tags, Descriptive Text, No JavaScript-Only Links

A page has two kinds of on-page links that matter: the slug that names the page, and the anchors on the page that lead elsewhere. Both have to be readable by a crawler and by a person, and both have to be descriptive without being stuffed.

Slugs that read like a sentence

A slug should be short, lowercase, hyphenated, and made of the words a human would say out loud. "trail-running-shoes" beats "product-1234" and beats "trail-running-shoes-for-wet-conditions-2026-best-review" because the first is descriptive and the second is padding. The slug appears in the result, so it is part of the click decision, not just a technical detail. Change a slug only with a redirect in place, or you throw away whatever the old URL had earned.

Anchor text Google can follow

Google can only reliably crawl links that are implemented as plain anchor elements, and it recommends descriptive anchor text rather than "click here" or bare URLs. Google's crawlable links documentation (2022) states the anchor rule and the descriptive-text rule together. Anchor text is also a signal: the words you use to point at a page tell Google what that page is about, which is why the same descriptive anchors that help readers also help rankings.

No JavaScript-only links

A link that exists only as a JavaScript click handler, or as an un-anchored element with an onclick, may not be followed at all. Google's crawlable links documentation (2022) is explicit that only anchor elements and equivalents are reliable. If a menu or a "load more" button builds links in JavaScript, make sure the same targets also exist as real anchors in the HTML, or Google may never reach the pages you are pointing at. This is where on-page and technical SEO meet: the technical SEO guide covers the crawl side in more detail.

Keyword Placement That Still Matters: First 100 Words, Headers, and Semantic Coverage

Keyword placement in 2026 is not about density. It is about making sure the page announces its topic early, uses the topic's natural vocabulary, and covers the subject completely enough that Google does not need to guess what it is about.

The first 100 words

State the topic and the answer in the opening paragraph. Google uses the beginning of the page as a strong signal for what it is about, and it uses the same text as a snippet candidate when the meta description is missing or weak. A page that opens with background fluff before naming the topic is giving up its clearest signal. Put the primary phrase and a direct answer in the first hundred words, in a sentence a person would write.

Headers and semantic coverage

The body should use the primary keyword in the H1 and the first paragraph, and then cover the related terms a real expert would use. Google understands related words and concepts, so semantic coverage means writing the full subject: if the page is about trail running shoes, it should mention traction, drainage, drop, lugs, and toe protection, because that is what the topic actually contains. You do not need to repeat the exact phrase, and you should not force it where it does not fit.

Keyword density is not a target

There is no magic percentage, and chasing one produces the stuffed copy that Google's systems and human readers both reject. Write the page to answer the question completely, use the topic's vocabulary naturally, and stop. If the phrase appears once in the title, once in the H1, and once in the first paragraph, the page has already announced itself clearly. More repetition adds risk, not ranking.

Image SEO: Descriptive Alt Text, WebP and AVIF, Lazy Loading, and Context

Images rank in Google Images, earn clicks, and support the text, but they also drag down Core Web Vitals when they are heavy or unstable. Google's image best practices cover both sides: descriptive, context-specific alt text with no keyword stuffing, support for WebP and AVIF, lazy loading, and placing images near the text that refers to them. Google Images SEO best practices (2024) state all four.

Alt text that describes, not stuffs

Alt text exists so a screen reader and a crawler can understand an image they cannot see. Describe the image specifically and in context. If the image is a close-up of a shoe sole after a muddy run, say so; do not write "running shoes running shoes best running shoes". The keyword belongs in alt text only when it genuinely describes the image, and stuffing it is a documented anti-pattern.

WebP and AVIF by default

Serve WebP or AVIF for photographs and complex images, with JPEG or PNG as fallbacks, and use SVG for simple graphics and icons. Modern formats are dramatically smaller at the same quality, which directly improves LCP and the overall page weight. Google lists JPEG, PNG, WebP, SVG, and AVIF as supported. Google Images SEO best practices (2024) confirm that list.

Lazy loading and context

Lazy-load images that sit below the fold so the browser does not fetch them until they are needed, but never lazy-load the hero image above the fold, which would delay LCP. Place each image next to the text that discusses it, because context helps Google match the image to the query and helps the reader see why it is there.

Here is an image block fixed with context-specific alt text, explicit dimensions to prevent layout shift, and lazy loading on a below-the-fold image:

<!-- Before: generic alt text and no dimensions -->
<img src="shoe.jpg" alt="shoe">

<!-- After: context-specific alt text, dimensions, lazy loading -->
<img src="trail-shoe-sole.webp"
     alt="Close-up of the outsole lugs on the Merrell Agility Peak after a muddy descent"
     width="1200" height="800" loading="lazy">

The width and height attributes prevent CLS by reserving space before the image loads, which ties image markup directly to a Core Web Vitals metric. Check your images and alt text together with the on-page SEO checker.

Internal Linking and Sitelinks: Anchor Text as a Ranking and Navigation Signal

Internal links are the wiring of a site. They pass crawl paths between pages, distribute whatever authority the site has, and tell Google which pages matter most by how often and how prominently they are linked. Anchor text does the describing, which makes every internal link a tiny on-page optimization for its target.

Anchor text as a navigation and ranking signal

Point at a page with the words that describe it, and vary the anchor naturally rather than repeating the exact phrase every time. A page about trail running shoes might be linked as "trail running shoes," "wet-weather trail shoes," and "the shoe review" across different contexts. This reads naturally to a person and gives Google a set of consistent, varied signals about the target. The same rule that applies to external anchors applies internally. Google's crawlable links documentation (2022) recommends descriptive anchor text in both cases.

Sitelinks are automatic, not hand-built

Sitelinks are the extra links that appear under some search results, pointing to popular interior pages. Google generates them automatically from a site's internal link structure and anchor text, and site owners cannot fully control them. Google sitelinks documentation (2023) says so directly. What you can do is build a clean, logical internal structure with descriptive anchors, which is exactly the structure sitelinks are generated from. You cannot request a sitelink, but you can make the underlying links worth surfacing.

Internal linking also feeds the canonicalization decision, because Google weighs internal links when it chooses between duplicate URLs. Google's consolidate duplicate URLs documentation (2023) lists internal linking among the signals. Consistent internal anchors toward one version of a page are a quiet way to make your canonical choice stick, which connects this section to the canonicalization section later in the guide.

Structured Data and Rich Results: JSON-LD, Schema.org, and the Rich Results Test

Structured data describes your page to machines in a vocabulary Google understands, which can qualify the page for rich results like review stars, FAQs, and product information. Google recommends JSON-LD, uses the schema.org vocabulary, and requires that the structured data describe content that is actually visible on the page and is not misleading. Google structured data intro (2023) states all three requirements.

JSON-LD is the format to use

JSON-LD sits in a script tag in the head or body and does not disturb the visible HTML, which makes it the easiest format to maintain and the one Google recommends. Keep it truthful: the data must match what a visitor can see on the page, and inventing ratings or prices you do not show is a violation that can cost you the rich result and invite a manual action.

Visible, non-misleading, and validated

Only mark up content that exists on the page, and only use types and properties from schema.org that fit what the page actually is. A service page should not claim to be an Article, and a product page should not invent reviews. After you add markup, validate it, because a typo in JSON-LD silently disables the entire block.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Trail Running Shoes for Wet Conditions: 9 Tested Pairs",
  "author": {
    "@type": "Person",
    "name": "Maya Chen",
    "url": "https://example.com/about/maya-chen"
  },
  "datePublished": "2026-07-30",
  "dateModified": "2026-08-12",
  "image": "https://example.com/img/trail-shoes-hero.webp"
}
</script>

This block marks up a real article with a real author, publish date, and image, all of which are visible on the page. Validate it in the schema checker before you deploy, then confirm the page is eligible for rich results in Google's Rich Results Test. A clean JSON-LD block that passes validation is the difference between structured data that helps and structured data that Google ignores.

E-E-A-T on the Page: Author Bylines, First-Hand Experience, and People-First Content

E-E-A-T stands for Experience, Expertise, Authoritativeness, and Trust. It is not a direct ranking factor with a score, but it is the lens Google's quality raters use to judge a page, and the qualities it describes show up as on-page signals you control. Google added Experience to the framework in December 2022, putting first-hand experience on the same footing as formal expertise. Google's E-E-A-T announcement (2022) documents that change.

Bylines and author pages

Put a real name on the page, link it to an author page, and make that author page say who the person is and why they know this subject. A byline that reads "Staff Writer" with no linked profile signals nothing. A byline that reads "Maya Chen, trail runner and shoe tester for six years" and links to a page with her background signals both expertise and experience. This is the cheapest E-E-A-T win available, and it is entirely on-page.

First-hand experience on the page

Show the work. If you tested nine pairs of shoes, show the mud, the river crossings, the worn soles, and the specific failures. Phrases like "we tested" mean nothing without the evidence that testing happened. First-hand experience is the Experience in E-E-A-T, and it is the part a competitor copying a listicle cannot easily fake. Photographs, named methods, and dated results are the on-page proof.

People-first content, not search-engine-first

Google's helpful content guidance asks whether the content provides original information, value, and first-hand experience, and it notes that the classifier operates sitewide, not page by page. Google's creating helpful content guidance (2022) frames the questions a page should answer yes to. A page written to rank for a keyword reads differently from a page written to actually help, and both Google and the reader can tell. Write for the person, then let the on-page mechanics in this guide make that page legible to Google.

Core Web Vitals and On-Page Performance: LCP, CLS, and Why INP Replaced FID

Core Web Vitals are three field metrics that measure how fast a page loads, how stable it is, and how quickly it responds to input. They matter on-page because they are measured on your actual pages and fixed in your actual HTML, CSS, and images. The three are Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint.

LCP: the load

Largest Contentful Paint measures how long the largest visible element takes to render. A good LCP is 2.5 seconds or less. Web.dev Core Web Vitals (2024) lists the thresholds for all three. The hero image, the heading font, and render-blocking scripts are the usual culprits, and the fixes are smaller hero images, modern formats, and preloading what matters.

CLS: the shift

Cumulative Layout Shift measures how much the page jumps around while it loads. A good CLS is 0.1 or less. Web.dev Core Web Vitals (2024) sets the threshold. The fix is reserving space for images, ads, and embeds with explicit dimensions, and never injecting content above existing content without warning.

INP: the interaction, and why it replaced FID

INP measures the latency of the slowest meaningful interaction, from tap to the next paint, rather than just the first delay. A good INP is 200 ms or less. Web.dev Core Web Vitals (2024) sets that threshold. The fix is less main-thread work during input: break up long tasks, defer non-critical JavaScript, and avoid huge third-party scripts that block the thread.

Measure your own pages rather than trusting a score from memory. The technical SEO guide goes deeper on the fixes, and the on-page point is simple: every element on this page, from the hero image to the schema script, either helps or hurts these three numbers.

Mobile-First Indexing and Device Parity: Optimize the Version Google Actually Indexes

Google finished moving the entire web to mobile-first indexing by late 2023, which means Google now indexes the mobile version of a page as the primary version. Google's mobile-first indexing announcement (2023) confirms the transition is complete. Every on-page decision in this guide now has to be judged on the mobile version first, because that is the version Google reads and ranks.

Google indexes the mobile version

Under mobile-first indexing, the content, headings, links, and structured data on the mobile page are the ones that count. If your mobile page loads a stripped-down version that drops the H1, the alt text, or the internal links, you are optimizing a version Google never uses as the primary record. Check that the mobile page and the desktop page carry the same substantive content.

Parity means the same content, links, and images

Device parity does not mean pixel-identical layouts. It means the same text, the same headings, the same links, the same images and alt text, and the same structured data appear on both versions. Google's guidance is to make content and metadata equivalent across devices, and the failure mode is a mobile version that hides half the page behind a "view desktop" toggle or a hamburger menu that JavaScript never renders. Keep the critical on-page elements in the initial mobile HTML, and you keep them in Google's index.

The fastest way to confirm parity is to fetch the mobile version in Search Console's URL Inspection tool and read what Google rendered. If the H1, the first paragraph, and the internal links are all present in that rendered HTML, your on-page work is actually being indexed.

Canonicalization Without Over-Engineering: Consolidating Duplicate URLs and Sitemaps

Canonicalization is the process of telling Google which URL is the real one when the same content exists at more than one address. It matters on-page because duplicate URLs split signals, and the rel="canonical" element is the most direct on-page tool for consolidating them. Google chooses a canonical URL using several signals, including the rel="canonical" link element, redirects, sitemap URLs, and internal linking. Google's consolidate duplicate URLs documentation (2023) lists those signals.

The signals Google uses to pick a canonical

The rel="canonical" element is a strong hint, not a command. Google weighs it against redirects, sitemap URLs, and your internal links, so the signals should agree. If your canonical tag points to one URL but every internal link points to another, Google has to choose between two conflicting hints. Make the tag, the internal links, and the sitemap all name the same URL, and the choice resolves cleanly.

<link rel="canonical" href="https://example.com/guides/trail-running-shoes">

Sitemaps: lastmod, changefreq, priority are optional

The sitemap protocol defines lastmod, changefreq, and priority as optional per-URL fields, not required ones. Sitemaps.org protocol (2016) states this directly. That means hours spent tuning priority values are wasted, because the field is optional and carries little to no weight. Keep lastmod accurate if you maintain it, but do not build a process around changefreq or priority, and do not treat the sitemap as a ranking lever. It is a discovery aid, nothing more.

The right level of canonicalization effort is one canonical tag per page, internal links that agree with it, and a sitemap that lists the canonical versions. Beyond that, stop. Over-engineering canonicalization into redirect chains and per-variant tags creates the very confusion you were trying to remove.

Why Google Rewrites Your Title or Snippet: Diagnose and Fix It

A rewritten title or snippet is the clearest sign that the page is not describing itself well. Google replaces a title when it is missing, boilerplate, or stuffed, and it regenerates a snippet when the page text answers the query better than your description does. Google title link documentation (2021) and Google snippet documentation (2024) together explain both behaviors.

Why a title gets rewritten

Worked example: a page sells trail running shoes, but its title reads "Home | Acme Outdoors". Google may rewrite it to "Acme Outdoors Trail Running Shoes" using the H1, because the H1 describes the page better than "Home" does. The fix is to write the title yourself, specifically: "Trail Running Shoes | Acme Outdoors". When you see a rewrite, compare the title Google produced with your H1 and first sentence, and you will usually see exactly where your title diverged from the page.

Why a snippet gets regenerated

Worked example: a page's meta description reads "We sell the best products at the best prices with great service." A visitor searching for "do trail running shoes drain water" gets a snippet pulled from the body instead, because the body paragraph about drainage answers the query and the description does not. The fix is a description that actually addresses a real query: "See how nine trail shoes handle water, from quick-draining mesh to fully sealed boots, with drainage times for each."

Fixing each one

For a rewritten title, align the title element, H1, and opening sentence, and remove any boilerplate or stuffing that invited the rewrite. For a regenerated snippet, read the snippet Google chose, then write a description that covers that same ground better, so Google keeps your version. Check both changes in the SERP preview tool before you publish, and confirm the title tag itself is valid with the meta tag checker.

Auditing Your Pages With Live Checks: URL Inspection, PageSpeed Insights, Rich Results Test, and SERP Preview

Everything in this guide is verifiable, and the verification is what separates a real on-page program from a checklist you mark off on faith. Four free checks cover the whole surface: URL Inspection for what Google indexed, PageSpeed Insights for performance, the Rich Results Test for structured data, and a SERP preview for how the result will look.

The four live checks

Search Console URL Inspection shows you the canonical URL Google chose, whether the page is indexed, and the rendered HTML Google saw. PageSpeed Insights reports LCP, CLS, and INP with the specific elements to fix. The Rich Results Test validates your JSON-LD and shows which rich results the page qualifies for. The SERP preview tool renders the title and snippet as they will appear on a phone and a desktop. Run all four after any meaningful change.

A worked before and after audit

Before: a page titled "Home" with a generic description, a hero image with no dimensions, a JavaScript-only menu, and no structured data. URL Inspection shows the page indexed but with a canonical that conflicts with its internal links. PageSpeed Insights shows LCP at 4.1 seconds and CLS at 0.23, both failing. The Rich Results Test shows no eligible markup. The SERP preview shows a rewritten title and a snippet pulled from the footer.

After: the title reads "Trail Running Shoes for Wet Conditions: 9 Tested Pairs", the description addresses the drainage query, the hero image is a sized WebP, the menu links are real anchors, and the page carries valid Article JSON-LD. URL Inspection shows one clean canonical that matches the internal links. PageSpeed Insights shows LCP at 1.9 seconds and CLS at 0.02, both in the good range. The Rich Results Test reports the page is eligible for an Article rich result. The SERP preview shows the title and description you wrote, kept intact.

That before-and-after is the whole discipline in one page: map each element to the Google document that governs it, fix it in HTML, and confirm with the on-page SEO checker, the schema checker, and the live tools Google provides. You do not have to trust any of the advice in this guide. Run the checks and watch them pass.

On-Page SEO Mistakes That Still Hurt Rankings: Fixed Character Counts, Ranking Myths, and Sitemap Priority

Most on-page advice recycled across the web is years out of date, and following it costs you the exact things this guide fixes. The three most common mistakes are all easy to spot once you know the primary sources.

Fixed character counts

The "50 to 60 character title" and "155 to 160 character description" rules are wrong as hard limits. Google has no fixed character count and truncates by device pixel width. Google snippet documentation (2024) states this directly. The right practice is to write for meaning, put the key words first, and preview the truncation on a phone. A hard count produces titles that are either crammed or truncated at the wrong word.

Meta description ranking myth

Treating the meta description as a ranking factor wastes effort on the wrong field and, worse, leads to keyword-stuffed descriptions that repel the click. The description is not a ranking factor, and Google says so. Google snippet documentation (2024) is the source. Write it for the click, not for a ranking you were never going to get from it.

Sitemap priority tuning

Optimizing the priority and changefreq fields in a sitemap is obsolete. The sitemap protocol defines both as optional, and Google ignores them for ranking. Sitemaps.org protocol (2016) documents that they are optional. Spend the time on real on-page work, and keep lastmod accurate only if you already maintain it.

Other recycled advice

Beyond the big three, watch for the same stale patterns: keyword density targets, hiding content behind "view desktop", marking up content that is not visible, and treating structured data as a ranking factor. Each has a primary source in this guide that says otherwise. When a piece of advice cannot be traced to a dated Google document, treat it as a rumor until you find the source.