Technical SEO Audit: A Prioritized Checklist for 2026

In short: A technical SEO audit answers four questions in order: can Google reach your pages, can it index the right version of each one, can it understand what each page is about, and does the page work well for the people it sends. Start with status codes, robots.txt and noindex rules, then redirects, canonicals and sitemaps, then titles, structured data and hreflang, then HTTPS, mobile parity and Core Web Vitals. Fix by impact, not by the length of the issue list, and recheck after every release.

Most audits fail the same way. A crawler lists 214 "issues" sorted by count, and the team spends a week adding alt text to decorative images while a noindex tag left over from staging keeps the pricing page out of Google. Volume is not priority.

This checklist follows the path a page takes through Google: crawled, indexed, understood, served. A problem early in that chain makes everything after it irrelevant, so audit and fix in that order. Every rule below comes from Google's documentation.

What a technical SEO audit covers

A technical audit is about access and interpretation, not about whether your content deserves to rank. Google's technical requirements are short: Googlebot isn't blocked, the page returns HTTP 200, and the page has indexable content. Google adds that meeting them "doesn't mean that a page will be indexed; indexing isn't guaranteed." Everything else in an audit is about removing the reasons Google might skip, misread or demote a page.

Before you start: four sources of truth

1. Search Console Page indexing report: which URLs Google indexed and why it skipped the others.
2. URL Inspection tool: Google's view of one URL, including the rendered HTML and the canonical it chose.
3. A site crawler: status codes, redirects, titles and canonicals for every page it can reach.
4. A page-level checker: our free website SEO checker runs 38 checks on the page you enter (your home page by default) and the site files around it in about 20 seconds.

Record a baseline first (indexed pages, not-indexed pages by reason, URLs found by the crawler), or you cannot tell whether the fixes worked.

Step 1: Can Google reach your pages?

Status codes

Every URL you want in search must answer with 200. Google documents how it treats the others in How HTTP status codes affect Google Search and Redirects and Google Search:

Two details matter in practice. Google says "all 4xx errors, except 429, are treated the same," so a 404 and a 410 lead to the same result. And 429 is the code firewalls and bot protection send when they think a crawler is too fast, which is why a security product can quietly slow your indexing.

Google interprets an instant meta refresh as permanent and a delayed one as temporary. JavaScript redirects work only if rendering succeeds; Google's advice is to use them only when server-side or meta refresh redirects are not possible.

robots.txt

robots.txt manages crawler traffic. According to Google's robots.txt introduction, it "is not a mechanism for keeping a web page out of Google." A disallowed page "can still be indexed if linked to from other sites," shown without a description.

Check three things:

• The file exists at the root and returns 200 as plain text, not an HTML page, or a clean 404 if you need no rules. Never a 5xx: Google then pauses crawling.
• No rule blocks the sections you want in search. The classic disaster is a Disallow: / copied from staging.
• CSS and JavaScript needed to render the page are not blocked.

The robots.txt checker reads your file the way Googlebot does and flags rules that block the whole site or the page you enter, and a robots.txt that answers with a server error.

noindex and X-Robots-Tag

A noindex meta tag or an X-Robots-Tag: noindex HTTP header keeps a page out of results. The header form also works for PDFs, images and videos, which cannot carry a meta tag (Block Search indexing with noindex).

The trap: if robots.txt blocks the same URL, "the crawler will never see the noindex rule, and the page can still appear in search results." To remove a page, allow crawling and serve noindex. Audit both the HTML and the response headers, because CDNs and plugins can add X-Robots-Tag without anyone editing the page.

Step 2: Can Google index the right version?

One site, one address

http://example.com, http://www.example.com, https://example.com and https://www.example.com are four different URLs to a crawler. Pick one and permanently redirect the other three to it in a single hop. Do the same for trailing slashes and uppercase paths if your server answers both ways. The redirect checker tests all four host versions, shows the status code of every hop and flags temporary redirects, loops and long chains.

Canonical tags

Google's canonicalization guide ranks the signals: redirects and rel="canonical" are strong signals, sitemap inclusion is a weak one. All are signals, not commands; Google can choose a different canonical. Its best practices:

• Use absolute URLs in canonical tags.
• Add a self-referencing canonical on the canonical page itself.
• Name the same canonical in every method (tag, header, sitemap).
• "Don't use the robots.txt file for canonicalization purposes."

Typical findings: every page canonicalizing to the home page, and canonicals pointing to redirected or 404 URLs.

XML sitemaps

From Build and submit a sitemap:

• A single sitemap is limited to 50,000 URLs or 50 MB uncompressed. Larger sites split into several files listed in a sitemap index.
• Google ignores <priority> and <changefreq>.
• Google uses <lastmod> only "if it's consistently and verifiably accurate," and it should reflect significant changes, not a new copyright year.
• Submit it in Search Console and reference it in robots.txt with a line such as Sitemap: https://example.com/sitemap.xml.

A sitemap should list only canonical, indexable URLs that return 200. Redirects, 404s and noindex pages in the sitemap send mixed signals and are among the most common findings in a crawl.

Soft 404s

A soft 404 is a page that returns 200 but looks like an error: an empty category, a "product not found" message, a search page with no results. Search Console reports them under "Soft 404". Return a real 404 or 410 for missing content, or put useful content on the URL.

JavaScript rendering

Google crawls, then renders with a headless Chromium, then indexes the rendered HTML (JavaScript SEO basics). Rendering happens "once Google's resources allow," so content that exists only after scripts run arrives later and is more fragile. Check:

• Links are <a> elements with an href. Google says it "can only discover your links" that way; click handlers on <div> or <span> are invisible to it.
• Client-side routes use the History API, not # fragments.
• Single-page apps avoid soft 404s by redirecting to a URL that returns 404 or by adding noindex to error views.
• Important text is present in the server response. Google still recommends server-side rendering or pre-rendering, and notes that "not all bots can run JavaScript," which matters even more for AI crawlers (see Step 5).

Use URL Inspection's live test to compare the raw HTML with the rendered HTML for one template of each type.

Step 3: Can Google understand each page?

Titles

Google's title link documentation asks for a distinct, descriptive and concise <title> on every page, without keyword stuffing or boilerplate. It states there is no length limit, but titles are truncated to fit the device. Google also rewrites title links automatically, using the <title>, the main heading, og:title, anchor text and other sources, especially when the title is missing, duplicated or unhelpful. A practical range of about 30 to 60 characters keeps the important words visible; that is a convention, not a Google rule.

Meta descriptions

Google says snippets "are primarily created from the page content itself" and that it sometimes uses the meta description when it gives a more accurate summary (Control your snippets). There is no length limit; the snippet is truncated as needed. What Google does warn against is identical descriptions on many pages and descriptions made of keyword lists. Audit for missing and duplicate descriptions on your important templates, and write a readable summary for each. The meta tag checker previews how a page looks in results.

Structured data

Google recommends JSON-LD "if your site's setup allows it" and the Rich Results Test to validate it (intro to structured data). In an audit, check that each template carries the markup it should (Organization on the home page, Product on product pages, Article on posts, BreadcrumbList where breadcrumbs exist), that it is valid, and that it matches what is visible on the page. Which types still earn rich results in 2026, and how to write them, is covered in our schema markup guide; the schema markup checker lists what a page declares now.

hreflang

For sites with language or country versions, Google's localized versions guide sets the rules:

• Use HTML link tags, HTTP headers or the sitemap; Google treats them as equivalent.
• Each version lists itself and every other version. Annotations that are not reciprocated may be ignored.
• Use an ISO 639-1 language code, optionally followed by an ISO 3166-1 alpha-2 region (en, en-GB, pt-BR). A country code alone is invalid.
• Use absolute URLs, and optionally x-default for visitors who match none of your versions.

Google detects page language from content with its own algorithms, not from hreflang or the lang attribute, so a German URL with English body text is still an English page. The hreflang checker validates the codes against these rules, checks the self-reference and notes whether x-default is set; it reads one page, so check the return links on the other versions too.

Step 4: Does the page work well for visitors?

HTTPS and mixed content

Serve every URL over HTTPS with a valid certificate and redirect HTTP permanently. Google's page experience guidance asks "Are your pages served in a secure fashion?" Also look for mixed content (scripts or images loaded over http://), which browsers partly block. The security headers checker covers the certificate, HTTPS redirect, HSTS and mixed content.

Mobile-first indexing

"Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking," per its mobile-first indexing best practices. The audit question is parity: the mobile version must have the same primary content, the same structured data, the same robots meta tags and equivalent titles and descriptions. Google also warns against lazy-loading primary content on user interaction, because Googlebot does not click, swipe or type.

Note that Google retired its Mobile-Friendly Test and the Search Console Mobile Usability report on December 1, 2023, pointing site owners to Lighthouse instead (Google Search Central Blog). Our mobile-friendly test checks the basics: the viewport tag, responsive images, favicon and page language.

Core Web Vitals

Google states that "Core Web Vitals are used by our ranking systems," while also saying good scores do not guarantee top rankings and relevance comes first. The targets on web.dev, measured at the 75th percentile of real visits:

INP replaced First Input Delay as a Core Web Vital in 2024. In a technical audit, note which templates fail and move on; diagnosing and fixing each metric is a project of its own, covered step by step in our Core Web Vitals guide. The Core Web Vitals checker reads your site's real Chrome user data.

Step 5: AI search readiness

For AI Overviews and AI Mode, Google says a page must be indexed and eligible for a snippet, with no extra requirements, and that your CDN or host must allow crawling too. Other assistants use their own crawlers: OpenAI uses OAI-SearchBot for ChatGPT search and GPTBot for training, and sites that block OAI-SearchBot "will not be shown in ChatGPT search answers." Audit three things: AI search crawlers are allowed in robots.txt and by the firewall, key content is in the HTML response, and the home page states who you are with Organization markup. The AI search readiness checker tests all three; our generative engine optimization guide covers the rest.

Reading the Page indexing report

The Page indexing report is where the audit meets reality. Google's own framing: "You should not expect all URLs on your site to be indexed, only the canonical pages." So the job is not to empty the "Not indexed" list. It is to make sure every important canonical page is indexed and that each exclusion is intended.

After fixing an issue everywhere, click Validate fix. Google says validation stops if even one instance remains and "typically takes up to about two weeks."

URL Inspection for single pages

The URL Inspection tool shows the indexed version (not live) and, with Test live URL, the current page as Googlebot fetches it: availability, crawl and indexing permission, user-declared and Google-selected canonical, rendered screenshot, raw HTML, HTTP headers and loaded resources. Use it on one URL per template after every fix. Request indexing helps for a few key pages; for many pages, Google recommends a sitemap with accurate lastmod values. Both inspections and indexing requests have daily limits per property.

Crawl budget: only for very large sites

Crawl budget is the most over-diagnosed issue in SEO. Google's crawl budget guide is written for sites with roughly 1 million or more unique pages changing weekly, sites with 10,000 or more pages changing daily, and sites with a large share of URLs in "Discovered - currently not indexed". Google calls these rough estimates, not exact thresholds, and says that if your pages are crawled the same day they are published, you do not need the guide. For most sites, a current sitemap and a regular look at Page indexing are enough.

How to triage: impact times effort

Score each finding on impact (how many important pages it affects and how badly) and effort (how hard it is to fix), then work top-down.

Fix templates, not pages: a missing title on a product template is one fix.

Worked example (hypothetical)

The following is a hypothetical example, not real data. Northwind Outfitters, an invented outdoor gear shop with about 1,200 product and category pages, runs an audit after a redesign. Search Console shows 640 pages indexed, down from 1,050 before the launch.

The crawler reports 312 findings. Sorted by count, the top three are missing alt text (148), long titles (61) and missing meta descriptions (40). Sorted by the order in this checklist, the picture changes:

1. Reach: robots.txt is fine, but 38 URLs return 429 during the crawl. The new bot protection rate-limits anything faster than a person.
2. Index: every filtered category URL (?color=, ?size=) carries a canonical to itself, creating 400 near-duplicates. The sitemap still lists 90 old URLs that now redirect. All product pages on http://www. redirect twice: to https://www., then to https://.
3. Understand: the 61 "long" titles are over by a few characters.
4. Experience: LCP fails on the category template because the hero image is lazy-loaded.

The fix order: allow verified crawlers through bot protection, canonicalize filtered URLs to the unfiltered category, regenerate the sitemap from canonical URLs only, collapse the redirect chain to one hop, then load the category hero image eagerly. Alt text and title lengths go into the next content sprint. Six weeks later the indexing drop has recovered, and the remaining "not indexed" URLs are the filtered pages, as intended.

How often to audit

Run a full audit quarterly and around every migration, redesign or URL change (crawl staging before launch, production the day after), and automate the essentials weekly: status codes, noindex and robots.txt changes, sitemap errors and the Page indexing trend. Technical SEO rarely decays slowly; it breaks on a deployment day.

A one-hour starting checklist

1. Run the free website SEO checker and note the high-priority failures.
2. Record Page indexing counts by reason in Search Console.
3. Live-test one URL per template in URL Inspection; compare raw and rendered HTML.
4. Check robots.txt, the four host versions and one redirect chain.
5. Spot-check ten sitemap URLs: each should return 200, be indexable and be canonical.
6. Put the findings in the impact × effort table and fix the top three this week.

How Searvia runs a technical SEO audit

Searvia's free website SEO checker reads the page you enter (the home page if you enter only a domain) and the site files around it (robots.txt, sitemap, llms.txt), your certificate, your email DNS records and real-user speed data from Chrome. It runs 38 checks in six sections: search appearance (9), crawling and indexing (6), AI search readiness (7), speed (6), mobile (4) and security (6), and gives an A+ to F grade with a prioritized fix list and a shareable report. Focused versions of the same engine are listed on the free tools page.

For the whole site, the Site audit in a Searvia account crawls your pages like a search engine, groups issues into errors, warnings and notices (broken pages and links, redirects in the sitemap, noindex pages in the sitemap, canonicals pointing elsewhere, duplicate titles, orphan pages and more), and runs again every week so you see what you fixed and what broke. Pages per audit depend on your plan; the free plan covers 100. Connect Search Console to see real Google indexing and clicks next to the audit, and verify your site to send new and changed pages to engines that support IndexNow, such as Bing and Yandex, after every audit.