When you open an on-page SEO checklist, you usually get thirty items in no particular order, and half of them do not matter as much as the checklist makes them look. This piece is a different kind of checklist. It is a triage order for auditing a page that already exists, so you know what to fix first and what to leave alone. The order below is not a published Google ranking formula, it is a practical way to work through a page: first check whether the page can even be found and used, then whether it answers the search it is supposed to win, then whether it looks right in the results, and only after that, the small stuff.
Keep three different questions apart as you go: whether the page can be found at all (eligibility), whether it actually answers the query well (relevance and usefulness), and whether it presents itself well in the results (presentation and experience). A page can fail any one of these while passing the others, and mixing them up is why a lot of on-page seo checklist work ends in polishing a title tag on a page that was never indexed in the first place.
Check that the page can actually be indexed
Start here, always, because nothing else on this list matters if the page cannot appear. Google's minimum conditions for a page to be eligible are that Googlebot is not blocked from it, the page returns a successful HTTP 200 response, and it holds content Google can actually read. A page sitting behind a login, returning an error, carrying a noindex tag, or serving content the crawler cannot access will quietly defeat every other improvement you make.
Open Search Console's URL Inspection tool for the page and read it carefully. It shows you two different things: what Google indexed the last time it crawled the page, and a live test of what Google sees right now. Those can disagree, so if content or resources look missing, run the live test and look at the rendered view. And remember that being technically eligible is not the same as being indexed. A page can pass every eligibility check and still not be in the index yet, or not be served for the query you care about.
One more nuance worth knowing before you report a finding to a client: a robots.txt block stops crawling, but it is not a reliable way to keep a page out of the results. A noindex directive is the actual instruction, and it only works if the crawler is allowed to see the page in the first place. Get this backwards and you will misdiagnose why a page is or is not showing up.
Confirm Google picked the URL you meant
A page can be perfectly accessible and still not be the version Google treats as the main one. URL Inspection reports the Google-selected canonical for a page, and it is worth comparing that against the URL you actually intended to rank, along with whatever canonical preference you declared in the code. Google can and does choose a different canonical than the one you specified.
Do not assume that a mismatch here is automatically a mistake. Duplicate or alternate status on a URL is not automatically an error, and it can even mean the page you actually wanted indexed is the one that is live. What it does mean is that this needs a look before you attribute a client's lost visibility to a ranking drop, when the real story might be that Google shifted which URL represents the content. This check is about which existing page gets shown, not an invitation to redesign the site's internal linking or URL structure.
Test whether the page satisfies the actual search intent
This is where the real leverage sits, and it is also the step most audits skip because it takes more judgment than a scan of meta tags. Google's search essentials point toward helpful, reliable, people-first content that uses the terms searchers would actually use, in places like the title and main heading. The audit question you are asking here is simple to state and harder to answer honestly: does this page do the actual task the searcher came to do?
A comparison query needs a comparison, a query asking for current facts needs current facts and not last year's numbers, and an explanatory query needs an explanation a reader can actually follow. Read the queries this page is meant to win alongside the page itself, rather than checking off one keyword and calling the intent covered. Google's systems also understand related concepts and phrasing, so an exact-match repetition of your target phrase is not a substitute for actually covering the topic the way a searcher expects.
Here is a concrete version of the mismatch to watch for, since it shows up constantly in agency audits: a page that promises an on-page SEO factors checklist but spends most of its length explaining what SEO is in general will lose to a page that gets straight to the checklist. That reader came for the artifact, not the definition. Note that as an editorial pattern to watch for, not a measured Google experiment.
Check for real usefulness, not just length
Once intent is confirmed, look at whether the page actually delivers something worth reading. Google asks whether a page supplies original information, analysis or reporting, whether it covers its subject with real depth, and whether it adds something beyond rephrasing what other pages already say. For a page you are auditing rather than writing from scratch, the practical version of this check is: is the central answer actually present, and what important facts or limitations are missing that a competing result already covers?
Resist the urge to write "add 600 words" as a finding. Google has no minimum or maximum word count that it prefers, and padding a page to hit a number a tool suggested does not fix a content gap, it just makes the gap longer to read through. A more useful finding sounds like "the page promises to compare three plans but never actually explains what's different between them." That tells whoever fixes the page exactly what is missing. Keep this separate from policy risk, too: content made at scale primarily to manipulate rankings, forced keyword repetition, and hidden text are their own category of problem, distinct from a page that is simply thin.
Ask whether the reader has reason to trust the claims
For any page making a claim that matters, especially one touching health, money or safety, check whether the reader has a reason to believe it. Look at whether statements are sourced, whether the facts hold up, whether the page shows appropriate firsthand experience where that is relevant, and whether it would help the reader to know who wrote or reviewed the page. Google describes these as ways to evaluate helpful content, and it is worth saying plainly: E-E-A-T is not one measurable ranking factor you can tick off, it is a lens for judging whether a page deserves trust.
In practice, a strong finding here looks like "this page makes a specific numerical claim with no source behind it," which is a real, fixable gap. A weak finding looks like "add an author bio for SEO," which treats a trust signal as decoration rather than substance. Never fill a missing piece of evidence by inventing a study, a result, or an expert quote just to close the gap. That solves the audit checklist and creates a worse problem.
Compare the title against what the page actually delivers
Read the HTML title element, the visible headline on the page, and the actual content, side by side. A useful title is specific to that page, reasonably concise, and honest about what the reader will find. Flag a boilerplate title reused across many pages, a vague label that could describe anything, or a title that promises something the page does not deliver.
One thing worth knowing before you flag a title as broken: Google can and does generate its own title link for the search result, drawing on the title element, the visible heading, other headings on the page, and more. So the title you see in a search result might not be the one you wrote, and that difference is not automatically a penalty. It is worth investigating why Google chose a different version, since sometimes its version genuinely fits the query better. There is also no fixed character limit for a title element, Google just truncates the displayed link to fit the device, so treat character-count rules as a rough guide, not a hard requirement.
Make sure headings and nearby text make the answer findable
Scan the page the way an impatient reader would: can you find the actual answer to each subquestion by skimming headings and the text right under them? Google's own guide to its ranking systems describes systems that can identify relevant sections within a page, and its search essentials point toward using the terms real searchers use in prominent places. That supports clear, well-organized sections, not a rule that a page needs a specific number of headings or a particular FAQ format to rank.
If a heading promises a comparison, the text under it should be the comparison, not another paragraph of setup. That is the actual bug to look for, buried or generic answers, not a missing H3 somewhere. The same logic carries into AI search: Google has said its AI Overviews and AI Mode rely on the same foundational SEO practices, with no special schema or technical trick required, and the links an AI answer draws on still need to be indexed and eligible to appear in ordinary results with a snippet. Do not promise a client that one layout change will produce an AI citation, since what an AI answer draws on varies by query.
Check whether the facts on the page are actually current
Freshness matters for queries where freshness matters, not as a universal rule. Look at anything on the page that is time-sensitive: prices, product specifications, regulations, statistics, named tools or features that may have changed. If those are stale, that is a real finding worth fixing. If the page is a stable explanation of something that has not changed, it does not need an artificial update just to carry a newer date.
Google's own helpful-content questions call out exactly this pattern: changing a displayed date without meaningfully changing the content, or publishing and deleting material purely to look active. Frame any freshness fix around what actually changed in the world, not around making the page look recently touched.
Check mobile experience and page experience in proportion
Look at how the page renders on mobile, whether ads or interstitials get between the reader and the main content, and whether the page is secure. Core Web Vitals feed into Google's ranking systems, but Google has also said directly that the most relevant result can still surface even with a weaker page experience. That is worth remembering before you tell a client that a perfect speed score will move them up the results.
The three vitals worth tracking are Largest Contentful Paint for loading speed, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. Reasonable targets are around 2.5 seconds for LCP, 200 milliseconds for INP, and 0.1 for CLS, measured at the 75th percentile of real page loads. Treat those as experience benchmarks, not as a percentage of ranking lift. Search Console's Core Web Vitals report will show you which pages are affected, and it is worth remembering that a lab test and real-user field data answer different questions, so a good lab score is not proof of a good real-world experience. On an audit like this one, the job is to flag an experience that is actually broken or obstructive, not to run a full speed-optimization project on every page.
Check images only when they carry information
For a page where images matter, look at whether the important ones are clear, sit near the text that explains them, load in a crawlable image element, and carry alt text that describes what the image actually shows rather than a string of keywords. Google pulls information about an image from the text around it and from its metadata, and alt text in particular helps both accessibility and Google's understanding of how the image relates to the page. A short, descriptive filename beats a generic auto-generated one when you have the choice.
This one is conditional for a reason: not every page leans on imagery to do real work, and renaming a handful of decorative files will not make up for a page that is missing its actual answer. Save this check for pages where the images are doing something, a chart, a screenshot, a diagram, not for pages where they are decoration.
Check whether the search snippet actually represents the page
Look at what shows up under the title in search results and compare it against what the page actually says. Google usually builds that snippet from the page's own content, and only sometimes pulls from the meta description, when Google judges the description describes the page better. Because of that, treat this mainly as a presentation and click-decision check rather than a promised ranking lever, and prioritize accordingly. A generic description copied across many pages, or one that misrepresents what the reader will actually find, is worth fixing. There is no fixed length limit either, since Google truncates the display as needed, so aim for accuracy over hitting an exact character count.
Check structured data only where a real result fits
Ask whether this specific page qualifies for a structured-data feature Google currently supports, whether the markup describes what is actually visible on the page, and whether the required properties are all present. Run it through the Rich Results Test to check the mechanics, but keep in mind that valid markup does not guarantee Google will actually display the enhanced result. Do not add generic schema to every page hoping it moves the needle, since a mismatch between markup and visible content is a bigger risk than having no markup at all. Worth knowing if you are relying on it for visibility: FAQ rich results stopped appearing in Google Search as of May 2026, so a general blog post should not promise a client that FAQ schema will earn that particular search feature, even though a clearly written FAQ section still serves readers on the page itself.
Leave URL wording and minor formatting for last
A descriptive URL can help a person understand what a result is about before they click it, but changing an established URL purely to insert a keyword adds real work and risk of disruption for a gain that is not documented anywhere. The same goes for meta keywords, which Google Search does not use at all, and for chasing a specific heading-tag structure as if it were a ranking lever on its own. Put these in a box labeled do not start here. They are worth doing when you are already touching the page for a real reason, not worth an hour of anyone's time on their own.
How to prioritize across all of this
Work the list in three passes, not twelve separate to-dos of equal weight. First, clear the blockers: indexability and canonical selection, since nothing else counts until those are sound. Second, close the query-and-content gaps: intent match, substance, trust, and title accuracy, since these are where a page actually wins or loses against competing results. Third, pick up the presentation and experience opportunities: snippets, structured data, mobile experience, images, when they are genuinely broken rather than merely imperfect.
An audit is working when every flagged page carries an observed problem and a real reason it deserves attention, not when every field in a scoring tool has turned green. Record a plain yes, no, or unknown for each check, the URL and query it applies to, and one piece of actual evidence, and you have a repeatable artifact you can run against any client page without reinventing the process each time. If you are running this kind of audit across a full client roster and the manual side of it (drafting the fixes, keeping metadata and internal links consistent, reporting what changed) is eating the time you would rather spend on strategy, DeepSmith builds SEO and AEO checks like these into its writing pipeline itself, so keyword coverage, headings and metadata come out already worked rather than needing a second pass.
