Website audit checklist: how to check your site’s technical fundamentals

Part of the WEBCHKR fix guides · Updated 2026-10-18

A website audit checks how a site is set up rather than what it says: whether it loads securely, whether search engines and AI tools can crawl it, whether its email domain is protected, and whether tracking and performance are in order. This checklist walks through doing it by hand, in the same eight groups WEBCHKR uses, with the free tool or browser feature for each step. Expect it to take an hour or two the first time.

Before you start

You need the domain, a desktop browser with developer tools (right-click the page, then Inspect), and somewhere to write things down. A spreadsheet with one row per check works well: what you found, whether it needs fixing, and who owns the fix, since the answers are spread across your web host, your DNS provider, your CMS and your marketing tools.

A few steps show a terminal command (curl or dig, both built into macOS and Linux). Each one has a browser alternative.

1. Site basics

All four versions of your address. Open http://example.com, http://www.example.com, https://example.com and https://www.example.com. All four should end at the same HTTPS address with no certificate warning, ideally through a single permanent (301 or 308) redirect. Test the http versions with curl -sI http://example.com, which shows the status code and the Location it redirects to, rather than in Chrome: Chrome now upgrades http to https by itself and can hide a missing redirect. How to fix redirects.
Home page status. The final address should answer 200. In developer tools, open the Network tab, reload, and read the status of the first request.
Mobile viewport. View the page source and look for <meta name="viewport" content="width=device-width, initial-scale=1">. Without it, phones render the desktop layout zoomed out.
404 handling. Visit a page that cannot exist, such as /this-page-does-not-exist-123. You should see a not-found page, and the status should be 404. A 200 is a soft 404, and Google may treat a redirect to the home page as one too. How to fix soft 404s.

2. Crawling and indexing

robots.txt. Open /robots.txt. It should not contain Disallow: / under User-agent: *, should not block the CSS and JavaScript your pages need, and should list your sitemap on a Sitemap: line.
noindex. Search the page source for noindex, and check the response headers for X-Robots-Tag. Either one keeps the page out of search results.
Sitemap. Open /sitemap.xml (or the address in robots.txt). It should load as XML and list only the pages you want indexed, on your live domain.
Canonical tag. Look for <link rel="canonical"> in the source. It should point at the page's own preferred address on your production domain, not a staging or development host.
What Google actually indexed. In Google Search Console, the Page indexing report (Indexing → Pages) lists pages that are not indexed and why, and URL Inspection shows how Google sees a single page.

How to fix robots.txt, noindex and sitemap problems.

3. On-page SEO and social sharing

Title tag. One <title> per page, unique, describing that page. Put the important words first: Google cuts long titles to fit the screen, and sometimes rewrites them.
Meta description. A one or two sentence summary in <meta name="description">. It does not affect ranking, but Google sometimes shows it as the snippet under your title; otherwise it writes one from the page.
H1. One main heading that says what the page is about, in text rather than inside an image.
Open Graph. og:title, og:description and og:image (1200 by 630 pixels, the size Facebook recommends and LinkedIn accepts) control the preview when the page is shared. Paste the address into LinkedIn's Post Inspector or a share preview tool to see it.
Structured data. Run the page through Google's Rich Results Test and the Schema Markup Validator (validator.schema.org). At minimum, an Organization or LocalBusiness block on the home page tells search engines who runs the site.

4. AI readiness

AI crawlers. In robots.txt, look for groups naming GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot, PerplexityBot and Google-Extended. Make sure what they say matches what you intend, and if your site is on Cloudflare, check its AI crawler settings too, because they can block crawlers whatever your file says. How to allow or block AI crawlers.
llms.txt. Open /llms.txt. It is optional, and if you have one it should be a short Markdown summary of the site with links to its key pages. How to create an llms.txt file.
Answerability. Pages that answer the questions customers actually ask, in plain words near the top, give people and AI search tools something clear to quote. Google says its AI features need no special format or markup.

5. Email authentication

These live in DNS, not on the website. From a terminal:

dig +short TXT example.com                    # SPF: one record starting v=spf1
dig +short TXT _dmarc.example.com             # DMARC: v=DMARC1; p=...
dig +short TXT google._domainkey.example.com  # DKIM: the name depends on the selector

Without a terminal, Google's free Admin Toolbox Dig (toolbox.googleapps.com/apps/dig) runs the same lookups. To find your DKIM selector, open an email you sent, view the original message or its headers, and look for s= in the DKIM-Signature line. Check every service that sends mail as your domain, not only your mailbox provider: newsletters, invoices, your CRM, your website's contact form.

Guides: SPF, DKIM, DMARC.

6. Security and privacy

Security headers. In developer tools, open Network, reload, select the first request and read its response headers, or run curl -sI https://example.com. Look for Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options (or frame-ancestors in a Content-Security-Policy), Referrer-Policy and Permissions-Policy. How to add security headers.
Mixed content. With developer tools open on the Console tab, browse a few pages. Warnings about content loaded over http:// mean an image, script or stylesheet is not using HTTPS.
Privacy policy. It should be linked from every page, usually in the footer, and describe the tracking you actually run. If you use advertising cookies, or analytics cookies with visitors in the EU, you will also need a consent banner. The UK now allows analytics cookies without consent when they are used only to improve your own site and visitors can easily opt out; check the ICO's guidance before relying on that.

7. Analytics and tracking

What is installed. Search the page source for googletagmanager.com, gtag(, and the IDs that follow (GTM-, G-). Google's Tag Assistant (tagassistant.google.com) shows which tags actually fire.
Duplicates. The same GA4 property installed twice, for example hard-coded in the theme and again through Google Tag Manager, can count every page view twice. Tag Assistant shows whether each page view is sent once.
Search Console. Confirm the site is verified, ideally as a Domain property verified through DNS, so it covers every subdomain and both http and https.
Ad pixels. Browser extensions such as Meta Ads Data Advisor (formerly Meta Pixel Helper) confirm that pixels load and fire the events you expect.

8. Performance and accessibility

Core Web Vitals. Run the home page and one key page through PageSpeed Insights (pagespeed.web.dev). The top section is field data from real Chrome users: Largest Contentful Paint should be 2.5 seconds or less, Interaction to Next Paint 200 milliseconds or less, and Cumulative Layout Shift 0.1 or less. The score below it is a lab test, useful for finding causes.
Images. Images are often the heaviest files on a page, so start there. Look for modern formats (WebP or AVIF), width and height attributes so the layout does not jump, and loading="lazy" on images below the fold (but not on the main image at the top).
Accessibility basics. Check for a lang attribute on the <html> tag, alt text on meaningful images, and landmarks such as <main> and <nav>. WAVE (wave.webaim.org) and the Lighthouse panel in Chrome's developer tools flag the common problems. Neither replaces testing by a person who uses assistive technology.

Record, fix, re-check

Fix what stops people and crawlers reaching the site first: certificate and redirect problems, a site-wide noindex or Disallow: /, soft 404s.
Then protect the email domain. Missing SPF, DKIM or DMARC costs deliverability every day and leaves the domain open to spoofing.
Then security headers, on-page SEO and AI readiness. Each is a small change once you know where your site's settings live.
Performance last. It usually takes the most work, and the field data needs about four weeks to reflect a fix.

After each fix, re-check just that item. DNS changes can take as long as the record's TTL to show everywhere: often under an hour, but Google warns it can take up to 72 hours.

How often to audit

Run an audit after any redesign, migration, or change of host, CDN or CMS; whenever you add a new marketing tool or change email providers; and at least once a quarter otherwise. These settings break silently: a redirect rule is lost in a migration, a staging noindex ships to production, a new newsletter tool starts sending without DKIM. Nobody notices until traffic or deliverability drops.