Technical SEO Audit vs Full SEO Audit: Which One Do You Need?
A technical audit asks whether search engines can use your site; a full audit asks why it ranks where it does. How to tell which one you need.
- Updated
- 8 min read
By Szymon Kokot Published Updated 23 min read
Technical SEO Checklist (2026): 36 Checks for Any Website
A technical SEO checklist answers one question: can search engines and AI crawlers find, crawl, render and index the site without obstruction? This checklist covers 36 checks in nine areas: crawling and indexing, site architecture, JavaScript rendering, speed, mobile experience, security, structured data, international targeting and AI crawler access. It leaves out keywords, content, competitors and conversion entirely. It follows the same 36 points as the Illucrum Technical SEO Audit and works for any kind of site.
In short: A technical SEO audit checks robots.txt, sitemaps, index coverage, status codes and redirects; URL structure, canonicals, internal links and pagination; whether content depends on JavaScript; speed and Core Web Vitals; mobile rendering; HTTPS, mixed content and exposed files; structured data and robots directives; hreflang and parameter URLs; and AI crawler access. All 36 checks run on free tools.
What does this technical SEO checklist cover?
This technical SEO checklist covers 36 checks in 9 sections. It goes deeper on the technical layer than the site-type checklists (website, SaaS, e-commerce and local), which each cover it in 7 to 12 checks.
| # | Section | Checks | The question it answers |
|---|---|---|---|
| 1 | Crawlability and indexation | 1 to 7 | Can crawlers reach the pages that matter, and index those and not others? |
| 2 | Site architecture and URLs | 8 to 12 | Are addresses, canonicals, links, depth and pagination in order? |
| 3 | Rendering and JavaScript | 13 to 15 | Is the content in the HTML crawlers receive? |
| 4 | Speed and Core Web Vitals | 16 to 20 | How fast does the site load and respond, and what slows it down? |
| 5 | Mobile and page experience | 21 to 23 | Does the site work on phones, where Google does most of its crawling? |
| 6 | Security and HTTPS | 24 to 27 | Is the site served securely, and does it expose anything it shouldn't? |
| 7 | Structured data and directives | 28 to 30 | Is the machine-readable layer valid and set as intended? |
| 8 | International and parameter handling | 31 to 33 | Are language versions, domain variants and parameter URLs handled? |
| 9 | Machine and AI access | 34 to 36 | Can AI crawlers reach the site and read its core facts? |
A technical audit suits a site before or after a migration, redesign or platform change, a site whose traffic dropped without an obvious cause, or a team that needs a precise list of technical fixes for its developer.
What do you need before you start?
You need verified Google Search Console access and a handful of free tools. Without Search Console, about a third of the checks can only be estimated from public data.
| Tool | Used for | Cost |
|---|---|---|
| Google Search Console | Index coverage, crawl stats, URL Inspection, Core Web Vitals, settings | Free, needs a verified site |
| PageSpeed Insights | Performance, Core Web Vitals, render-blocking and image diagnostics | Free |
| Illucrum Bulk SEO Checker | Status codes, canonicals, robots directives, headings, links and schema from the raw HTML of up to 25 URLs | Free, no account |
Chrome DevTools and curl |
Network, headers, redirects, raw HTML against the rendered page | Free |
| A desktop crawler such as Screaming Frog | Site-wide status codes, redirect chains, click depth and orphans | Free up to 500 URLs |
| Rich Results Test and Schema Markup Validator | Structured data validity and the HTML Google renders | Free |
| SSL Labs Server Test | Certificate and HTTPS configuration grade | Free |
| Security Headers | Security header presence | Free |
Before the first check, open a spreadsheet with four columns: check number, finding, evidence (a URL or screenshot) and severity. Then list one URL for each page template (homepage, service or product page, category or listing page, article, contact page), because technical problems usually live in templates.
Section 1: How do you check crawlability and indexation? (checks 1 to 7)
Crawlability and indexation checks establish whether search engines can reach the pages that matter, and whether Google indexes those pages and not others. If crawlers can't reach a page, nothing else in this checklist matters for it.
1. Robots.txt configuration
Robots.txt is the file at /robots.txt that tells crawlers which parts of a site they may visit. Open it in a browser and confirm it returns HTTP 200, not a 404 or 5xx. Read all of it. Look for Disallow: / under User-agent: *, which blocks the whole site, and for rules that catch important sections or the CSS and JavaScript files needed to render pages. Confirm a Sitemap: line points to a live sitemap.
Good result: 200 status, nothing important blocked, sitemap declared.
Record: status code, the full file, each rule affecting content, and whether the sitemap is declared.
2. XML sitemap health
Open the sitemap and confirm it is valid XML and returns 200. Paste its URLs into the Bulk SEO Checker in batches of 25, or run them through a crawler: every listed URL should return 200, be canonical and have no noindex. Confirm admin, cart, thank-you and parameter URLs are left out, lastmod dates are real rather than all set to today, and the sitemap is submitted in Search Console with status Success.
Good result: a valid, current sitemap listing only live, canonical, indexable URLs, submitted in Search Console.
Record: URL count, failing URLs by reason, the Search Console status and the discovered count.
3. Index coverage and excluded pages
In Search Console, open Indexing, then Pages. Record the indexed and not indexed totals and the count for each reason, especially "Crawled, currently not indexed", "Discovered, currently not indexed", "Soft 404", "Excluded by noindex tag" and the duplicate reasons. Run URL Inspection on your most important pages.
Good result: every important page indexed, and every exclusion intentional.
Record: indexed and not indexed counts, the full reason breakdown and any important page excluded.
4. HTTP status codes and server errors
Crawl the site and sort URLs by status code. Flag every 4xx and 5xx that is linked internally or listed in the sitemap. Request a URL that doesn't exist (/this-page-does-not-exist) and read the status in the DevTools Network tab: it must be a real 404. A missing page that returns 200 is a soft 404, which creates indexable junk. In Search Console, Settings, Crawl stats, check the share of server errors Googlebot receives.
Good result: no linked 4xx or 5xx URLs, real 404s for missing pages and no server errors in crawl stats.
Record: 4xx and 5xx URLs with the pages linking to them, the status of a missing page and the crawl stats error share.
5. Redirect chains and loops
A redirect chain is a redirect that passes through more than one step, such as A to B to C; a loop leads back to itself. List chains and loops from your crawl, and test known legacy URLs by hand in the Network tab. Check permanent moves use 301 or 308, not 302, and that internal links point at final URLs rather than at redirects.
Good result: single-step redirects, permanent codes for permanent moves, and internal links to final URLs.
Record: each chain with its steps, each loop, and temporary redirects used for permanent moves.
6. Crawl budget and index bloat
Crawl budget is the attention crawlers give a site; index bloat is when far more pages are indexed than the site needs. Compare the indexed count from check 3 with the number of pages that should be indexed. Scan the indexed URLs for parameters, filters, tag archives, internal search results and paginated duplicates. In Crawl stats, see what Googlebot spends its requests on by response and file type.
Good result: an indexed count close to the real number of useful pages, with crawling spent on them.
Record: indexed count against intended count, types of low-value indexed URLs with rough counts, and average crawl requests per day.
7. Orphan pages
An orphan page exists but isn't linked from anywhere on the site, so crawlers can only find it through the sitemap or by chance. Compare two lists: every URL in the sitemap (plus a site:yourdomain.com search for pages missing from the sitemap), and every URL a crawler finds by following links from the homepage. Anything in the first list but not the second is an orphan.
Good result: no orphan pages among the pages that matter.
Record: the orphan list, with commercially important ones marked.
Section 2: How do you check site architecture and URLs? (checks 8 to 12)
Site architecture checks look at how the site is organized: its addresses, canonicals, internal links, depth and pagination. These decide how crawlers move through the site and which pages receive the most internal weight.
8. URL structure and consistency
Review a spread of URLs across page types. Check they are lowercase, use hyphens rather than underscores, avoid unnecessary parameters and IDs, and follow one convention per page type. The usual finding is inconsistency: trailing slashes on some URLs and not others, mixed case, dates in some paths. Changing working URLs has a cost, so fix structure only where it causes real problems, always with 301 redirects.
Good result: readable URLs that follow one convention per page type.
Record: the convention in use per page type and every place it breaks.
9. Canonicalization and duplicate URLs
A canonical tag (<link rel="canonical">) tells search engines which address is the main version of a page. Check it on each template with the Bulk SEO Checker: it should be an absolute HTTPS URL pointing to the page itself. Then test duplicate paths: trailing slash, www, http, a tracking parameter and any print or alternate route. Each should redirect or carry the main URL's canonical. Check the canonical, sitemap and internal links all agree on the same URL.
Good result: one main address per page, with every duplicate pointing to it.
Record: missing, relative or wrong canonicals, and duplicate paths that return 200 with no canonical.
10. Internal linking and link equity flow
Internal links carry crawlers, and ranking strength, from page to page. In your crawl, check the number of internal links pointing to each important page, and whether they come from related content or only from the menu and footer. Sample anchor text with the Links table of the Bulk SEO Checker and note how much is "click here", "read more" or a bare URL.
Good result: important pages linked from relevant content with descriptive anchors.
Record: internal link counts for the top ten pages and the main anchor text patterns.
11. Site depth and click distance
Click depth is the number of clicks from the homepage to a page. A crawler reports it for every URL. Sort by depth and look at what sits four or more clicks deep. Important pages buried that deep receive less crawling and less internal weight.
Good result: important pages within three clicks of the homepage.
Record: the number of URLs at each depth and important pages deeper than three clicks.
12. Pagination handling
Find a paginated series such as a blog archive or product listing. Open page 2 and view the source. Check its canonical points to page 2 itself, not back to page 1, and that pagination links are ordinary <a href> links rather than JavaScript-only buttons. Google no longer uses rel="next" and rel="prev", so crawlable links are what let it reach deeper pages.
Good result: self-canonical paginated pages linked with plain, crawlable links.
Record: the canonical of each paginated page, how pagination links work, and any noindex on paginated pages.
Section 3: How do you check rendering and JavaScript? (checks 13 to 15)
Rendering checks establish what exists in the HTML a server sends and what only appears after scripts run. Google renders JavaScript, but not always immediately or completely, and most AI crawlers largely don't render it at all.
13. JavaScript rendering and content parity
Paste one URL per template into the Bulk SEO Checker, which reads the raw HTML without running JavaScript. If a page that looks complete in the browser comes back with no H1, few links and a word count near zero, its content depends on JavaScript. Confirm by comparing "View page source" with the DevTools Elements panel, and with the HTML shown in the Rich Results Test, which is what Google rendered. Check the H1, body copy, navigation links, canonical and meta tags one by one.
Good result: headings, body content, links, canonical and meta tags all present in the raw HTML.
Record: for each of the five elements, whether it is in the raw HTML, the rendered page or both.
14. Render-blocking resources
Render-blocking resources are CSS and JavaScript files that hold up the first display of a page. In PageSpeed Insights, open the render-blocking diagnostic and record the files listed with their estimated savings. Note scripts loaded in the <head> without defer or async.
Good result: no significant render-blocking files on key templates.
Record: the files listed, the potential saving and the current LCP for context.
15. Lazy-loading of critical content
Lazy loading delays images and other content until they are about to scroll into view. PageSpeed names the Largest Contentful Paint element; check that element in the HTML. If it is an image with loading="lazy", it is loading late on purpose, which slows the main content. Also check that important text isn't loaded only on scroll or on click, where crawlers may never see it.
Good result: the main image loads immediately, and lazy loading is used only below the fold.
Record: the LCP element per template, whether it is lazy-loaded, and any content loaded only on interaction.
Section 4: How do you check speed and Core Web Vitals? (checks 16 to 20)
Speed checks measure how fast the site loads and responds for real visitors, and find what slows it down. Test at least three templates; a homepage test alone isn't representative.
16. Page speed (mobile and desktop)
Run one URL per template through PageSpeed Insights for mobile and desktop. Record both Performance scores and judge on the lower one, which is almost always mobile.
Good result: a mobile Performance score of 90 or above on every key template.
Record: mobile and desktop scores per template and the top three opportunities for each.
17. Core Web Vitals (LCP, INP, CLS)
Core Web Vitals are Google's three measures of real visitor experience. Read the field data at the top of each PageSpeed report, which comes from real Chrome users; if there is none, the site has too little traffic and you are working with lab data only. Then open Search Console, Core Web Vitals, for the site-wide view by URL group.
Good result: Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less, as Google defines them.
Record: the three values per template, field or lab, and URL counts in each Search Console status.
18. Image optimization and modern formats
From PageSpeed, record the image diagnostics: properly sized images, efficient encoding, modern formats (WebP or AVIF) and explicit width and height. Then check the main image of a key page in the Network tab: compare its file size and pixel dimensions with the size it is displayed at.
Good result: images sized for display, compressed, served in a modern format and with dimensions set.
Record: each diagnostic with its estimated saving, and the main image comparison.
19. Caching, compression and CDN
Open the Network tab, reload a page and click a CSS or JavaScript file. Read its response headers: look for content-encoding: gzip or br (compression), and a cache-control header with a long max-age for static files. curl -I on a file URL shows the same headers. Look for signs of a content delivery network (CDN), such as cf-ray or x-served-by headers.
Good result: compressed responses, long caching for static files and a CDN where the audience is spread out.
Record: compression, cache-control values for static files and whether a CDN is used.
20. Third-party script weight
Third-party scripts are code loaded from other companies: analytics, tag managers, chat, ads, review widgets. In PageSpeed, open the third-party diagnostic and record each provider's transfer size and main-thread blocking time. If a tag manager is installed, list the tags it actually fires.
Good result: third-party code limited to what the business uses, loaded without blocking the page.
Record: each third party with size and blocking time, and any script loaded synchronously in the <head>.
Section 5: How do you check mobile and page experience? (checks 21 to 23)
Mobile checks confirm the site works on phones, where most visitors arrive. Google completed its move to mobile-first indexing in 2024, so the mobile version of a page is the version Google indexes.
21. Mobile rendering
Load each template in DevTools device mode at 390 pixels wide, then on a real phone. Check the layout holds, with no sideways scrolling or text too small to read. Then compare the mobile version with desktop: the same main content, headings, links, structured data and meta tags should be present on both. Content hidden or removed on mobile is content Google doesn't index.
Good result: the mobile version shows the same content, links and markup as desktop, in a layout that works.
Record: per template, layout problems and anything present on desktop but missing on mobile.
22. Viewport and tap targets
Confirm <meta name="viewport" content="width=device-width, initial-scale=1"> is in the source of every template; the Bulk SEO Checker lists the viewport of each URL. In device mode, inspect the main navigation links, buttons and form fields. WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels at level AA; around 44 to 48 pixels is a safer size for main buttons.
Good result: the viewport tag on every template, and buttons and links easy to tap.
Record: the viewport value per template and elements that are too small or too close together.
23. Intrusive interstitials
An interstitial is a pop-up or overlay that covers the page. Load key landing pages on a phone in a private window, so cookies don't suppress pop-ups, and note anything that covers the main content on arrival or within a few seconds. A standard cookie notice is fine; a full-screen overlay is what Google's page experience guidance names as a problem.
Good result: nothing covers the content on arrival except a consent notice.
Record: pages with overlays, what triggers them, when and how much of the screen they cover.
Section 6: How do you check security and HTTPS? (checks 24 to 27)
Security checks confirm the site is served securely and doesn't expose anything it shouldn't. They are observations from the outside, not a security test, and should only be run on a site you own or have permission to check.
24. HTTPS enforcement and SSL certificate
Confirm every page loads over HTTPS and that http:// redirects to https:// in a single step. Click the padlock for the certificate's issuer, the domains it covers and its expiry date, and run the domain through SSL Labs for a configuration grade.
Good result: HTTPS enforced, a valid certificate not close to expiry and grade A or A+.
Record: redirect behavior, expiry date, issuer and grade.
25. Mixed content
Mixed content is a secure page loading images, scripts or other files over plain HTTP. Load key pages with the DevTools Console open, where mixed content warnings appear automatically, and search the page source for http:// in src and href attributes. Scripts and iframes loaded over HTTP (active mixed content) are blocked by browsers and are more serious than images.
Good result: no mixed content on any template.
Record: each mixed content file, its type, and whether it is active or passive.
26. Security headers
Security headers are instructions a server sends that tell browsers how to protect visitors. Run the domain through securityheaders.com, or read the headers with curl -I https://yourdomain.com. Look for Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options or a frame-ancestors rule, Referrer-Policy and a Content-Security-Policy. These are hygiene and trust measures rather than ranking factors.
Good result: the standard headers present with sensible values.
Record: each header present or missing, and its value.
27. Exposed files and endpoints
Request common paths on your own site and note the status codes: /.env, /.git/config, /backup/, /phpinfo.php, old admin paths, and any staging subdomain. Anything returning real content is a finding. Search site:yourdomain.com for staging or test subdomains in Google's index, and search the page source of key pages for anything that looks like an API key or password.
Good result: nothing private reachable or indexed.
Record: each exposed path or indexed staging URL, and any credential in client-side code.
Section 7: How do you check structured data and directives? (checks 28 to 30)
Structured data and directive checks look at the machine-readable layer of the site: structured data, instructions to search engines and social metadata.
28. Structured data validity
Structured data is code (usually JSON-LD) that describes a page in a fixed vocabulary. The Bulk SEO Checker lists every block on up to 25 pages and flags any that fail to parse. Run one URL per template through the Rich Results Test and the Schema Markup Validator, and record types, errors and warnings. Check every claim in the markup (prices, ratings, dates, authors) appears on the page, and look for duplicate or conflicting blocks, often from a theme and a plugin both adding markup. FAQ rich results stopped appearing in Google on May 7, 2026, so don't count FAQ markup as a Google feature.
Good result: valid markup on every template, matching the visible page, with no conflicting blocks.
Record: types per template, errors, warnings, mismatches with the page and conflicting blocks.
29. Robots directives and snippet controls
Robots directives are page-level instructions such as noindex, nofollow, nosnippet and max-snippet. Check the <meta name="robots"> tag on each template (the Bulk SEO Checker lists it per URL) and the X-Robots-Tag HTTP header, which never appears in the HTML. nosnippet and restrictive max-snippet values also limit Google's AI Overviews and AI Mode. In Search Console Settings, check the Search generative AI control, which became available worldwide in August 2026 and removes a site's content from Google's AI features without affecting regular ranking.
Good result: directives set exactly as intended, with no accidental noindex or snippet limits.
Record: the directive on each template in both places, snippet controls and the state of the AI control.
30. Open Graph and social metadata
Open Graph tags control how pages look when shared on social platforms and in messaging apps. The Bulk SEO Checker export includes every og: and twitter: tag per URL. Check each template has og:title, og:description, og:image, og:url and og:type, that the image URL loads and that it is around 1,200 by 630 pixels.
Good result: complete tags and a working, correctly sized image on every template.
Record: tags present per template, image problems and templates sharing one generic image.
Section 8: How do you check international and parameter handling? (checks 31 to 33)
International and parameter checks cover language and region targeting, domain consistency, and the extra addresses that tracking codes, filters and sorting create.
31. Hreflang implementation
Hreflang tags tell search engines which language or country version of a page to show each visitor. If the site has one language for one market, mark this check N/A. Otherwise, view the source of a page that exists in several versions and check: valid language and region codes, a self-reference, reciprocal links between every pair of versions, an x-default, and target URLs that return 200 and are canonical.
Good result: valid, reciprocal hreflang with a self-reference and an x-default on every version.
Record: the hreflang set per sampled page, missing return links, invalid codes and broken targets.
32. Host and protocol consistency
Request all four versions of the domain: http://domain.com, http://www.domain.com, https://domain.com and https://www.domain.com. Each should redirect in one step to a single preferred version. Then confirm that version is the one used in canonicals, the sitemap and internal links.
Good result: every variant leads to one preferred host in one step, used consistently everywhere.
Record: the destination and number of steps for each variant, and any variant that returns 200.
33. Parameter and faceted URL handling
URL parameters are the parts after a question mark, created by sorting, filtering, tracking and session IDs. List the parameter patterns the site generates and check in Search Console which have been indexed. For each pattern, check whether pages carry a canonical to the clean URL, a noindex, a robots.txt block or nothing. Google's guide to managing faceted navigation covers the options for filter URLs.
Good result: every parameter pattern handled deliberately, with no duplicate parameter URLs indexed.
Record: each pattern, the number indexed and the handling applied.
Section 9: How do you check machine and AI access? (checks 34 to 36)
Machine and AI access checks confirm that AI crawlers and assistants can reach the site and read its core facts. This is the technical layer only; whether assistants actually cite or recommend the business is what the GEO checklist measures.
34. AI crawler access
AI crawlers fall into three classes, and blocking the wrong class removes a site from AI answers. Check robots.txt rules for each, including the wildcard rule.
| Crawler class | What it does | Examples |
|---|---|---|
| Retrieval | Builds the index an assistant searches | OAI-SearchBot, Claude-SearchBot, PerplexityBot, Bingbot |
| User-triggered | Reads a page when a person asks the assistant to | ChatGPT-User, Claude-User, Perplexity-User |
| Training | Collects content for model training | GPTBot, ClaudeBot, Google-Extended, CCBot |
Robots.txt states intent, but a firewall, CDN or bot-protection setting can block crawlers regardless. Request a key page with a retrieval crawler's user agent (curl -A "OAI-SearchBot" https://yourdomain.com/) and compare with a normal request; a 403 or challenge page means the edge is blocking it. Some providers verify crawlers by IP address, so server logs are the final word where you have them.
Good result: retrieval and user-triggered crawlers allowed in robots.txt and at the firewall, and a deliberate choice about training crawlers.
Record: the rule for each crawler, the result of the user-agent test and whether each block was intended.
35. Machine-readable content
Check that the site's core facts (what the business does, its services or products, prices, contact details) exist as plain text in the HTML, rather than only in images, PDFs or content loaded by JavaScript. The Words table of the Bulk SEO Checker shows what text a non-rendering crawler receives. You can note whether an llms.txt file exists, but don't count its absence as a fault: no major AI search product has confirmed using it, and Google's John Mueller called it "purely speculative" in June 2026.
Good result: core business facts readable as plain text in the raw HTML.
Record: for services, prices and contact details, whether each is plain text, and the llms.txt status.
36. Entity structured data (Organization and sameAs)
Entity markup tells machines who is behind the site. Check the homepage for Organization markup, or a specific type such as LocalBusiness, with name, url, logo, description and contact details. Check the sameAs property lists the brand's real profiles elsewhere: LinkedIn, the Business Profile, review platforms and directories.
Good result: complete organization markup with sameAs links to real profiles.
Record: the type used, fields present and the full sameAs list.
Frequently asked questions
How long does a technical SEO audit take to do yourself?
A first pass through this technical SEO checklist takes four to six hours on a small site if you know the tools. Much of that time is waiting for crawls, SSL Labs scans and PageSpeed runs across several templates. Larger sites take longer because sampling has to be more careful, not because the checks change.
Do I need paid tools for a technical SEO audit?
No. Every check in this technical SEO checklist runs on Search Console, PageSpeed Insights, Chrome DevTools, the Illucrum Bulk SEO Checker, a free crawler tier and free validators. Paid crawlers save time on sites with more than 500 URLs, but they don't reveal a category of problem the free tools miss. The SEO audit vs SEO tool comparison covers what tools can and can't tell you.
When should you run a technical SEO audit?
Run a technical SEO audit before and after a migration, redesign, platform change or domain move, and whenever traffic drops without an obvious cause. Between audits, the Search Console Pages and Core Web Vitals reports are worth a monthly look, because they show regressions without you having to search for them.
What is the difference between a technical SEO audit and a full SEO audit?
A technical SEO audit asks whether search engines can use the site: crawling, rendering, indexing, speed and security. A full SEO audit also asks why the site ranks where it does, adding content, keywords, backlinks, competitors and conversion. The technical vs full SEO audit comparison covers when each one fits.
The value of a technical audit is in the record, not the reading: thirty-six measured findings, each with evidence, can be put in order and handed to a developer. If you'd rather have the data collected, scored and prioritized for you, the Technical SEO Audit covers all 36 points at a fixed price listed on the pricing page.