On-page SEO: how to optimize a page step by step

An Ahrefs estimate showed 188 organic visits a month for CometWeb. Of those, 174 were attributed to two queries about free tools and to traffic from India. These are estimates from a third-party service, not observed users in analytics, but they were a useful clue about the search intent associated with our pages.

For on-page SEO, I start by checking whether a page answers the question behind the search. Titles, headings, links, images and structured data come next. The ten steps in this guide use a fictional backpack shop to show how the decisions fit together.

What on-page SEO is and how it differs from technical SEO

On-page SEO is optimizing the content and elements of a specific page so it meets the reader's need and is easy for a search engine to understand. It covers the content, the page title, headings, internal links and image descriptions.

The areas overlap, and Google doesn't process a page in three separate stages, but this is how I split the work:

Polishing the search snippet of a page that was accidentally excluded from indexing is wasted time. And a correct HTTP status won't make a thin product page answer a buyer's questions. Even a well-prepared page doesn't guarantee first place in Google, and a ticked-off checklist won't explain why a competitor shows up above you.

Step 1: Check that the page can appear in Google

For each important URL on your site, start with indexability and check three things:

1. Googlebot can reach the page,
2. the server responds properly,
3. there's content that can be indexed.

These are Google's basic technical requirements, and meeting them opens the door to the index, but Google makes the indexing decision itself.

In Search Console, open URL Inspection. The live test tells you about the page today, and the indexed version tells you whether Google has picked up your latest change (Google's guide to getting started with Search Console).

Next, check your meta tags and X-Robots-Tag HTTP header for a stray noindex on pages meant for search. robots.txt controls crawling, and noindex keeps a page out of the index, but Google can only read it if it can fetch the resource. Leave noindex on pages you excluded on purpose, such as the cart (Google's documentation on blocking indexing). Anyone who knows the URL can still open a noindexed page, so you lock private content behind access control, such as authentication (Google's guide to controlling what you share).

If the content only appears after JavaScript runs, check your rendered page as well. Google can process JavaScript, but application errors and unavailable resources still matter (JavaScript SEO basics). For the wider set of checks, see the technical SEO audit guide.

Step 2: Match the page to search intent

Search intent is the task behind a query, whether someone wants to understand a concept, compare options, find a particular site or buy a product. Similar words can hide quite different tasks.

Take a fictional backpack shop, and treat the table below as a proposed content plan, with no ranking or search-volume study behind it.

Before you build a page, look at the current results for a few queries in the target language and country. Note what dominates: guides, categories, products or tools. That's a clue for judging intent, and copying your competitors' structure is optional. For an existing page, check its queries in Search Console too.

Give each page one main purpose. Google can connect a text with different ways of phrasing a query (SEO Starter Guide). So tying a page to one literal keyword, or writing a separate article for every variant of a phrase, is wasted effort.

If two URLs do almost the same job, compare their content and data before you merge them. A guide and a product category can healthily share a query, so check what each page is for before you call it harmful "cannibalization".

Step 3: Add the information people need to decide

Content optimization starts with the answers your page is missing, and those depend on the page type. On a product page, that may be dimensions, compatibility, limitations of use or return conditions. In a guide, it's the order of steps, an example, the data source and a way to check the result. Google's guidance on helpful, reliable, people-first content recommends content that adds more than a summary of what's already been published.

Show how you took your own measurements, and say where manufacturer data came from. Put the answer or the scope of the offer at the top of your page, then explain the criteria and exceptions with an example.

How many times to use a keyword

Use the terms your reader needs to understand the topic, because keyword density percentages and the identical phrase in every H2 are bad yardsticks. Repeating words excessively to manipulate rankings is what Google's spam policies call keyword stuffing. Let the question set the length, and cut every paragraph that doesn't help your reader understand the topic, make a decision or check an important claim.

How to show that the page is trustworthy

Name the author where it makes sense, cite sources for important claims and show the date of the real update. Label a vendor's data as the vendor's data. E-E-A-T, meaning experience, expertise, authoritativeness and trust, is a framework from the same Google guidance. It's neither a single factor nor a public ranking score that a plugin can "raise".

Step 4: Keep the title, H1 and meta description distinct

All three describe the same content and can be worded differently. Google generates the title shown in results automatically from several sources, <title> and headings among them (Google's documentation on title links).

Here's how that could look in the fictional backpack guide:

<title>How to choose a laptop backpack: size and device protection</title>
<meta name="description" content="Learn how to measure your laptop, compare compartment dimensions and judge how well a backpack protects your device. Practical buying criteria.">

The matching H1: "How to choose a laptop backpack and check that your device will fit".

For the title, go for a recognizable topic and a specific scope. Remove strings of near-identical phrases and any promise beyond what your page delivers.

Treat a title length of around 50–60 characters as a working editorial check. It's neither a Google limit nor a condition for ranking well, because Google truncates the displayed title to fit the device width.

Write the meta description as an honest summary of the page. Google may show a passage from your content instead if it fits the query better, and the documentation on snippets sets no fixed 155-character limit. Promise a price, discount or delivery terms only when the page backs them up.

Before you fix meta tags, check main and production

Here's my confession. Recently I had an AI agent fix the title and og: tags (Slack or LinkedIn build link previews from them) on a public report in CometWeb Insight, our website audit app.

The agent worked on a branch 287 commits behind main, and on main the problem had already been solved six days earlier. The new version duplicated that solution and broke it, so we reverted it.

The copy you or your agent work on can be older than the main version of your code or CMS. In my case, production was waiting for a deploy, so the source of the published page alone wouldn't have shown me anything. The SEO module in Insight shows a preview of the search result based on the current title and meta description, but Google still picks the final snippet.

Step 5: Structure headings like a list of the reader's questions

For a guide, use one clear H1, with H2s naming the main topics and H3s naming their parts. I do it for your reader, without any fear of a Google penalty for a second H1, and the SEO Starter Guide leaves the number of headings up to you.

H1: How to choose a laptop backpack
  H2: Measure the device and the backpack compartment
    H3: Where to find the dimensions of a specific model
  H2: Check how well the device is protected in transit
  H2: Compare comfort and interior organization
  H2: Pre-purchase checklist

Mark headings up with real <h2> and <h3> elements. People who use screen readers move around a page by its headings and understand its layout from their hierarchy (W3C WAI's tutorial on headings). So you pick an H3 for its place in the hierarchy and set the font size in CSS.

Step 6: Get the URL, canonical and language versions right

A new URL should be descriptive and stable, for example /guides/how-to-choose-a-laptop-backpack. Leave a working URL alone, even when adding a keyword is tempting. A new address means redirects, updated links and possible swings in visibility (Google's guide to debugging drops in search traffic).

rel="canonical" points to the preferred URL among duplicates or very similar pages. According to Google's documentation on canonical URLs, it's a signal, and Google may choose differently.

Pointing every similar article at the homepage with a canonical is misuse, and a badly chosen intent stays badly chosen. Duplicates need tidying up, but they don't automatically mean a penalty.

On a multilingual site, don't make one language version the canonical of its translation just because both describe the same product. When you use hreflang, the tag that marks language versions, Google recommends a canonical page in the same language.

I show how to line up canonicals with your sitemap in the canonical and sitemap setup guide.

Step 7: Add links that help the reader take the next step

You place an internal link where the reader needs more information, for example from the backpack guide to the right category. Anchor text, the clickable text of a link, says where it goes, for example "compare compartment sizes across backpacks". An important page should have at least one link from another page on your site.

Google's link best practices set no universal requirement of two to five links per article.

Link with an ordinary <a> element and an href attribute, because those are the links Google follows reliably. A link built only from a JavaScript click handler can get skipped.

<a href="/laptop-backpacks">Laptop backpacks with listed compartment dimensions</a>

Add links to external sources next to claims that need checking. Mark paid links with, for example, rel="sponsored", and user-added links with rel="ugc", and Google describes there when nofollow fits too.

Step 8: Describe images and keep them from slowing the page down

Alt text describes what an image means in its place on the page, for example "Black backpack with the laptop compartment open". You're writing a sentence for a person, so skip hyphenated file names and lists of SEO phrases. Google uses alt text together with the page context to understand images better (Google's image SEO best practices).

A purely decorative image should have an empty alt="", because a missing attribute and an empty attribute are two different things (W3C WAI's tutorial on decorative images). When an image is the only content of a link or button, its alt text describes its function (W3C WAI's tutorial on functional images).

Match the resolution to where your image is displayed. WebP or AVIF can make a file smaller, but the saving depends on the image and the settings, so compare the file size before and after.

Turn on lazy loading (deferred image loading) image by image. The LCP element, the largest content element visible while the page loads, should load early, because delaying it can make LCP worse (web.dev's guide to optimizing LCP).

Add video when it explains something better than text or a photo. Add captions, and put the essential instructions in text too.

Step 9: Check mobile and Core Web Vitals

Google uses the mobile version of a site's content for indexing and ranking (documentation on mobile-first indexing). The same important information should be on a phone, so a product description cut in half for a shorter screen is a bad trade.

According to web.dev, the thresholds apply to the 75th percentile of real-user measurements, with mobile and desktop assessed separately. Missing data from real visits means the result is unknown, and a lab test answers a different question. The thresholds for LCP, INP and CLS are in a table in my guide to speeding up a website.

Core Web Vitals are used by Google's ranking systems, but a high position depends on many more signals (Google on page experience). I wouldn't chase a 100/100 score at the expense of the content or usability.

The CometWeb performance auditor checks a public URL's performance, which is one part of on-page SEO. For the order of typical fixes, see the guide on how to speed up a website.

Step 10: Match structured data to the real content

Structured data describes your page's content in a standardized way. Google offers rich results for only some Schema.org types and lists them in its search gallery of structured data. For a blog post, you can use BlogPosting or another Article type, with the headline, author and dates matching the publication (Google's documentation on Article markup). Change dateModified when there's a real update. Setting it to today's date every time the page is opened is a mistake.

Don't mark up your guide as a product with an invented price and ratings, because the data must describe the real content (structured data policies). The Rich Results Test finds syntax errors, but whether a rich result shows depends on Google.

As checked on 24 September 2026, Google no longer shows FAQ rich results; they stopped appearing on 7 May 2026. You'll find the change in Google's documentation updates. A questions-and-answers section still helps the reader, so add one for people. Don't expect an FAQ rich result from it.

On-page SEO and AI answers in Google Search

For AI Overviews and AI Mode, the same SEO fundamentals and original, useful content matter. Google's guide to optimizing for generative AI features doesn't require a special "AI" schema, an llms.txt file or mechanically splitting text into chunks of a set length. It does cover the settings for a site's participation and the Generative AI performance report in Search Console.

State the conditions and sources alongside the answer. Add a date if the information is likely to change. Show an example, your own measurement or your method. Repeating generic advice without examples or evidence gives readers little reason to rely on the page.

Check your bot access and participation in each AI system separately. These recommendations are Google's, so treat other search engines and assistants as separate cases.

On-page SEO example: from a generic page to a useful guide

This fictional editorial example has not been implemented for a client or tested for search visibility. It assumes the guide includes instructions for measuring results.

Before you publish, read your page as someone buying this kind of product for the first time, and check three things:

• whether they can take the measurement,
• whether they know where to find the data,
• whether the title promises only what the content goes on to explain.

Only then check your code and how the page looks on a phone, once the content passes this test.

On-page SEO checklist: what to check before publishing

The on-page SEO checklist is a tool for signing off work on a single page, independent of any Google score. For each item, record evidence or a note: checked, needs work, not applicable or no data.

For a shop category, add product availability and filter usefulness; for a product page, current specifications and purchase terms. For a guide, check that your reader can carry out the steps.

How to check whether your on-page SEO changes helped

I'd run the before-and-after comparison in five steps:

1. Confirm the change is live. Open your published URL and walk through it like a reader, because what you saved in the editor and what's published can differ.
2. Record a baseline. In the Search Console Performance report, filter by the URL and note clicks, impressions, CTR (the share of impressions that turn into clicks) and average position for your important queries. CTR measures clicks, so whether a new description moved your ranking is a separate question.
3. Compare 28 days with 28 days. Take the 28 full days before the change and the same stretch after Google has processed it, with the same filters (country, device, search type), and with few impressions, go longer. It's a proposed method, with no deadline by which an effect has to appear.
4. Check the background, meaning seasonality, changes in demand and search engine updates. Google's guide to debugging drops in search traffic notes that effects appear at different times and that some changes produce no noticeable result.
5. Measure your page's goal. In analytics, I'd track a click through to a product, use of a tool or a form submission, because plenty of pages sell only indirectly. Time on page is ambiguous: more of it can mean interest or trouble finding the answer.

If you change the content, title, links and template at once, the result is the effect of the whole package. A simple before-and-after comparison can't isolate any single element, so don't call it an A/B test or credit the entire increase to one heading.

To keep the scope, date and retest conditions of each comparison on record, see the CometWeb website quality benchmark. For short, sourced answers about audits and indexing, there's the CometWeb answers hub.

Frequently asked questions about on-page SEO

Three takeaways

1. The CMS fields are the easy part, because you can fix the title, H1, meta description and alt text with the checklist above.
2. Intent is the hard part, because traffic arrives for the job a page does, as my two keywords from India show.
3. Start with one page, write down what's missing and fix it in the order shown below. Keep your pre-change check results to compare with the published version.

Some of those checks the CometWeb Insight SEO module does for you:

• a quick URL test checks one public address: HTTP, robots, canonical, meta, schema, headings, content, links;
• a project audit adds a multi-page crawl, sitemap, linking, duplicates, hreflang and run history for before-and-after comparison.

Create a free Insight account and check your page, although you'll still judge intent yourself.

Sources and review date

The checklist, the shop scenario and the comparison plan are my editorial proposals, with no effectiveness study behind them and no promise of more traffic.

1. Google Search Central: SEO Starter Guide.
2. Google Search Central: technical requirements.
3. Google Search Central: blocking indexing with noindex.
4. Google Search Central: specifying canonical URLs.
5. Google Search Central: title links in search results.
6. Google Search Central: snippets and meta descriptions.
7. W3C WAI: decorative images.
8. web.dev: Web Vitals.
9. Google Search Central: structured data policies.
10. Google Search Central: documentation updates, including the FAQ retirement.
11. Google Search Central: debugging drops in search traffic.
12. Google Search Central: spam policies.