On-page SEO: every element explained, with an audit checklist

What on-page SEO covers, and what it does not

Google Search Essentials sums up on-page SEO in one of its key best practices: use the words people would use to look for your content, and place them in prominent locations on the page, such as the title and main heading, alt text and link text. Google's explanation of how it ranks results says the same from the other side: the most basic signal that content is relevant is that it contains the keywords of the query, for example in the headings or body text.

On-page work is one of three layers, and each fails in its own way:

The layers depend on each other. A page Google has not crawled and indexed cannot rank however good its title is, and no on-page change stands in for links from other sites. The crawling, rendering and indexing layer has its own guide, technical SEO. For the whole loop of auditing, fixing and measuring a site, see how to improve SEO.

Some popular on-page factors are not factors at all. Google's SEO Starter Guide lists them among the things it believes you should not focus on:

• The keywords meta tag. Google Search does not use it.
• Keywords in the domain name or URL path. Alone, they have hardly any effect beyond appearing in breadcrumbs.
• Content length. There is no word count target, minimum or maximum, for ranking.
• The number and order of headings. Semantic order helps screen readers, but it does not matter to Google Search.
• E-E-A-T as a ranking factor. Google's answer is that it is not one.
• A duplicate content "penalty". The same content under several URLs is inefficient, but it does not cause a manual action.

Search intent and the main content

What it is. Search intent is what the person searching wants to learn, do or find. The main content is the part of the page that serves it, as opposed to navigation, sidebars, ads and footers.

What Google says. Before ranking anything, Google works out the intent behind a query with language models and a synonym system, so a page that says "adjust laptop brightness" can match a search for "change laptop brightness". The Starter Guide says content people find compelling and useful will likely influence your presence in search results more than any of its other suggestions, and describes that content as easy to read, unique, up to date and helpful. Google's guidance on helpful content asks whether a reader leaves feeling they learned enough to reach their goal, and whether the main heading or page title gives a descriptive, helpful summary of the content.

How to get it right.

1. Search the query yourself and note what kind of page ranks: guides, product pages, tools, comparisons or videos. Make sure yours is the same kind before you tune anything else.
2. Answer the query in the opening lines, in the words people search with, then give the detail. Bing's webmaster guidelines ask for the same thing: essential information near the top, and each URL focused on a single topic.
3. Cover what the reader needs next. Semantic SEO explains how to map a topic's entities and questions; the queries that already show a page in Search Console are the best record of what is missing, and finding untapped SEO opportunities shows how to read them.
4. Make the main content easy to tell apart from everything around it. Google's guide to generative AI features names that as part of a good page experience.

Common mistake. Writing one page for every phrasing of a query. The generative AI guide says creating separate content for every variation of how people search, primarily to manipulate rankings, violates Google's scaled content abuse policy, and that its systems understand relevance without an exact match. Repeating a phrase until it sounds unnatural is keyword stuffing, which Google's spam policies prohibit.

The title element and title links

What it is. The <title> element inside the page's <head>. Browsers show it in the tab and in bookmarks; Google uses it, with other text on and around the page, to generate the title link, the clickable headline of a search result.

What Google says. Google generates title links automatically from several sources: the <title> element, the main visual title, heading elements such as <h1>, the og:title meta tag, other large and prominent text, anchor text on the page, the text of links pointing to the page, and WebSite structured data. It calls the title link often the primary piece of information people use to decide which result to click. There is no length limit on the element, but the title link is truncated as needed to fit the device width. After you change a title, Google has to recrawl and reprocess the page, which can take a few days to a few weeks.

How to get it right.

• Give every page its own title that describes that page. Avoid vague labels such as "Home" or "Profile".
• Keep it concise, and put the site name at the start or the end, separated by a hyphen, colon or pipe.
• Make the main visible heading say the same thing, ideally in the first visible <h1>, so the page has one clear main title.
• Write it in the same language and script as the page.

<head>
  <title>How to test a backup restore: a monthly drill | Example Co</title>
</head>

Common mistake. A title Google has to repair. The title link documentation lists what triggers a rewrite: half-empty titles such as | Example Co, obsolete titles that still carry last year's date, titles that no longer match the page, and the same boilerplate repeated across a group of pages. Its best practices add keyword lists such as "backup, backups, backup testing", which can make a result look spammy. When Google detects a problem, it may build the title link from headings, anchors or other text instead. If results show a title you did not write, fix the page, not the result.

The meta description and snippets

What it is. The <meta name="description"> tag in the <head>: a short summary of the page that readers never see on the page itself.

What Google says. The snippet under a title link is created primarily from the page content, chosen to preview the part that best relates to each search, so one page can show different snippets for different queries. Google uses the meta description when it describes the page more accurately than text taken from the page. There is no length limit; the snippet is truncated to fit the device. In a 2009 post on meta tags, Google said it sometimes uses the description for snippets but not in ranking. Bing treats it differently: its guidelines say missing, duplicate or overly short titles and meta descriptions may reduce indexing reliability and ranking.

How to get it right.

• Write a unique description for each important page. If time is short, Google suggests starting with the home page and the most visited pages.
• Summarize the page in a sentence or two, with the facts a searcher needs: for an article, the author or date; for a product, the price and key details.
• On large database-driven sites, generate descriptions from each page's own data. Google says programmatic descriptions are appropriate there, as long as they read naturally and differ from page to page.
• To limit what Google shows, use the nosnippet or max-snippet:[number] rules, or the data-nosnippet attribute on part of the page.

<meta
  name="description"
  content="A monthly drill that proves your backups restore: pick a sample, restore it to a clean machine, time it and record the result."
/>

Common mistake. One description on every page, or a string of keywords. Google says descriptions made of long lists of keywords are less likely to be shown as the snippet at all.

Headings that outline the page

What it is. The <h1> to <h6> elements that name the page and its sections.

What Google says. Headings are one of the places where a query's keywords signal relevance. The Starter Guide recommends breaking long content into sections with headings that help people navigate; as noted above, it also says heading order and count do not matter to Google Search. The title link documentation adds one warning: when several headings carry the same visual weight, Google may use the first one as the title link.

How to get it right. Heading order matters to people, because browsers and assistive technologies such as screen readers use headings for in-page navigation. The W3C's headings tutorial says to nest headings by rank and to avoid skipping ranks where possible, because a skipped level is confusing. A practical pattern:

• One <h1> that states what the page is, in words that match the title element.
• An <h2> for each question or task a reader scans for.
• <h3> for the steps or parts inside a section.

<h1>How to test a backup restore</h1>
  <h2>Why a finished backup is not proof of recovery</h2>
  <h2>Run the monthly restore drill</h2>
    <h3>Pick a sample</h3>
    <h3>Restore it to a clean machine</h3>
  <h2>Record the result</h2>

Common mistake. Choosing a heading level for its font size. Style headings with CSS and choose the level from the outline. Headings such as "Introduction" or "More information" are the other waste: they tell a scanning reader nothing about the section.

URL slugs

What it is. The slug is the readable part of the URL path that names the page, such as backup-restore-testing in https://example.com/guides/backup-restore-testing/.

What Google says. Google's URL structure guidance recommends readable words rather than long ID numbers, words in your audience's language, hyphens rather than underscores between words, and as few parameters as possible. URLs are case-sensitive: Google treats /APPLE and /apple as two URLs. The Starter Guide explains why readable words still help even though keywords in the path barely affect ranking: parts of the URL can appear in results as breadcrumbs, and people use them to judge whether a result will be useful.

Good:   https://example.com/guides/backup-restore-testing/
Avoid:  https://example.com/index.php?id=4821&cat=7
Avoid:  https://example.com/Guides/Backup_Restore_Testing/

How to get it right. Choose the slug when the page is created: a few lowercase words that name the topic, joined by hyphens, with no session IDs or tracking parameters. Then keep it. Bing's guidelines ask for stable URLs, and a proper redirect when one has to change.

Common mistake. Renaming the URL of a page that already ranks to fit a keyword in. The gain is close to nothing by Google's account, and the page's visibility then depends on the redirect being right. If a change is unavoidable, use a 301 redirect: Bing's guidelines specify it for permanent moves, and Google's canonicalization guide treats a redirect as a strong signal that the target should become the canonical URL.

Internal links and anchor text

What it is. Links from one page of your site to another. The anchor text is the visible, clickable text of the link.

What Google says. Google uses links as a signal of relevance and to find new pages; the Starter Guide says the vast majority of new pages Google finds every day are found through links. Google can generally only crawl a link that is an <a> element with an href attribute. Good anchor text is descriptive, reasonably concise and relevant to both pages, and the words around the link add context. For an image used as a link, Google uses the image's alt text as the anchor text. Every page you care about should have a link from at least one other page on your site, and there is no ideal number of links per page.

How to get it right.

• Link from pages on the same subject, in the sentence that explains why the reader should follow the link.
• Use anchor text that makes sense on its own: "backup schedule", not "click here". Lighthouse's link text audit flags generic phrases such as "click here", "here", "more" and "learn more".
• Link to the canonical URL of the target, not to a redirecting or parameter version.
• Space links out. Google advises against chaining several links next to each other, because each loses the words around it.

A crawlable link with descriptive anchor text:

<p>
  Before the drill, check that your
  <a href="/guides/backup-schedule/">backup schedule</a>
  covers every server you plan to restore.
</p>

A link Google may not follow, with anchor text that says nothing:

<span onclick="go('/guides/backup-schedule/')">Click here</span>

Common mistake. Orphan pages and links crawlers cannot follow: navigation built from onclick handlers on <span> or <div> elements, or new pages that appear only in a sitemap. Bing's guidelines ask for the same standard <a href> links, with relevant anchor text or image alt attributes.

Images: alt text, file names and formats

What it is. The <img> element and everything that describes it: the alt attribute, the file name, the text around it and the format of the file.

What Google says. Google's image SEO guide sets out how images are found and understood:

• Google finds images in the src attribute of <img> elements, including inside <picture>, and does not index CSS background images.
• Alt text is the most important attribute for image metadata. Google uses it with computer vision and the page's content to understand the image, and it doubles as anchor text when the image is a link.
• The file name gives very light clues, so restore-drill-timeline.webp says more than IMG00023.JPG.
• Supported formats are BMP, GIF, JPEG, PNG, WebP, SVG and AVIF. With srcset or <picture>, always give a fallback URL in src.
• Images are often the largest contributor to page size, so compress them and serve responsive sizes.

How to get it right. Place each image next to the text it illustrates, and write alt text that says what the image shows in the context of the page. An image that adds no information, such as a divider, gets an empty alt="". The W3C's decorative images tutorial explains why: screen readers then skip it, while a missing alt attribute can make some of them read out the file name.

<img
  src="/images/restore-drill-timeline.webp"
  alt="Timeline of a restore drill: sample chosen, restored to a test server, files compared, time recorded"
  width="1200"
  height="675"
/>
<img src="/images/section-divider.svg" alt="" />

Common mistake. Alt text written as a keyword list. Google's image guide shows a stuffed example and says the practice harms users and may cause a site to be seen as spam. The other is putting information only in images: Bing's guidelines say images should support the text on the page, not be the only place the information appears.

Structured data that matches the visible page

What it is. Machine-readable statements about the page in the schema.org vocabulary. Google supports JSON-LD, Microdata and RDFa, and recommends JSON-LD as the easiest to implement and maintain at scale.

What Google says. Structured data helps Google understand a page and can make it eligible for rich results, such as review stars and carousels. The general structured data guidelines set the rules: mark up only content that is visible to readers, keep the markup a true representation of the page, include every required property of the feature, and keep time-sensitive information current. Valid markup guarantees nothing; Google decides whether to show a rich result. A structured data manual action removes a page's eligibility for rich results, and Google says it does not affect how the page ranks in web search.

Features also end. Google's documentation update log records that FAQ rich results were limited to well-known, authoritative government and health sites in September 2023, and stopped appearing in Google Search on May 7, 2026; the documentation was removed in June 2026. How-to rich results were removed in September 2023, and several other types, such as estimated salary and vehicle listing, were dropped by September 2025. For AI Overviews and AI Mode, the generative AI guide says structured data is not required and there is no special schema.org markup to add.

Check Google's list of supported features before you build markup for a rich result.

How to get it right. Generate the markup from the same data that renders the page, so the two cannot drift apart. Test it with Google's Rich Results Test, which the guidelines say catches most technical errors for Google's features, and with the Schema Markup Validator, which checks schema.org markup of any type for syntax mistakes. An example for an article follows in the author and date section.

Common mistake. Markup for content the reader cannot see: FAQ answers that exist only in JSON-LD, ratings that appear nowhere on the page, or reviews not written by real users. Google lists hidden content as a reason markup is not shown, and says reviews or ratings not by actual users may lead to a manual action.

Canonical tags

What it is. A <link rel="canonical"> element in the <head> that names the preferred URL when the same content is reachable at several addresses: with and without www, with tracking parameters, or through sorting and filter options.

What Google says. Google's canonicalization guide ranks the ways to state a preference: redirects and rel="canonical" are strong signals, sitemap inclusion a weak one, and they add up when combined. None is required; without one, Google picks the version it considers best. Declaring one tells Google which URL you want people to see in results, lets it consolidate signals such as links from other sites onto that URL, and saves crawling on duplicates. Google recommends a self-referential canonical on the preferred page itself, absolute rather than relative URLs, and internal links that point to the canonical version. The element only counts inside the <head>.

How to get it right. Put the same line on the preferred page and on every variant of it, such as ?utm_source=newsletter:

<link
  rel="canonical"
  href="https://example.com/guides/backup-restore-testing/"
/>

Then check what Google chose. The URL Inspection tool shows both the user-declared canonical and the Google-selected canonical; the second appears only in the indexed result, because a live test cannot predict it. Bing's guidelines add a caution: canonical tags signal a preference, but they do not replace fixing the duplication at its source.

Common mistake. Canonicals that contradict other signals: a sitemap that lists one URL while the canonical names another, noindex or robots.txt used to choose a canonical (Google advises against both), or page two of a multi-part article pointing to page one, which Google's Article documentation says to avoid. Lighthouse's canonical audit catches the mechanical errors: more than one canonical, an invalid URL, a canonical on another domain, or one that points to the site root.

Author and date information

What it is. A visible byline that says who wrote the page and links to more about them, and visible publication and update dates, repeated in structured data.

What Google says. E-E-A-T stands for experience, expertise, authoritativeness and trustworthiness. The Starter Guide says it is not a ranking factor, and the helpful content guidance explains the nuance: Google's systems use a mix of factors that identify content with good E-E-A-T, give it even more weight on topics that could affect people's health, finances or safety, and treat trust as the most important part. Google strongly encourages accurate authorship information, such as bylines where readers would expect them, that lead to more about the author.

For dates, Google's byline date guidance says its systems look at several factors to estimate when a page was published or significantly updated. It recommends a prominent visible date labelled "Published" or "Last updated", plus the datePublished and dateModified properties in Article, BlogPosting or other CreativeWork markup. Google asks that the visible and structured dates match, and that neither be in the future.

How to get it right. A visible byline, and markup that says the same thing:

<p>
  By <a href="/authors/jane-doe/">Jane Doe</a>. Published March 4, 2025. Last
  updated September 15, 2026.
</p>

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": "How to test a backup restore",
    "datePublished": "2025-03-04T09:00:00-05:00",
    "dateModified": "2026-09-15T14:30:00-04:00",
    "author": [
      {
        "@type": "Person",
        "name": "Jane Doe",
        "url": "https://example.com/authors/jane-doe/"
      }
    ]
  }
</script>

The time zone offsets differ because Google asks for the correct zone, daylight saving time included. The Article guide sets the author rules: list each author in their own author entry, give the @type and a url or sameAs that identifies the person, and put only the name in author.name, without job titles, honorifics or words like "posted by".

Common mistake. One author field holding several names, or a dateModified that changes on every deploy while the visible date, and the content, stay the same.

Content freshness without fake date changes

What it is. Keeping a page accurate as its subject changes, and saying honestly when it last changed.

What Google says. Freshness matters for some queries, not all. Google's ranking systems guide describes "query deserves freshness" systems that show newer content where people expect it, such as reviews of a film just released, and Google's ranking explainer notes that freshness weighs more for current news topics than for dictionary definitions. The helpful content guidance lists two warning signs: changing the date of a page when its content has not substantially changed, and adding or removing large amounts of content to make a site seem fresh, which it says will not work. The Starter Guide's advice is plain: check older content, update it as needed, or delete it once it is no longer relevant.

How to get it right.

1. Update when the facts change: a new version, a changed price, a retired feature, a better answer.
2. Change the visible "Last updated" date and dateModified together, in the same release as the edit.
3. Update the sitemap's <lastmod>. Google uses it only when it is consistently and verifiably accurate, generally treats changes to the main content, structured data or links as significant, but not a new copyright year, and ignores <priority> and <changefreq>.
4. For other search engines, send the changed URL through IndexNow, a ping protocol supported by Microsoft Bing, Naver, Seznam.cz, Yandex and Yep. Bing's guidelines ask for IndexNow notifications and accurate lastmod values.

<url>
  <loc>https://example.com/guides/backup-restore-testing/</loc>
  <lastmod>2026-09-15</lastmod>
</url>

Common mistake. A template that stamps "Last updated" with today's date on every page, or a sitemap generator that gives every URL the build time. Both tell search engines something false, and Google relies on lastmod only while it proves accurate.

On-page SEO checklist: an audit table

One pass through a page, element by element. The table is the what; choosing which pages to audit first and measuring what changed is covered in how to improve rankings with on-page SEO.

The Performance report in Search Console shows which queries bring your site traffic, grouped by query or by page, which is the evidence for the first row. For the rest, a crawler finds the pattern across the site and URL Inspection confirms what Google itself sees on one page.

If you want this done across a site's templates rather than page by page, our SEO service includes on-page fixes to titles, descriptions, headings and internal links, and structured data validated on every release, with each change confirmed in the rendered HTML and in Search Console. It does not promise rankings, because no one can honestly. More guides are under SEO.