How to do a web page SEO analysis, step by step (and turn it into a client fix list)
A web page SEO analysis checks one URL, not a whole site. You look at whether the page is set up to be found, understood and clicked for the search it is meant to win. It is the right tool when a client asks "why isn't this page ranking?" or before you rewrite a landing page.
The steps below need only a browser, the page source and Google's free tools.
Step 0: Decide what the page should rank for
You can't judge a page without a target. Write down:
- The main query, e.g.
emergency plumber leeds - The search intent: does the searcher want to buy, compare, learn or find a place?
- What already ranks: search the query and look at the top results. If they are all guides and your page is a sales page (or the other way round), that mismatch is your first finding. Tweaking tags won't fix it.
Step 1: Check the page can be indexed
Check this before anything else. Everything after it is wasted if Google can't index the page.
- View the source (
Ctrl+U/Cmd+Option+U) and search fornoindexin a<meta name="robots">tag. - Find the
<link rel="canonical">tag. It should point to this URL, or deliberately to another one. - In Google Search Console, run URL Inspection on the page to see whether it is indexed and which canonical Google chose.
- Make sure the page returns a 200 status and isn't blocked in
robots.txt.
Pitfall: staging-site noindex tags often survive a launch. Always check.
Step 2: Title tag
Find <title> in the source.
- Does it contain the main query, or a close variant, near the start?
- Is it unique on the site? Duplicate titles across templates are common.
- Would a person click it? Specific beats generic: "Emergency Plumber in Leeds – 24/7, Fixed Call-Out Fee" beats "Home | Smith Plumbing".
- Length: Google cuts titles by display width, not by a fixed character count. Around 50–60 characters is a common rule of thumb, not a Google rule.
Google may rewrite titles it finds unhelpful. Its title link guidance explains why.
Step 3: Meta description
Find <meta name="description">. It doesn't directly affect rankings, but it often becomes the snippet, so it affects clicks.
- Is there one at all, and is it unique to this page?
- Does it say what the page offers and why to click?
- Google may show other text from the page instead. Its snippet guidance covers this.
Step 4: Headings
List the headings in order. A quick way is the browser console:
`js
document.querySelectorAll('h1,h2,h3').forEach(h => console.log(h.tagName, h.textContent.trim()))
`
Check that:
- there is one clear
H1that matches the topic, not a logo or "Welcome" - the
H2s read like an outline of what the searcher needs - headings aren't being used just for styling
Step 5: Content
This is where most of the value is.
- Does it answer the query? Compare it with the top results. Which questions do they answer that this page skips?
- Is the main point near the top? Or is it buried under a hero image and slogans?
- Is it specific? Prices, areas served, steps, examples and proof beat generic claims.
- Thin or duplicate content: a page that mostly repeats another page on the site is competing with it.
- Freshness: check for outdated dates, prices or product names.
Step 6: Internal links
- Links into the page: search
site:example.com "topic"or use Search Console's Links report. Important pages should be linked from relevant pages, not only from the footer. - Links out of the page: does it point readers to the next logical step?
- Anchor text: "click here" tells Google nothing. Describe the target page instead.
- Broken links: hover over or click through a few. A crawler is faster on big pages.
Step 7: Images
- Every meaningful image needs
alttext that describes it. Decorative images can usealt="". - File names like
IMG_4482.jpgare a missed chance. Something likeboiler-repair-leeds.jpgis better. - Oversized images slow the page. Run it through PageSpeed Insights and note the image warnings.
Step 8: Structured data (schema)
Paste the URL into Google's Rich Results Test. It shows which structured data it finds (JSON-LD, Microdata or RDFa) and any errors.
- A local business page might use
LocalBusiness. An article might useArticle. A product page might useProduct. - Only mark up what is actually visible on the page.
- Fix errors first. Treat warnings as optional.
Step 9: Turn the findings into a client fix list
A list of 40 issues in random order won't get acted on. For each finding, record:
| Issue | Why it matters | Fix | Impact | Effort |
|---|---|---|---|---|
| Page has noindex | Can't appear in Google | Remove tag | High | Low |
| Title is "Home" | Weak relevance and clicks | Rewrite with query | High | Low |
| No section on pricing | Top results all cover it | Add pricing section | Medium | Medium |
Then sort by impact first, effort second. High-impact, low-effort fixes go at the top. Write each fix so the client, or their developer, can do it without you. "Change the title to: …" is better than "optimise title".
Common pitfalls
- Reporting tool scores instead of problems. Clients care about the fix, not the number.
- Ignoring intent and polishing tags on a page that's the wrong type for the query.
- Analysing the desktop view only. Google mainly uses the mobile version of a page.
- Making changes without first saving the current title, description and rankings, so you can't show what improved.
Doing this faster
Done by hand, this takes roughly 30–60 minutes per page (our estimate). That's fine for one page but slow across a client's ten key pages. We're building Auditfold, a browser extension that will run these page-level checks in one step and produce the ranked fix list described above. It's one option. The manual steps here work just as well if you prefer to do them yourself.