The Website Audit Checklist That Finds Real Problems

Most site audits produce four hundred warnings and zero decisions. A website audit tool earns its place only when it separates the handful of issues that actually cost you traffic, things like uncrawlable templates, conflicting canonicals, structured data that fails validation, and a slow largest contentful paint on your highest-traffic page type, from the cosmetic noise you could safely ignore for another year.

This checklist is organized the way a crawler experiences your site, from fetch to render to index to citation. Six layers: crawl access, meta and titles, canonicals, schema, Core Web Vitals, and the newer AI-readable layer including llms.txt. Each section tells you what to check, what a real problem looks like as opposed to a warning, and how to verify the fix rather than assume it.

What Does a Website Audit Tool Actually Check?

The category name hides enormous variation. Some products are crawlers that download your HTML and pattern-match against a rule list. Some are performance testers that hit one URL and return a score. Some pull data you already own from Google Search Console and rearrange it. A complete picture needs all three, because each one is blind to what the others see.

A crawler tells you what exists and how pages connect. It cannot tell you whether anyone visits those pages, and it cannot tell you how they perform for real users on real devices. A lab performance test tells you how a page behaves under one simulated condition, throttled CPU, a specific network profile, a specific viewport. Real user data from the Chrome User Experience Report tells you the opposite: what actually happened to actual visitors over a rolling window, with no ability to explain why. Search Console tells you which queries produced impressions and clicks, which is the only layer that connects any of this to outcomes.

The mistake almost everyone makes is treating one of those layers as the whole audit. A page can pass every crawler rule and still be invisible because it is a duplicate of a stronger URL. A page can score 100 in the lab and fail Core Web Vitals in the field because the lab test never loaded the third-party tag manager your marketing team added last quarter. If you are still shortlisting products, what to look for in an SEO audit tool covers the evaluation criteria in more depth than a checklist article can.

Here is the coverage map, so you know what any given tool can and cannot tell you.

Skopx runs the first five of those in Site Health and the sixth in AI Visibility, which matters mostly because the fix list from one layer often explains a symptom in another. You can see how the pieces fit on the platform overview.

Crawl: Can Every Page Actually Be Reached?

Start here, because everything downstream is meaningless if the bot never arrives. Crawl problems are the ones that silently delete entire sections from the index, and they are usually invisible in a browser because your session is authenticated, your cache is warm, and you are not a bot.

Check the response status of every URL in your sitemap. A sitemap listing URLs that return 404, 301, or 500 is a signal that your sitemap generation is disconnected from your actual routing. Redirect chains are the next thing to look for: a URL that goes to a second URL that goes to a third wastes crawl budget and dilutes the signal at every hop. One hop is normal. Three is a bug someone introduced and nobody noticed.

Then read robots.txt as if you were seeing it for the first time. The classic failure is a staging rule that shipped to production, a single Disallow: / that removes the entire site. The subtler failure is disallowing a directory that contains resources the page needs to render, typically CSS or JS bundles. If the bot cannot fetch the stylesheet, it cannot see your layout, and layout affects how it judges the main content.

Orphan pages deserve their own pass. These are URLs that exist and may even rank, but have no internal link pointing at them. A crawler starting at your homepage will never reach them. Compare your sitemap set against your crawl-discovered set: anything in the sitemap but not in the crawl graph is an orphan, and the fix is a link from a relevant page, not another sitemap entry.

Finally, check rendering. If your pages are client-rendered and the main content only appears after JavaScript executes, fetch the raw HTML and search it for a distinctive sentence from your body copy. If that sentence is not in the source, you are betting your indexing on the renderer queue. That bet sometimes pays off and sometimes does not, and you will not know which until traffic moves.

Meta and Titles: The Layer That Breaks Quietly

Title and meta description problems almost never throw errors. They just quietly underperform, which is why they survive for years.

Duplicate titles are the most common finding on any site with a templating system. Category pages, paginated archives, and filtered views tend to inherit one title pattern and repeat it across hundreds of URLs. Google will often rewrite these, which means your carefully chosen keyword gets replaced by whatever the algorithm considers more accurate. The fix is to make the template interpolate something distinguishing: the category name, the page number, the filter value.

Length is worth checking but not worth obsessing over. Titles get truncated in the results page based on pixel width, not character count, so a title full of wide characters truncates sooner than one with narrow ones. Around sixty characters is a working rule of thumb. Meta descriptions have no direct ranking effect at all, but they influence click-through, and a missing description means the engine writes one by grabbing text from the page, sometimes your cookie banner.

Check heading structure while you are in the HTML. One H1 per page, headings that descend without skipping levels, and headings that actually describe the section below them. This matters more now than it did five years ago, because passage-level retrieval and AI answer generation both use headings to decide which chunk of a page answers a question. A page with six H2s that read like real questions is easier to quote than a page with six H2s that read like "Overview" and "More Info."

Open Graph and Twitter card tags belong in this pass too. They do not affect ranking, but a missing og:image turns every share of that page into a bare text link, and social traffic is the cheapest kind of discovery you have.

Canonicals: One URL Per Piece of Content

Canonical tags are where technically correct sites lose rankings, because the failure mode is not an error, it is disagreement.

The self-referencing canonical is the baseline: every indexable page should declare itself canonical. What breaks is the variations. Query parameters from campaign tracking create infinite versions of the same page. Trailing slash and non-trailing-slash versions both resolve. HTTP and HTTPS both respond. Uppercase and lowercase paths both serve content. Each of those splits your signal unless the canonical tag consolidates them, and each of them is easy to miss because a browser hides the difference.

Three specific conflicts are worth checking by hand:

A canonical pointing at a URL that redirects. You tell the engine the real version lives at URL B, and URL B sends a 301 to URL C. The instruction is now ambiguous, and engines resolve ambiguity by ignoring you.

A canonical combined with a noindex on the same page. These instructions contradict each other. One says consolidate signals here, the other says do not index this at all.

Paginated series where every page canonicalizes to page one. Pages two through twenty contain content that exists nowhere else, and you have just told the engine to ignore all of it.

Verify canonicals in the rendered HTML, not the template source. Tag managers and personalization scripts have been known to inject a second canonical tag at runtime, and two canonical tags on one page means neither is trusted.

Schema: Structured Data That Survives Validation

Structured data is the part of the audit where "present" and "valid" are very different states. A page can carry a JSON-LD block that a parser rejects, and the practical result is identical to having no schema at all.

Audit for three things in order. First, does the JSON parse. A trailing comma or an unescaped quote from a product description with an inch mark will break the whole block. Second, does the type match the page. An Article schema on a pricing page is not a small mismatch, it is a false statement about what the page is. Third, does the schema agree with the visible content. If your Product schema declares a price of 49 and the page shows 59, you have created a conflict, and the resolution is that the engine stops trusting your markup.

The types that carry real weight for most sites are Organization on the homepage, Article or BlogPosting on content, Product with Offer on commerce pages, FAQPage where you have genuine question and answer pairs, and BreadcrumbList wherever you show breadcrumbs. Add sameAs links on your Organization schema pointing at the profiles you actually control, because that is one of the more direct ways to connect scattered brand mentions to a single entity. If entity consistency is a live concern for you, brand mention monitoring in the AI era goes deeper on why that matters now.

Do not add FAQPage schema to a page that does not visibly display those questions and answers to a human visitor. That is the kind of shortcut that works until a manual review, and then it does not.

Core Web Vitals: Lab Scores Versus Real Users

This is where a website audit tool most often misleads people, because the number that is easiest to produce is the number that means the least.

Lighthouse gives you a lab score from a single simulated run. It is genuinely useful as a diagnostic: it tells you which resource blocked rendering, which image was oversized, which script consumed the main thread. It is not a measurement of your users' experience, because it is one run, on one simulated device, on one simulated connection, from one location, usually with an empty cache.

Field data from CrUX is the measurement. It aggregates real Chrome users over a rolling twenty-eight day window and reports the seventy-fifth percentile for each metric. That percentile choice matters: you pass when three quarters of visits pass, which means your worst quarter of experiences defines whether you are in trouble.

The three metrics and their passing thresholds are stable and worth memorizing. Largest Contentful Paint should be at or under 2.5 seconds, and it is usually the hero image, the web font, or a render-blocking script. Interaction to Next Paint should be at or under 200 milliseconds, and it is almost always long JavaScript tasks blocking the main thread when someone taps. Cumulative Layout Shift should be at or under 0.1, and it is almost always images without dimensions, ads injected above content, or a font swap that reflows the page.

The workflow that actually fixes things: use field data to decide whether a problem exists and which page types have it, then use lab data on those specific pages to find the cause. Doing it in the other order means optimizing pages that were never broken. For the ongoing measurement side, Core Web Vitals monitoring covers how to track this continuously instead of in one-off checks, and the PageSpeed Insights API guide covers pulling both lab and field numbers programmatically so you are not clicking through a form for every URL.

One caution about low-traffic URLs: CrUX has no data for pages below a traffic threshold, so a brand new page or a deep archive page will show lab data only. Absence of field data is not a passing grade, it is silence.

llms.txt and the AI-Readable Layer

The newest section of the checklist, and the one most audit products do not cover yet, is whether your site is legible to language models and the retrieval systems in front of them.

Check whether you serve an llms.txt at your root. The convention is a markdown file that lists your important pages with short descriptions, giving a model a clean map instead of asking it to infer structure from navigation. It is not a standard with enforcement behind it, and no engine promises to read it. It costs an hour to write and it is the kind of low-effort hedge that looks obvious in retrospect if adoption continues.

More consequential: check whether your robots.txt blocks AI crawlers you actually want visiting. Many sites added blanket blocks during one news cycle and never revisited them. If you want to be cited in AI answers, blocking the crawler that builds the index those answers draw from is a self-inflicted wound. Decide deliberately, per crawler, rather than inheriting a default someone pasted in.

Then check content shape. Retrieval systems chunk pages and pull the chunk that answers the query. Pages that front-load a direct answer, use headings that mirror real questions, and state facts in self-contained sentences get quoted more often than pages that build to a conclusion across nine paragraphs. A sentence that begins "as we mentioned above" is useless in isolation, and isolation is exactly how it will be read.

Finally, measure whether any of this is working. Classic rank tracking will not tell you, because the answer surface has no positions. Skopx AI Visibility generates buyer-intent prompts from your own site, runs them through search-grounded AI, and reports share of voice plus the citation gaps where a competitor gets named and you do not. If this layer is new to you, start with the generative engine optimization guide and then the AI search optimization checklist for the tactical version.

How Do You Turn Findings Into a Fix Order?

An audit that returns a flat list of issues transfers the hard part back to you. Ranking the list is the actual work.

Sort by two variables: how many URLs the issue affects, and whether those URLs get traffic. A broken canonical on one archived post is a footnote. The same broken canonical in a template that renders four thousand product pages is your week. Join your crawl findings against Search Console impression data and the priority order writes itself, which is one reason pulling Search Console data through its API is worth the setup time over exporting spreadsheets by hand.

Then separate template problems from content problems. Template problems are single fixes with site-wide effect, and they belong to engineering. Content problems are per-page fixes, and they belong to whoever owns that page. Mixing them into one list guarantees that the cheap high-leverage fixes wait behind two hundred title rewrites.

Scoring helps here if the score is transparent about its inputs. A single 0 to 100 number is only useful when you can open it and see which checks contributed what, which is the difference between a number you can act on and a number you can only feel bad about. How SEO health scores work breaks down what a defensible scoring model includes.

How Often Should You Re-Run the Checklist?

Manual audits fail on cadence, not on quality. The full checklist above takes a focused half day the first time. Nobody does it again in month two, and the regression that shipped in month three goes unnoticed until a quarterly traffic review.

The realistic split: run the full checklist quarterly and after any migration, redesign, or CMS change. Run the fast subset weekly, meaning sitemap status codes, robots.txt diff, canonical conflicts on top pages, and field Core Web Vitals on your main page types. Anything a bot can check does not need a human on the schedule, which is the whole argument for automating technical SEO checks rather than calendaring them.

Skopx Site Health runs the Lighthouse pull, the CrUX field data, the Search Console join, and the in-house on-page audit that produces the 0 to 100 score with its fix list, and the results feed the same daily morning briefing as everything else, so a regression shows up as a line you read rather than a dashboard you remember to open. Plans start at 5 dollars per month for Solo and 16 dollars per seat per month for Team, with the AI running on your own key at zero markup or on the included allowance. Details are on the pricing page.

Frequently Asked Questions

What is the difference between a website audit tool and a crawler?

A crawler is one component of an audit. It fetches URLs, follows links, and reports what it found, which covers status codes, redirect chains, internal link structure, and on-page HTML. A website audit tool in the fuller sense combines that crawl with performance data from Lighthouse, real user data from CrUX, and query data from Search Console, then ranks the findings. If a product only crawls, it can tell you a page has a duplicate title but cannot tell you whether that page matters.

How long should a full website audit take?

The first pass on a site under a few thousand URLs takes a focused half day if you are working through the six layers in this checklist by hand. Most of that time goes to interpretation rather than data collection: deciding which of the flagged issues are real, which are template-level, and which are safe to ignore. Automated collection compresses the gathering to minutes and leaves the judgment, which is the part worth your time anyway.

Does a low Lighthouse score mean my site will lose rankings?

Not directly. Lighthouse is a lab diagnostic, and the metrics that feed the page experience signal come from field data in CrUX, not from your lab score. A page can score in the fifties in Lighthouse and still pass Core Web Vitals for real users, usually because real visitors have faster devices than the simulated one. Use the lab score to find causes, and use field data to decide whether a problem exists at all.

Do I need llms.txt on my site?

No engine requires it and none promises to read it, so treat it as optional. It is a short markdown file at your root that lists your important pages with one-line descriptions, and writing one takes about an hour. The more consequential check in the same pass is your robots.txt: if you have blanket-blocked AI crawlers and you also want to be cited in AI answers, those two positions are in conflict, and the block is the one costing you.

Can one tool cover both technical SEO and AI visibility?

They are different measurements and most products do one or the other. Technical SEO auditing checks whether crawlers can reach, render, and index your pages. AI visibility measures whether models name and cite you when someone asks a buying question in your category. Skopx runs both, Site Health for the technical layer and AI Visibility for the answer layer, which is useful mainly because an indexing problem found in one often explains a citation gap found in the other.

What should I check first after a site migration?

Sitemap status codes and canonical tags, in that order, before anything else. Migrations break those two most often and most expensively. Pull every URL in the new sitemap, confirm each returns 200, then check that redirect chains from old URLs resolve in one hop rather than three. After that, verify canonicals in the rendered HTML on a sample of each page type, because template changes are where self-referencing canonicals turn into pointers at the old domain.