Technical Website Audit Tool Checklist

A technical website audit is a pass over the parts of a site that search engines and browsers actually fetch: the HTML, the headers, the DNS, and whether the page can be read without a login. It is not a brand review and it is not a full Core Web Vitals lab run. If you want that first-pass health check without installing software, start with our free technical website audit tool — paste a URL, no account required.

This guide walks through the same modules that tool scores, so you know what each finding means and what to fix first. If you already have a separate checklist for AI-generated pages, keep using the AI-content technical SEO checklist; this one is about the site itself.

What the audit is for

Use a technical audit before a redesign, a domain move, a campaign launch, or whenever Search Console shows impressions but the page feels slow or badly indexed. The job is to find blockers: a missing HTTPS redirect, a title that never made it into the HTML, a robots rule that hides the page, or mail records that will bounce outreach from the same domain.

Our tool scores six areas and then averages them: speed, page performance, DNS, on-page SEO, security, and AI search readiness. A low overall number is a prompt to open the failed rows, not a ranking prediction. Fix the critical and high items first. Medium and low items can wait until the page loads and can be crawled.

How to run the free tool

1. Open the website audit.
2. Paste a public HTTPS URL. Use the live homepage or the landing page you care about, not a staging host that blocks crawlers.
3. Wait for the modules to finish. You get ring scores plus a finding list with evidence and a recommendation.
4. Optionally email yourself the PDF if you need a record for a developer or a vendor.

The fetch is a server-side first-pass. It reads the HTML, response headers, robots.txt, sitemap hints and public DNS. It does not log in or replace PageSpeed Insights for field Core Web Vitals. After you clear the critical issues, run PageSpeed on the same URL for lab and CrUX detail.

Speed: first byte and payload

Speed here is about the HTML response, not a full Lighthouse filmstrip. The module records time to first byte (TTFB), total time to download the HTML, the size of that HTML, whether the response is compressed, and whether the connection looks like HTTP/2 or HTTP/3.

• TTFB. A long wait before any bytes arrive usually means a cold origin, a slow database, or no cache at the edge. A content delivery network and cacheable HTML help more than minifying one script.
• Total response time. This is TTFB plus download. A large template or a chat widget dumped into the first HTML makes this worse.
• HTML size. Hundreds of kilobytes of markup before the first image is a template problem. Split below-the-fold blocks and stop inlining huge SVG sprites in every page.
• Compression. Text should arrive as gzip, Brotli, or zstd. If the tool reports no Content-Encoding, turn compression on at the host or the CDN.
• Protocol. HTTP/1.1 still works. HTTP/2 or HTTP/3 multiplexes assets and usually lowers latency on modern stacks.

Treat speed fails as “the page is expensive to get,” not as a Core Web Vitals score. You still need a lab or field test for LCP and INP.

Performance: scripts, images and cache

The performance module looks at how the HTML is built, not at a filmed load. Typical findings:

• Render-blocking scripts. A <script src> in the head without async or defer holds the first paint. Tag managers and chat widgets are the usual culprits. Defer anything that is not needed to render the first screen.
• Stylesheet count. Many small CSS files mean extra connections. Bundle the critical path and load the rest later.
• Image dimensions. Images without width and height (or an aspect-ratio) cause layout shift when they load. Add the attributes in the CMS or the theme.
• Resource hints. preconnect, dns-prefetch and preload help when you already know the LCP image or a third-party origin. They are optional; missing hints are a warning, not a crash.
• Cache headers. Cache-Control, ETag or Last-Modified let browsers and CDNs reuse files. HTML can stay short-lived; CSS and images should not.
• CDN. The tool looks for common CDN signatures (Cloudflare, Vercel, Netlify, CloudFront, Fastly). No signature is a hint, not proof you are unprotected.

DNS and mail records

DNS is why a pretty site can still fail email and fail over. The audit resolves public records for the host:

SPF and DMARC belong on the same domain you send campaigns from. For a deeper mail-only pass, use the SPF, DKIM, DMARC and BIMI deliverability write-up and the matching checker on the tools index.

On-page SEO the HTML must contain

These checks read the document the crawler gets. If your app renders the title only after JavaScript, the audit will say it is missing — and so will many bots.

• Title. Present, roughly 10–60 characters, with the phrase people search near the front.
• Meta description. Present, roughly 50–160 characters, one clear sentence. Google may rewrite it; an empty tag still looks unfinished.
• Canonical. A self-referential absolute URL on the same host. Wrong hosts and leftover staging URLs split signals.
• One H1. The page should have a single H1 that matches the intent. Duplicates usually come from a theme header plus the article title.
• Image alt. Meaningful images need alt text. Decorative images can use empty alt; missing attributes on a product shot are the problem.
• Open Graph and Twitter Card. og:title, og:description, og:image and twitter:card so shares do not show a random crop.
• Sitemap. /sitemap.xml or a sitemap listed in robots.txt. Login and admin URLs should stay out of it.
• Internal links. A handful of in-site links so the page is not an island.
• JSON-LD. At least one valid application/ld+json block. Organization on the homepage, Article on posts. Generate a block with the schema markup generator if the finding is empty.
• Content depth. Very short HTML bodies look thin. Service and blog URLs need enough copy to explain the page.
• Hreflang. Only if you actually have locale variants. Do not add them as decoration.

HTTPS and a 200 status sit in the same technical group. An HTTP URL or a 301 chain is worth collapsing before you rewrite titles. The redirect checker guide covers hop-by-hop status codes if the audit shows a protocol hop.

Security headers

Security in this audit is a header and transport check, not a penetration test. The tool looks for:

• HTTPS — the page was requested over TLS.
• HSTS — Strict-Transport-Security so browsers keep using HTTPS.
• Content-Security-Policy — limits scripts and frames the page may load.
• X-Frame-Options — reduces clickjacking on pages that should not be iframed.
• X-Content-Type-Options — usually nosniff.
• Referrer-Policy — stops full URLs leaking to third parties.
• Permissions-Policy — camera, geolocation and similar browser features.
• No mixed content — HTTPS pages should not load HTTP images or scripts.
• Cookie flags — if Set-Cookie is present, look for Secure, HttpOnly and SameSite.
• Server leakage — Server and X-Powered-By advertising exact versions.
• CORS — a wildcard Access-Control-Allow-Origin combined with credentials is a fail.

A missing CSP on a marketing site is common and not an emergency if you already use HTTPS and HSTS. A missing HTTPS redirect is an emergency. Ask hosting or the CDN to set headers if you do not control the origin.

AI search readiness

This module is about whether answer engines can fetch and quote the page, not about “ranking in ChatGPT.” The audit checks robots.txt for AI crawlers (allowed, blocked, unspecified, or conflicting), whether llms.txt or ai.txt exists, whether the HTML already contains FAQ-style headings, and whether the first HTML looks like an empty shell that only fills in after JavaScript.

Blocked bots are a policy choice. If you want citations, do not disallow GPTBot, ClaudeBot, PerplexityBot or Google-Extended on the URLs you care about. If you want to opt out, say so in robots.txt on purpose — do not leave a leftover Disallow: / from a staging copy.

Malformed JSON-LD is a fail even when a type is present. Fix the script tag before you add more types. After the technical pass, the AI search readiness checker is a tighter 12-point look at llms.txt, sitemap, schema and FAQ copy.

What to fix first

1. HTTPS, 200 status, and no accidental noindex on public URLs.
2. A and NS records; SPF/DMARC if you send mail from the domain.
3. Title, meta description, canonical and a single H1 in the server HTML.
4. TTFB and compression if the HTML is slow to arrive.
5. HSTS and mixed content.
6. JSON-LD that matches the visible page.
7. Everything else on the list.

Hand the PDF to whoever can change the theme or the CDN. Marketers can usually fix titles, descriptions, alt text and schema without a deploy.

Frequently asked questions

Is this the same as a Lighthouse report?

No. Lighthouse and PageSpeed Insights run a lab browser and report Core Web Vitals-style metrics. This audit is a first-pass technical SEO and operations check on the HTML, headers and DNS you get from one fetch.

Why did the title fail when I can see it in the tab?

The tab title can be set by client-side JavaScript after load. Crawlers that do not execute your bundle will see an empty <title>. Put the real title in the document the server sends.

Do I need an account?

No. Paste a URL and run it. Sign in only if you want saved reports.

Should login and admin be in the sitemap?

No. Keep /login and /admin out of the sitemap and behind noindex. The audit is for public URLs.

Run the checklist on your site

Open the free technical website audit tool, paste the URL you actually want indexed, and work the failed rows from the top. If you need a prioritized fix plan after the scan, that is an SEO and content conversation, not another plugin.