Technical SEO audit: how to run one step by step

A technical SEO audit is a structured check of whether search engines can find, crawl, render, and index your pages. This guide walks the audit in the order that saves time, then shows how to rank what you find so you fix the right things first.

People also search for this as an "seo tech audit". Same job. You are looking for the technical reasons a good page is not getting the visibility it should.

Before you start: set the scope

Decide what you are auditing before you open a tool. A 40-page local business site and a 40,000-page store need different depth.

• Pick the property. Use the exact Search Console property (domain or URL-prefix) so the data matches the site you crawl.
• List the pages that make money. Home, service pages, location pages, top products. These get checked by hand, not just by tool.
• Note recent changes. A migration, a redesign, or a plugin swap is the first suspect for any drop.
• Save a baseline. Export clicks, impressions, and indexed page count so you can prove the audit worked.

Tools like Argus, the ZeusSEO site crawler, handle the crawl and the issue list so you spend your time on decisions. More on that in the steps below.

Step 1: Check crawlability

If a bot cannot reach a page, nothing else matters. Start here.

1. Open robots.txt. Confirm it loads at the root, returns a 200, and does not block folders you want ranked. A stray "Disallow: /" left from staging is common. Remember robots.txt controls crawling, not indexing; Google's robots.txt introduction explains the difference.
2. Check for noindex. Look at the meta robots tag and the X-Robots-Tag header on key pages. Noindex plus a sitemap entry sends mixed signals.
3. Crawl the site yourself. A crawler follows links the way a bot does and shows you status codes, titles, and broken links in one pass.
4. Look for 4xx and 5xx errors. Pages returning 404 that still have internal links are a quick win. Repeated 5xx errors suggest a hosting problem.

In ZeusSEO, Argus crawls a site and reports site-wide totals: pages returning 4xx or 5xx errors, pages with broken internal or external links, noindex pages, and pages with broken schema. It also lists crawled pages worst-first by issue count with their index status. One honest limit: the crawl data does not keep redirect chains, so check those separately (Step 4).

Step 2: Check indexing and Search Console coverage

Crawled does not mean indexed. Search Console tells you what Google actually did.

1. Read the Pages (indexing) report. Compare indexed against not indexed, then read the reason for each group. Google documents the reasons in its Page indexing report help.
2. Sample with URL Inspection. Inspect your top pages. The URL Inspection tool shows the indexing status of a page and lets you run a live test.
3. Cross-check the count. If your sitemap lists 500 URLs and Google indexed 300, find out which 200 are missing and why.
4. Separate intentional from accidental. Thank-you pages and filtered URLs should stay out. Service pages should not.

ZeusSEO can run these checks through your AI assistant. It can inspect a single URL against the real URL Inspection API, batch a list, and diff a sitemap against what is indexed. These calls are read-only. They report Google's status, including the coverage state, last crawl time, and whether Google's chosen canonical matches yours. They never request indexing. The setup is covered in the Search Console MCP guide.

Step 3: Audit your sitemaps

A sitemap is a list of pages you want indexed. Treat it as a promise and check that you keep it. Google describes what a sitemap does in its sitemaps overview.

• Only canonical, indexable, 200-status URLs. No redirects, no 404s, no noindex pages, no parameter duplicates.
• Submitted in Search Console. Confirm the status is "Success" and the discovered URL count looks right.
• Referenced in robots.txt. Add the Sitemap line so any crawler can find it.
• Up to date. New pages appear, deleted pages leave. A stale sitemap wastes crawl attention.
• Split large sites. Use a sitemap index so each file stays manageable.

The sitemap-versus-indexed diff is the fastest way to see the gap. It collects your submitted sitemap URLs, checks them against Google, and returns the ones that are not indexed with their coverage state. Large sitemaps are checked in resumable batches because Google limits daily inspections.

Step 4: Check redirects

Redirects are where migrations quietly break.

1. Find chains. A to B to C should be A to C. Each hop slows the page and dilutes clarity.
2. Find loops. A redirects to B, B redirects to A. The page never loads.
3. Use permanent redirects for moves. A permanent redirect tells Google the move is permanent. A temporary redirect left in place for years is a bug. Google's redirect documentation covers how each type affects the URL shown in results.
4. Force one version. HTTP to HTTPS, and one choice between www and non-www, all in a single hop.
5. Fix internal links to point at the final URL. Do not rely on a redirect to carry your own navigation.

Step 5: Review canonical tags

The canonical tag names the preferred version of a page. Google's guide to consolidating duplicate URLs covers canonical tags, redirects, and sitemaps as the signals you can use.

• Self-referencing canonicals on normal pages are healthy.
• Canonical to a different URL should be deliberate. Check that the target returns 200 and is indexable.
• Canonical vs sitemap. The sitemap URL and the canonical should match.
• Google's choice vs yours. In URL Inspection, if the declared and Google-selected canonical differ, find out why. Usually it is duplicate content or conflicting signals.
• Parameters and pagination. Filtered and sorted URLs should resolve to one canonical page.

Step 6: Test speed and Core Web Vitals

Speed is a ranking input and a conversion input. Use real-user data first, lab data second.

1. Start with the Core Web Vitals report in Search Console. It groups URLs by field data, so you fix templates, not single pages.
2. Run PageSpeed Insights on one URL per template: home, service page, blog post, location page.
3. Read the three metrics: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness), and Cumulative Layout Shift (stability). Google explains them in Understanding Core Web Vitals and Google Search results.
4. Fix the usual causes: oversized hero images, unoptimized fonts, render-blocking scripts, heavy third-party tags, and missing image dimensions.

Treat this step as its own measurement. Pair it with the crawl, but verify speed with a speed tool.

Step 7: Validate structured data

Schema markup helps Google understand a page and can make it eligible for rich results. Start with Google's structured data introduction.

• Match the markup to the page. Do not mark up content users cannot see.
• Test with Google's Rich Results Test. Aim for zero errors and review warnings.
• Check required properties for each type, such as LocalBusiness, FAQPage, Article, and BreadcrumbList.
• Watch for broken JSON. A missing comma invalidates the block.

The Argus crawl flags pages with broken schema, so a site-wide pass finds the syntax errors before you test pages one by one.

Step 8: Audit internal links

Internal links decide how authority and crawl attention flow through your site.

• Orphan pages. Pages in the sitemap with no internal links pointing to them. Link them from a relevant page.
• Click depth. Money pages should be reachable within a few clicks from the home page.
• Broken links. Fix or remove links to 404 pages, internal and external.
• Anchor text. Use descriptive text, not "click here".
• Redirected links. Update links that go through a redirect.

Step 9: Run the on-page basics

Technical audits often include quick on-page checks because crawlers see them for free: missing or duplicate titles, missing H1s, thin pages, and missing meta descriptions.

ZeusSEO's Kronos module runs a free on-page audit. It discovers public pages from robots.txt and the sitemap, fetches them, detects on-page issues, and builds a prioritized monthly fix plan. It makes no paid API calls and uses no credits. Each fix is ranked critical, high, medium, or low, and marked auto-fixable or manual.

How to prioritize what you find

A first audit can return hundreds of issues. Do not fix them in the order the tool lists them. Rank them.

1. Blockers first. Anything that stops crawling or indexing of important pages: robots.txt blocks, accidental noindex, server errors, redirect loops.
2. Then pages that matter. A broken canonical on a service page outranks a missing alt tag on an old blog post.
3. Score by impact and effort. High impact and low effort goes to the top of the sprint. High effort with unclear impact goes to the backlog.
4. Fix by template. One change to a template can clear hundreds of flagged URLs.
5. Batch into monthly sprints. A short, dated plan gets done. A 300-row spreadsheet does not.
6. Re-crawl and compare. Confirm each fix, then check your baseline from the scoping step.

How often should you audit

Run a full audit when you take on a site, after any migration or redesign, and then quarterly. Check Search Console weekly for new indexing or Core Web Vitals warnings. Between audits, a scheduled crawl catches regressions early.

If you run this for several clients, a crawler that keeps results per site and a prioritized fix list saves hours. See how Argus crawls and monitors technical issues, or check pricing for the plan that fits your site count.