Page analysis takes a single URL and reviews it end to end: what it’s trying to rank for, whether the title and description support that, how the content is structured, what it links to, how the images are handled, and what a search engine actually receives when it requests the page.
Built in-house. It is my own tooling rather than a reseller’s dashboard, which is why it checks the things I act on rather than everything a generic tool can measure.
What it does
Page analysis answers one question properly: is this page doing everything it reasonably could for the search it’s aimed at. It reads the live page as a crawler would, checks the elements that decide how it appears in results, and reports what’s missing or working against it, ordered by what’s likely to matter rather than by what’s easiest to count.
It’s the tool I reach for first when a client says one specific page isn’t performing.
What it checks
| Area | What it looks at |
|---|---|
| Intent match | What the page is aimed at, and whether the content answers that search rather than a neighbouring one |
| Title and description | Length, whether they read well in a result, and whether they match the page |
| Headings | One clear H1, sensible hierarchy, and headings that match how people ask |
| Content depth | Whether the page answers the question fully, and what the ranking pages cover that it doesn’t |
| Answer passages | Whether sections open with something self-contained enough to be quoted |
| Internal links | What links in, what links out, and whether the page is reachable from the right places |
| Images | File size, format, dimensions, alt text and whether they’re lazy loaded |
| Schema | Whether structured data is present, valid, and matches what’s visible |
| Rendering | Whether the main content is in the HTML or only appears after JavaScript runs |
| Indexability | Canonical, robots directives and whether the page is eligible to appear |
Why rendering gets its own check
The most common surprise on a single-page review is the gap between what a person sees and what a crawler receives. On sites built with heavy JavaScript, the headings and body copy can be absent from the initial HTML, so a tool reading the page source finds almost nothing.
Reading the raw HTML rather than a converted version of the page is the only way to see this. It’s also the only way to see the head section reliably, since many tools strip it, taking the title, description, canonical and schema with it.
Example output
PAGE: /guides/choosing-a-threshold-seal/ TITLE: 71 characters. Truncates in results before the useful part. H1: Matches the title closely. Fine. DEPTH: Covers heights and lengths. Doesn’t cover floor preparation, which two of the three ranking pages lead with. ANSWER PASSAGE: The page opens with company history. The recommendation appears in section four. IMAGES: 11 images, 4 over 400KB, 6 with no alt text. SCHEMA: None. Product and FAQ markup would both apply here.
What I review
Every recommendation gets checked against the live page before it reaches a client. Tools report what they can measure, which isn’t the same as what’s worth doing, and a list of technically valid findings sorted by severity is usually the wrong order to work in.
I also check a low click-through rate against the live search result before calling it a title problem. Search engines rewrite titles, and the title in your source isn’t always the one being shown.
Limitations
- One page is one page. A page can be perfect and still fail because the rest of the site doesn’t support it.
- Competitive context is a judgement. Content depth is measured against what currently ranks, and that changes.
- No crawl budget view. Sitewide indexing questions need the technical SEO checks rather than a single-page review.
Services it powers
Page analysis supports SEO work generally, and feeds the content quality and E-E-A-T and image SEO services. See the rest of the tools on the tech stack page.
FAQ
What does a page analysis actually tell me?
It tells you whether one page is doing everything it reasonably could for the search it targets: whether the title and description work, whether the content answers the question fully, how the images and schema are handled, and what a search engine receives when it requests the page.
Why check how a page renders?
Because what a visitor sees and what a crawler receives can differ. On JavaScript-heavy sites the headings and body copy are sometimes missing from the initial HTML, so the page a search engine reads is far thinner than the one you see in a browser.
Is a single page review enough?
Sometimes, when one page underperforms while the rest of the site is healthy. When the problem repeats across a section, or the page can’t be found at all, the answer usually lies in site structure and indexing instead, which is a sitewide job.
See the whole toolkit
The tech stack page lists every tool, and the free assessment includes a review of your most important pages.