How to Do a Technical SEO Audit (Free Checklist)

You published the pages, tuned the keywords, and still nothing shows up in search. Often the problem isn’t the content. Google may be unable to crawl a page, may choose not to index it, or may see something different from what visitors see.

Learning how to do a technical SEO audit gives you a repeatable way to find those problems using free tools and a fixed order of checks. This guide covers ten steps, each with a pass criterion, a severity level, and the tool that checks it. The quick answer comes first.

How to Do a Technical SEO Audit: Quick Answer

To do a technical SEO audit, crawl your site, check which pages Google has indexed, review robots.txt and sitemaps, fix status codes and redirects, resolve canonical conflicts, review internal links, test mobile rendering, measure Core Web Vitals, check HTTPS, and validate structured data, in that order.

Definition: Technical SEO audit
A technical SEO audit is a systematic review of a website’s crawlability, indexability, rendering, structure, security, and performance, designed to find the issues that stop search engines from discovering, understanding, and ranking its pages.

The ten steps in order:

1. Crawl your website to build a URL inventory.

2. Check which pages Google has indexed in Search Console.

3. Audit robots.txt and XML sitemaps for access and discovery problems.

4. Fix status codes, redirects, and broken links.

5. Resolve canonical and duplicate URL issues.

6. Review site structure, internal links, and orphan pages.

7. Test mobile usability and JavaScript rendering.

8. Measure Core Web Vitals and page speed.

9. Check HTTPS and website security.

10. Validate structured data.

The order follows how Google processes a site: it crawls a URL, indexes it, renders it, and then ranks it. A page that cannot be crawled cannot be indexed, and a page that cannot be indexed gains nothing from speed or schema fixes. That is why indexing checks come before performance checks.

What You Need Before You Start: Free Audit Tools

A free technical SEO audit needs Google Search Console, PageSpeed Insights, Lighthouse, Chrome DevTools, a free crawler such as the free version of Screaming Frog SEO Spider, and optionally Ahrefs Webmaster Tools. Together they cover indexing, site-wide status data, rendering, and performance.

When choosing tools, ask two questions. Does the tool use Google’s own data? Does it show page-level detail you can act on?

A crawler shows what could be wrong, while Search Console shows what Google actually sees. One mistake people often make is trusting a crawler report alone. The audit needs both, because a crawler cannot tell you which URLs Google has chosen to index.

Before starting, verify your site in Search Console and confirm GA4 is collecting data. Without verification, the indexing and Core Web Vitals checks later in the audit are not available.

Step 1: Crawl Your Website

A site crawl is an automated scan that follows links from your homepage and records each URL’s status code, title, canonical, indexability, and depth. In an audit, the crawl produces the URL inventory that every later step checks against.

1. Open your crawler and enter your homepage URL, using the full https:// version.

2. Add your sitemap if the tool allows it, so pages with no internal links are included.

3. Run the crawl and wait for it to finish. On large sites, a free crawler may stop at its URL cap.

4. Export the key columns: URL, status code, indexability, canonical, title, and crawl depth.

5. Save the export as your baseline. You will re-crawl later to confirm fixes worked.

On a large site, sample by page template instead of by URL count. Check one page each from the homepage, category, blog post, and product templates. One broken template can affect thousands of pages, so a single fix at the template level often resolves them all.

A common mistake is crawling only the homepage and a few links, then treating the result as the whole site. If the crawl hits a limit, note which templates it did not reach.

Step 2: Check Which Pages Google Has Indexed

To check whether pages are indexed, open the Page indexing report in Google Search Console, review the indexed and not-indexed totals, and then run URL Inspection on individual pages. Compare Google’s indexed list against the indexable URLs from your crawl to find gaps.

The most damaging edge case is a noindex tag left on after launch. A staging setting carries into production, and important pages quietly drop out of search while the team keeps publishing.

“Crawled – currently not indexed” is often a content-quality signal rather than a technical bug. Google may judge the page thin, repetitive, or too similar to another page. Fixing it usually means improving the page, not editing code.

To compare lists, export your crawl’s indexable URLs and the indexed URLs from Search Console. Pages in the first list but missing from the second are your investigation queue.

Step 3: Audit Robots.txt and XML Sitemaps

Check that robots.txt does not block important pages or CSS and JavaScript files, and that your XML sitemap lists only canonical, indexable URLs that return a 200 status. Robots.txt controls crawl access, while the sitemap helps search engines discover pages.

Robots.txt

• Look for accidental disallows. A Disallow: / copied from a staging site blocks the entire site.

• Check for blocked resources. Blocking CSS or JavaScript files can stop Google from rendering pages correctly.

• Use the robots.txt report in Search Console to confirm Google can fetch and parse the file.

• Keep the file small. According to Google’s documentation, Google processes only the first 500 KiB of a robots.txt file.

XML sitemaps

• List only indexable URLs. Remove redirected, noindexed, canonicalized, and error URLs.

• Respect the limits. Per Google Search Central documentation, one sitemap file can hold up to 50,000 URLs or 50 MB uncompressed. Larger sites use a sitemap index.

• Submit the sitemap in Search Console and check for errors.

• Keep lastmod honest. Update it only when page content changes.

A noindex tag and a robots.txt block conflict with each other. Google cannot see a noindex tag on a page it is not allowed to crawl, so the URL may stay in the index. To remove a page from search, allow crawling and use noindex.

Step 4: Fix Status Codes, Redirects, and Broken Links

The HTTP status codes that matter most in a technical SEO audit are 200 (OK), 301 (permanent redirect), 302 (temporary redirect), 404 (not found), 410 (gone), and 5xx (server errors). Each tells search engines how to treat a URL, and 5xx errors are the most urgent.

Redirect chains happen when one URL redirects to another that redirects again. Loops send crawlers in circles. Per Google’s documentation, Googlebot follows up to 10 redirect hops, but shorter chains are faster and safer. Aim for one hop from the old URL to the final one.

A soft 404 is a page that shows “not found” content but returns a 200 status. Search Console reports these, and the fix is to return a real 404 or restore the content.

Update internal links to point to the final URL instead of relying on redirects. Redirects are a safety net, not a substitute for correct links.

Not every 404 needs fixing. According to Google’s guidance, 404 errors on URLs that never existed or have no value do not harm the rest of your site. Prioritize broken URLs that have backlinks, internal links, or traffic.

Step 5: Resolve Canonical and Duplicate URL Issues

A canonical tag is an HTML element that tells search engines which URL is the preferred version when the same or very similar content exists at several addresses. It consolidates ranking signals onto one URL and reduces duplicate indexing.

Common causes of duplicate URLs:

• www vs non-www: www.example.com and example.com both load.

• HTTP vs HTTPS: both versions return a page.

• Trailing slashes: /shoes and /shoes/ serve the same content.

• URL parameters: filters, sorting, and tracking codes create new URLs.

A mini example: if example.com/shoes?color=red shows a filtered view of the main shoes page, its canonical tag should point to example.com/shoes. The main page should carry a self-referencing canonical that points to itself.

Google treats canonicals as a hint, not a command. When signals conflict, such as a canonical pointing one way, a redirect another, and the sitemap listing a third URL, Google may choose a different URL than you intended. Search Console reports this as “Duplicate, Google chose different canonical than user.”

Teams often run into this after a migration, when old canonicals are copied across. The fix is consistency: the canonical, internal links, redirects, and sitemap should all name the same URL.

Step 6: Review Site Structure, Internal Links, and Orphan Pages

An orphan page is a page with no internal links pointing to it, which makes it hard for search engines to discover and weakens its authority. To find one, compare the URLs in your sitemap and GA4 landing pages against the URLs your crawler reached through links.

1. Check crawl depth. Pages many clicks from the homepage are typically discovered and revisited less reliably. Google publishes no fixed depth limit, so use depth as a relative signal and look for important pages buried deeper than they should be.

2. Find orphan pages. Pages in the sitemap or in GA4 landing page reports that your crawl did not reach through links are orphan candidates.

3. Check hub and cluster links. Each main topic page should link to its supporting articles, and those articles should link back.

4. Review anchor text. Descriptive anchors tell search engines what the target page is about. Anchors like “click here” carry no topic signal.

Internal links serve crawling and relevance at the same time. They create the paths Googlebot follows, and their anchor text and context signal topical relationships. A page can be indexed with weak internal links, but it usually performs better with them.

A common issue is adding new pages to the sitemap without linking to them from anywhere. The sitemap helps discovery, but internal links tell Google the page matters.

Step 7: Test Mobile Usability and JavaScript Rendering

To check whether Google can render your JavaScript content, run a live test in Search Console’s URL Inspection tool, open “View tested page,” and compare the rendered HTML and screenshot with what visitors see. Content missing from the rendered HTML may not be indexed.

1. Confirm mobile parity. Google predominantly uses the mobile version of a page for indexing. Text, links, structured data, and images present on desktop should also appear on mobile.

2. Compare raw and rendered HTML. In Chrome, view the page source (raw HTML), then inspect the page in DevTools (rendered HTML). Important text and links should appear in the rendered version.

3. Run the URL Inspection live test. Open “View tested page” to see the rendered HTML and a screenshot of what Googlebot received.

4. Check blocked resources. If the screenshot looks broken, a blocked script or stylesheet may be the cause.

5. Test with JavaScript disabled in DevTools to learn how much content depends on it.

Raw source can look nearly empty while the rendered page is fine, and the reverse is also possible. Content that appears only after a user clicks, scrolls, or logs in may never be seen by Googlebot.

Google has retired its standalone Mobile-Friendly Test and the Mobile Usability report. Use Lighthouse, DevTools device emulation, and URL Inspection instead.

Step 8: Measure Core Web Vitals and Page Speed

Good Core Web Vitals scores, per Google’s web.dev documentation, are a Largest Contentful Paint (LCP) of 2.5 seconds or less, an Interaction to Next Paint (INP) of 200 milliseconds or less, and a Cumulative Layout Shift (CLS) of 0.1 or less, each measured at the 75th percentile of page loads.

Field data and lab data measure different things. Field data comes from real users and appears in the Search Console Core Web Vitals report and at the top of PageSpeed Insights. Lab data comes from a simulated test, such as Lighthouse. The two can disagree, and low-traffic sites may have no field data at all. In that case, use lab data to find fixes and re-check field data later.

Audiences in markets like Bangladesh often browse mainly on mobile devices and slower connections, so speed problems that look minor on a fast office network can matter more. For international audiences, hosting location and a CDN can also affect server response and LCP.

One mistake people often make is chasing a perfect 100 Lighthouse score. The goal is passing the three thresholds for real users, not maximizing a lab number.

Step 9: Check HTTPS and Website Security

HTTPS issues that affect SEO include an expired or invalid SSL certificate, HTTP pages that do not redirect to HTTPS, mixed content (insecure resources on secure pages), and security warnings reported in Search Console. Each can trigger browser warnings or split ranking signals between URL versions.

• Certificate validity: the certificate is current and covers the exact domain, including www if used. Pass: the browser shows no warning.

• Redirects: every HTTP URL redirects with a 301 to its HTTPS equivalent. Pass: no HTTP page returns a 200.

• Mixed content: images, scripts, or stylesheets load over http:// on an HTTPS page. Pass: the DevTools console shows no mixed-content warnings.

• Search Console security issues: check for hacked content or malware flags. Pass: no issues listed.

Certificate renewals that lapse silently are a common cause of sudden traffic drops. Browsers show a full-page warning, and most visitors leave. Set a calendar reminder or enable auto-renewal, and confirm it actually works.

Step 10: Validate Structured Data

To check structured data for errors, paste the URL into Google’s Rich Results Test to see which rich result types are eligible, then use the Schema Markup Validator to check general Schema.org syntax. Fix errors first and review warnings by importance.

• Test key templates: one article, one product, and the homepage are usually enough to catch template-wide problems.

• Match visible content. Markup should describe what users can actually see on the page. Google’s structured data guidelines warn against marking up content that isn’t visible.

• Choose types that fit. Article, Organization, BreadcrumbList, Product, and LocalBusiness are the most commonly useful.

• Check Search Console enhancement reports for errors across the whole site.

Valid markup does not guarantee rich results. Google decides whether to show them based on eligibility, quality, and the query. Treat schema as a way to clarify meaning, not a switch that forces a result.

How to Prioritize Technical SEO Issues

Fix issues in this order: first those that block indexing, then those that waste crawling or split ranking signals, then those that affect page experience, and last cosmetic warnings. Impact on whether pages can appear in search should decide the order, not the number of warnings.

For a quick impact-versus-effort check, sort fixes into four groups: high impact and low effort (do first, such as removing an accidental noindex), high impact and high effort (plan, such as a speed overhaul), low impact and low effort (batch later), and low impact and high effort (usually skip).

Beginners can follow the severity order and stop there. Advanced teams can also weight by traffic and revenue, fixing template-level issues on pages that already earn impressions.

Not everything needs fixing. A handful of old 404s with no links or traffic can be left alone, and chasing every crawler warning is a common way to burn time without improving visibility.

Free Technical SEO Audit Checklist

A technical SEO audit checklist covers crawl access, indexing, status codes, canonicals, internal links, rendering, Core Web Vitals, HTTPS, and structured data. Each check needs a tool, a pass criterion, and a severity level so you know when it is complete and how urgent a failure is.

Keep a simple findings log with five columns: URL, issue, severity, owner, and status. It turns the audit from a one-time report into a work list you can track and re-check.

Common Technical SEO Audit Mistakes

The most common technical SEO audit mistakes are checking page speed before indexing, treating every crawler warning as an error, ignoring Search Console data, blocking resources in robots.txt, auditing only the homepage, and never re-crawling after fixes. Most of them come from skipping the order of dependencies.

The scenario to watch for is polishing pages Google cannot see. A team rewrites titles and content on pages that are noindexed, blocked, or not indexed, and nothing improves. Re-crawling after each batch of fixes confirms the change worked and caught nothing new.

When to Do It Yourself and When to Get Help

A free audit is usually enough for small sites with no indexing errors. Hire a professional for technical SEO when pages stay unindexed after basic fixes, when a migration or redesign is planned, or when speed and rendering problems trace back to code, hosting, or a JavaScript framework you cannot change yourself.

Do it yourself when:

• The site is small, and Search Console shows no major indexing errors.

• Problems are limited to titles, links, sitemaps, and settings you can edit in your CMS.

• You can re-run the checklist after each change.

Bring in a specialist when:

• The site is large, uses a JavaScript framework, or relies on custom code.

• Traffic dropped after a migration, redesign, or platform change.

• Indexing or Core Web Vitals problems persist after the basic fixes.

Framecipher offers technical SEO services for teams that want a developer-level review and implementation. Sites targeting the US, UK, Canada, and Australia together may also need hreflang and regional setup reviewed, which is easy to get wrong without experience.

Conclusion

A technical SEO audit works best as an ordered process rather than a long list of checks. Start with what Google can crawl and index, move to rendering and speed, and score each finding by how much it affects visibility.

Three practical takeaways:

1. Audit in dependency order: indexing first, then rendering, then speed and structured data.

2. Score every finding by severity so you fix the few issues that matter and skip the noise.

3. Re-crawl and re-check Search Console after fixes to confirm they worked.

Your next step: run the free checklist on your ten most important pages and log each finding by severity. If critical issues remain after the basic fixes, a professional audit from Framecipher can help you find the cause and plan the repair.