Technical SEO Checklist: What to Check in a Website SEO Audit

The most common mistake is starting with the cosmetic. Someone rewrites meta descriptions on twenty pages while robots.txt blocks a whole section. Work from the general to the specific, in five steps.

1. Crawling: can a robot fetch the page (robots.txt, status codes, redirects)?
2. Indexing: is the page allowed into the index (noindex, canonical, duplicates)?
3. Understanding: does the markup and text make clear what the page is about (title, headings, structured data, language)?
4. Speed: does the page load without avoidable delay?
5. Safety: is the site served over HTTPS without unsafe settings?

Decide first what you are auditing: one page, one template or the whole site. A fault in a template repeats on thousands of URLs, so one template problem outweighs ten single-page problems. Google's SEO starter guide is a good reference for the basics.

Also be clear about the limits of your tools. A passive scanner reads one URL and a handful of public supporting files. It does not crawl the whole site, run JavaScript or measure rankings. For a site with hundreds of pages, combine a quick scan with Google Search Console.

Begin with /robots.txt. Check that it returns 200, that Disallow: / does not apply to the whole site, and that it does not block the stylesheets and scripts needed to render the page. Syntax and common mistakes are covered in robots.txt: how to write and check it.

Next, status codes. A live page should return 200, a removed one 404 or 410, and a moved one 301 or 308 to a single final address. Chains of several redirects slow crawling down, and a redirect loop makes the page unreachable. A temporary 302 on a page that moved for good should be fixed too. Google explains permanent moves in its redirect documentation.

Check the HTTPS version and host duplicates separately. The www and non-www versions should not both serve the content: pick one and redirect the other. The same goes for http and https.

Finally, the sitemap. It should exist, be declared in robots.txt with a Sitemap: line, and list only canonical URLs that return 200. Requirements and errors are in sitemap.xml: requirements, errors and how to check it.

A minimal setup for this block looks like this:

User-agent: *
Disallow: /admin/

Sitemap: https://example.com/sitemap.xml

Once the robot reaches a page, something decides whether it enters the index. Three signals matter here, and they must not contradict each other.

Noindex directives

Check the robots meta tag and the X-Robots-Tag HTTP header. A noindex left over from a staging environment is among the costliest launch mistakes: the page works, but it never appears in search. Remember that the crawler has to be able to read the directive, so a page with noindex must not also be blocked in robots.txt. See Google's page on blocking indexing.

Canonical

The rel="canonical" tag suggests which URL is the main one among similar pages. Verify that it is present, uses an absolute https address, points to a page that returns 200 and does not point elsewhere without a reason. Typical errors are collected in canonical tags: when you need them and common mistakes.

Soft 404 pages

These pages say "nothing found" but return status 200. They waste crawl effort and give you nothing. Make sure a non-existent address returns a real 404.

A related case is a page with almost no content in the initial HTML, for example one assembled purely by scripts. If the source holds almost no text, a search engine may see less than a visitor does.

This is the most visible part of an audit, though not the most important. Check at least the following.

• The title exists, appears once, describes this particular page and is not a generic word such as "Home". Keep it short enough not to be cut off; Google explains how titles are chosen in its title link documentation.
• The meta description exists, differs from the title and is not truncated. Google may rewrite it, but a well-written one does no harm, see the snippet documentation.
• Exactly one non-empty h1, then subheadings without skipped levels.
• A lang attribute on the html tag with a valid language code.
• A meta viewport so the page renders properly on a phone.
• alt text on informative images, plus width and height attributes.
• A doctype and a declared character encoding.

A basic head can look like this:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Page name</title>
  <meta name="description" content="A short description of the page for search results.">
  <link rel="canonical" href="https://example.com/page">
</head>

Do not chase perfect lengths. They are guidelines, not search engine requirements. It matters more that the metadata is unique and describes the page honestly.

Internal links help visitors and robots alike. Check for broken links, session identifiers in URLs, malformed links (empty or with typos) and http links on an https page. A sample of a few internal links is enough for a quick look, but a large site needs a full crawl.

Structured data gives a page a machine-readable description. Check that JSON-LD is present, that it is valid JSON, that @context is set and that the type matches the content. Which types an ordinary site really needs is covered in JSON-LD structured data: what an ordinary website needs. Markup does not guarantee a rich result, and markup describing content that is not visible on the page goes against Google's rules.

If the site is multilingual, check hreflang separately: valid language codes (uk for Ukrainian, not ua), a self-reference on every version, return links between versions and x-default. The usual failures are described in hreflang: common errors and how to check them.

Last, social metadata. Open Graph and Twitter Cards change how a link looks in messengers and social feeds, not where the page ranks. The favicon belongs here too, and its absence is easy to spot.

Speed is measured in two different ways, and they should not be confused. Field data from real visitors appears in the Core Web Vitals report in Google Search Console and in PageSpeed Insights. Lab data comes from Lighthouse. What LCP, INP and CLS mean, and why their thresholds are set where they are, is explained in Core Web Vitals for beginners.

A passive scanner does not measure Core Web Vitals. It reports only indirect signs that a page may be slow to load:

• the server response time of the single main request (not a Core Web Vitals metric);
• the size of the HTML document;
• whether response compression is on;
• whether HTTP/2 is supported;
• whether cache headers are present;
• render-blocking scripts in the head;
• the number of third-party hosts and web fonts;
• images without declared dimensions, which can cause layout shift;
• legacy image formats.

These are pointers to where to look, not a score. If a scanner flags images without dimensions, that is a layout-shift risk, not a measured CLS. For real numbers, use field data.

Security belongs in a technical audit for two reasons. First, Google recommends serving pages over HTTPS. Second, faults such as mixed content, an expired certificate or a form that submits over http put visitors off and break pages.

Check the following:

• every page is reachable over HTTPS and http redirects to https;
• the certificate is valid, not expired and issued for the right hostname;
• the page has no mixed content (scripts and styles loaded over http);
• the main headers are set: Strict-Transport-Security, X-Content-Type-Options, a Content-Security-Policy and protection against framing.

Security headers are not ranking factors on their own. But a badly written CSP can block scripts your pages need, and HSTS saves returning visitors a redirect. How to set and verify them is described in security headers and SEO. If a security review is what you need, see the website security check.

Here is the summary: what to check, and whether the passive SEOAudit report shows it.

To set priorities, fix what blocks search visibility first: noindex, a closed robots.txt, server errors, redirect loops. Next come problems that blur signals: conflicting canonicals, duplicate hosts, hreflang errors. Metadata, markup and minor notes close the list. The scanner report separates important results from informational ones, which helps you avoid spending time on details.

Repeat the check after every significant release, template change, migration or domain move, and on a schedule, for example monthly. For an automated pass there is the SEO audit page, and if visibility in AI search matters to you, see AI search readiness.