Every Check Website Toolkit Runs on Your Site, and What Each One Means
When someone runs their first audit, the question you are probably asking yourself is “what is it actually checking?” Fair question. A score out of 100 means nothing if you don’t know what went into it.
So this is the full list: every check the audit makes (at time of writing), what it looks for, why it matters and what to do when it flags something. To make it concrete, I’ve used examples from the sample site in the Website Toolkit demo, a made-up bakery called Bramble & Oak. I built the demo’s data so that it trips every single check, which makes it a handy place to see each one in context. (A real site will be a lot less dramatic.)
Each check has a severity:
- Error (red): something is broken for visitors right now.
- Warning (amber): it works, but it’s costing you something, such as speed, rankings or trust.
- Info (grey): worth knowing, often deliberate, rarely urgent.
Links and pages
Broken pages
A page on your site that returns an error instead of loading: a 404 (not found) or a 500 (server error). The report tells you which page linked to it, so you know where the bad link lives.
On the demo site, the menu links to a “seasonal specials” page that no longer exists, and a blog post about the new oven throws a server error. Fix: restore the page, or update the link that points to it.
Broken links
A link to another website that doesn’t work: the page is gone, the server errors, or the address is malformed. The report includes the link text, and where it can, a screenshot of the page with the link highlighted.
The bakery’s events page still links to last year’s food festival site, which has gone. Fix: update the link or remove it. Links to sites you don’t control rot quietly over time, which is why I check every one.
Broken anchors
A link to a specific section of a page (/faq/#delivery-areas) where that section no longer exists. The visitor lands at the top of the page instead of the answer they wanted. This usually happens when someone renames a heading. Fix: point the link at the section’s new ID, or put the old ID back.
Missing redirects
A page that existed on an earlier audit and now returns 404, with no redirect to a replacement. Nothing on your site links to it any more, so it doesn’t count as an ordinary broken page. But Google, bookmarks and other websites still do.
The bakery deleted its Christmas 2025 orders page after the season. Fix: add a 301 redirect to the nearest replacement (the menu, or next year’s Christmas page) so those visitors and that search ranking aren’t thrown away.
Redirect chains
A link or page that redirects, and then redirects again: /store/ goes to /shop/, which goes to /order/. Each hop adds a round trip, and search engines are less patient with long chains. Fix: make the first address redirect straight to the final one.
Redirected links
A link that works, but only by taking a detour through a redirect. The most common culprits are old http:// links and missing trailing slashes. The report gives you the exact address to link to instead, so the fix is copy and paste.
Temporary redirects (302/307) get gentler advice. They often depend on the visitor’s language, location or login, so I only suggest changing the link if the destination really is its permanent home.
Changed link destinations
This one catches something most audit tools miss. I remember what each outbound link’s destination page looked like last time, and flag it when that page has changed beyond recognition.
On the demo site, the bakery links to its flour supplier. That domain has expired and been bought by a casino affiliate site, so the bakery is now unknowingly sending its customers there. Expired domains being taken over is common, and it can quietly damage your reputation and search rankings. Fix: remove or replace the link.
Orphaned pages
A page that exists but that nothing on your site links to. Visitors can’t navigate to it, and search engines treat it as unimportant. The bakery’s careers and team pages are both orphans. Someone built them and then forgot to add them to the menu. Fix: link to the page from somewhere sensible, or delete it if it shouldn’t exist.
The 404 page
I deliberately request a page that doesn’t exist and look at what comes back. Problems I flag:
- The server’s default error page instead of one in your own design.
- A “soft 404”: the page says “not found” but returns a 200 OK status, so Google may index junk URLs.
- Redirecting every missing page to the homepage, which confuses visitors and counts as a soft 404 to Google.
- A server error instead of a 404.
Fix: a custom 404 page in your site’s design, with a search box and links to popular pages, that returns a real 404 status.
Unverified pages and links
Sometimes the crawler can’t get a clear answer. The site’s firewall blocked it, the page needs a login, or the server kept timing out. Rather than guess, I list these separately as unverified. They don’t count towards your broken total.
The bakery’s staff login page returns “forbidden”, which is exactly what it should do. Fix: usually nothing, but glance down the list in case something public is being blocked.
Images, stylesheets and scripts
Broken images
An image that fails to load. I also record where the image was referenced: a normal <img>, a responsive srcset, or a social preview tag (og:image). A broken social preview image is easy to miss because it never shows on the page itself, only when someone shares the link.
The bakery’s cake page is missing its lemon drizzle photo, and one blog post has a broken social preview image. Fix: re-upload the file, or fix the path.
Broken stylesheets and scripts
A CSS or JavaScript file the page asks for that isn’t there. Often it’s a leftover from a plugin that was removed. The bakery’s homepage still loads a slider plugin’s stylesheet, and four pages try to load a cookie banner script that’s gone missing. The second one matters more than it sounds: if the cookie banner isn’t loading, your cookie consent may not be working. Fix: remove the reference, or restore the file.
Large images
Images heavy enough to slow a page down (over 800 KB by default, adjustable per site). I don’t treat every big file the same:
- A normal image visitors download (the bakery’s 2.4 MB homepage photo) gets top priority: resize and compress it, or serve WebP/AVIF.
- An image only offered as a large responsive size is lower priority. Browsers only download it on big, sharp screens.
- An image only used as a social preview is never downloaded by visitors. But apps like WhatsApp skip preview images that are too heavy, so it’s still worth shrinking to 1200×630.
If an image CDN is supposed to be converting your images to modern formats and isn’t, I tell you that too.
Unverified images, stylesheets and scripts
As with pages: files the crawler couldn’t confirm either way, usually because a third-party host (like Instagram’s image servers) blocks automated checks. Listed for completeness, not counted as broken.
Search engine basics (SEO)
Page titles
Titles shorter than 30 characters, or too wide to display in full in search results. I measure width rather than just counting characters, because “WWWW” takes up far more room than “iiii”. The bakery’s About page is titled just “About Us”. That’s a wasted chance to tell Google what the page is about.
Meta descriptions
Missing (the wholesale page has none), too short (under about 70 characters) or likely to be cut off in search results (over about 155). Google doesn’t always use your description, but when it does, it’s your one sentence to win the click.
Headings
Pages with no H1 heading at all (the bakery’s blog index) or more than one (the team page has two). One clear H1 per page tells search engines and screen readers what the page is about.
Site-wide SEO findings
A few SEO checks look at the site as a whole rather than one page. The biggest is a robots.txt that blocks the entire site: one stray line that tells every search engine to stay away. It’s a classic launch-day mistake when a staging site’s settings go live.
Content
Content changes
I compare each page’s sections with the last audit and tell you what changed: sections added, removed, or that lost a big chunk of their text. On the bakery site, the pastries page lost its “Seasonal Bakes” section and gained “Cinnamon Buns”, and the About page’s “Our story” lost 64% of its text.
That might be a planned edit. It might be someone deleting the wrong block. Either way, you hear about it as part of a scheduled audit, rather than when a client notices. You can ignore individual sections that change all the time (like a “latest news” box) without ignoring the whole page.
Content integrity
I check page text against a dictionary and flag pages with an unusually high share of words it doesn’t recognise. I also flag spam and pharma terms, words you’ve told me should never appear, and words that look run together (like “sourdoughstarter”, which usually comes from copying text out of a PDF).
On the demo site, the press page has picked up casino and payday-loan wording. That’s the classic sign of a hacked page stuffed with spam links. Real sites have their own vocabulary (brand names, local places), so you can approve words once and they stop being flagged. Approvals pooled across many sites also help every other site’s results.
Duplicate sections
The same heading appearing more than once on a page. The bakery’s cakes page has two “Allergens” sections. Sometimes it’s intentional, but it’s often a page builder block that’s been duplicated by accident.
Repeated copy
The same paragraph of text under different headings on one page. On the bakery’s FAQ page, the answer to “Do you deliver?” is a copy of the answer to “When can I collect?” This usually means text was pasted into the wrong card of a layout, and it’s very easy to miss when proofreading.
Shared social share image
When the same og:image is used on nearly every page (at least 5 pages, 80% or more of them), every post you share on Facebook, LinkedIn or WhatsApp gets an identical preview picture. Most SEO plugins will use each post’s featured image automatically once one is set.
Performance
Slow pages
Pages that took more than 3.5 seconds to load, against a target of under 3. A single load time is a noisy measurement, so I leave a margin before flagging. The bakery’s order page takes over 4 seconds, and that’s the page where a slow load costs actual sales. Large images and heavy scripts are the usual causes; the image and script checks above tell you where to start.
Security
Suspicious scripts
Inline scripts showing the hallmarks of a hidden loader: hex-escaped strings, code that decodes and runs itself, scripts that inject other scripts. This is the technique card skimmers (Magecart) use to steal payment details at checkout. On the demo site, it’s sitting on the checkout page, which is exactly where you’d find a real one.
A legitimate script has no reason to hide its own code, so this is always worth a look. If it turns out to be genuine (some tracking snippets are oddly written), you can allow it with one click and it won’t be flagged again unless its code changes. More on how that works.
Allowed script changed
An inline script you’ve previously allowed whose code has changed. Usually it’s routine, like a tag manager container ID or an API key being updated, so I show how much changed and ask you to re-allow it rather than raising the full alarm.
DNS changes
I record the site’s DNS records (where its website, email and verification records point) and flag any change since the last check. On the demo site, the email (MX) records and the SPF record have both switched to an unknown provider.
DNS changes are usually deliberate: a hosting move, a new email provider. But an unexpected one can mean a compromised registrar or DNS account, and changed email records can mean someone is intercepting your mail. If you didn’t make the change, check your DNS provider and registrar accounts straight away.
Broken Google Maps embeds
A Google Map on the page showing “This page can’t load Google Maps correctly” or a “for development purposes only” watermark. This usually means an expired API key or a billing problem on the Google account. The bakery’s visit-us page has one, which is exactly the page visitors need when they’re trying to find you.
AI visibility
More and more people find businesses by asking ChatGPT, Perplexity, Claude or Google’s AI answers rather than scrolling search results. These checks look at whether those tools can actually reach and read your site.
AI search crawlers blocked
Your robots.txt blocks crawlers that fetch pages to answer people’s questions with a link back to you, such as OAI-SearchBot (ChatGPT search) and PerplexityBot. While they’re blocked, you can’t be cited in those answers. This is often an accident, copied from a “block all AI” list.
AI crawlers blocked by your firewall
robots.txt says yes, but your server or CDN says no. The bakery’s homepage loads fine normally but returns “forbidden” to ClaudeBot. This is almost always Cloudflare’s “Block AI bots” setting, and it overrides robots.txt.
AI training crawlers blocked
Shown as info, not a warning. Blocking crawlers that collect content to train AI models (like GPTBot and Google-Extended) is a common, deliberate choice, and it doesn’t stop you appearing in AI search answers. I list it so you know it’s there.
JavaScript-only content
Pages whose content only appears after JavaScript runs. AI crawlers don’t run JavaScript, so they see a nearly empty page. The bakery’s order page has 38 words in its HTML. Fix: server-side rendering or pre-rendering for pages you want found.
Snippets blocked
Pages using nosnippet or max-snippet:0, which stop Google quoting them in AI Overviews, AI Mode and normal search snippets. Fine on a terms page if it’s deliberate. A problem if it’s on your service pages.
AI opt-out tags
Pages using the non-standard noai / noimageai tags. Some AI tools honour them, some don’t. Info only.
Structured data
Two checks here. Invalid structured data (warning) means JSON-LD markup that won’t parse. One stray comma and search and AI engines ignore the whole block. Structured data gaps (info) covers a homepage that doesn’t say who the business is (Organization or LocalBusiness markup), or articles without a machine-readable author and date, which AI engines favour when choosing what to cite.
llms.txt
A short Markdown file at /llms.txt that points AI tools at a site’s most important pages, a bit like a sitemap written for them. I flag a missing one and check an existing one is well-formed and doesn’t link to broken pages.
Freshness signals
Your sitemap tells crawlers when each page last changed. If every page has the same date (usually the moment the sitemap was generated) or none at all, crawlers can’t tell what’s new, so updated pages get re-read later than they should.
Open Graph tags
Missing og:title, og:description or og:image, the tags used to build link previews in chat apps, social networks and AI assistants. Without them, a shared link is a bare URL.
What you can do with the results
Every issue can be marked fixed, ignored (for this page, or a whole domain), turned into a to-do, or starred as important. Issues found by more than one check are counted once in your score. Each re-audit also shows what’s new, what’s been fixed and what’s come back since the last one.
If you’d like to see all of this on a real report rather than read about it, open the demo. It takes one click, there’s no sign-up, and you get an hour with the bakery site, its checklists and its client feedback to poke at.