Technical SEO audit checklist: a step-by-step guide for small sites

A technical SEO (search engine optimization) audit answers four questions in order. Can search engines reach your pages? Are the right pages indexed? Do they load and render well on a phone? Can machines understand what is on them? Work through the ten steps below in sequence, because an early problem, such as a blocked folder or a stray noindex tag, makes the later checks meaningless.

This checklist is for small and mid-sized sites, as of November 2026. You need a verified Google Search Console property, PageSpeed Insights, and a crawler that exports every URL with its status code, canonical tag and inbound links. Skip crawl budget work. Google says its crawl budget guidance (opens in a new tab) is meant for very large or very fast-changing sites, and that a current sitemap plus regular checks of the Page indexing report is enough for everyone else.

Step 1: Confirm crawlers can reach the site

Open /robots.txt on every host you use, including subdomains. Google’s robots.txt setup guide (opens in a new tab) says the file must sit at the root of the host and applies only to that protocol, host and port, so each subdomain needs its own file.

Look for three things:

• Blanket blocks. A Disallow: / rule under User-agent: *, often left over from a staging site, stops every compliant crawler.
• Blocked resources. Google’s robots.txt introduction (opens in a new tab) advises against disallowing CSS or JavaScript files when pages are harder to understand without them.
• A sitemap line. A Sitemap: line with a full URL points crawlers to your sitemap.

A typical small-site file is short:

User-agent: *
Disallow: /cart/
Disallow: /internal-search/

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

Robots.txt manages crawling, not indexing. A disallowed URL can still appear in results, without a description, when other pages link to it. Confirm in Search Console’s robots.txt report that Google can fetch and parse the file.

Step 2: Check which pages are indexed

Open the Page indexing report in Search Console. The Page indexing report documentation (opens in a new tab) sets the goal as getting the canonical version of every important page indexed, not every URL. Each group of non-indexed URLs has a reason and a source. Issues whose source is the website are the ones you can usually fix.

Sort the reasons into two piles:

1. Expected: duplicates that point to the right canonical, thank-you pages you marked noindex, folders you blocked on purpose.
2. Mistakes: important pages that are marked noindex, blocked by robots.txt, returning server errors, caught in redirect errors or flagged as soft 404s.

Pay special attention to noindex. Google’s noindex documentation (opens in a new tab) explains that the rule can be a robots meta tag or an X-Robots-Tag response header, and that it only works when the page is crawlable. A page that is both disallowed in robots.txt and marked noindex can stay in the index, because the crawler never sees the tag.

<meta name="robots" content="noindex">

For a single page, the URL Inspection tool (opens in a new tab) shows the indexed version, the canonical Google selected, and a live test. Indexed data describes Google’s last visit. The live test describes the page now.

Step 3: Resolve duplicate URLs with canonicals

Google’s canonicalization guide (opens in a new tab) ranks the signals you control. Redirects and rel="canonical" annotations are strong signals, sitemap inclusion is a weak one, and they work better combined. They state a preference, so Google can still choose a different URL.

In your crawl export, check that:

• Every indexable page has a self-referencing canonical, written as an absolute URL inside the <head>.
• Canonical targets return 200 and are not redirected or marked noindex.
• HTTP redirects to HTTPS, and only one of the www and non-www hostnames resolves without a redirect.
• Internal links and sitemaps use the canonical URL.
• Neither robots.txt nor noindex is used to handle duplicates. The guide advises against both.

<link rel="canonical" href="https://www.example.com/services/seo-audit/">

Step 4: Audit status codes and redirects

Export the status code of every internal URL and compare it with Google’s status code documentation (opens in a new tab).

Status	How Google treats it	What to do
200	Content moves on to indexing, which is not guaranteed. Empty or error-like pages can be flagged as soft 404s.	Return 200 only for real pages
301 or 308	Followed. A strong signal that the target should become the canonical URL.	Use for permanent moves
302 or 307	Followed, but a weak signal. Treated as temporary, so the original URL tends to stay in results.	Use only for short-term moves
404 or 410	Content is ignored. Indexed URLs drop out over time.	Fine for removed pages; fix internal links to them
429 and 5xx	Crawling slows. URLs that keep failing are eventually dropped.	Treat as urgent; check hosting and logs

Next, review the redirects. The same documentation says Googlebot generally follows up to 10 hops. Our read: aim for one hop, because every extra hop slows visitors and adds a point of failure. Google’s redirect guide (opens in a new tab) recommends server-side redirects and treats JavaScript redirects as a last resort, since rendering can fail. Flag every chain, every loop, and every internal link that points at a redirected URL.

Step 5: Validate your XML sitemaps

Google’s sitemap guide (opens in a new tab) sets the ground rules. A single sitemap is limited to 50MB uncompressed or 50,000 URLs, must be UTF-8 encoded, and should list absolute URLs for the pages you want shown in search. Google ignores <priority> and <changefreq>, and uses <lastmod> only when the dates are consistently accurate. Submitting a sitemap is a hint, not a command.

Check that:

• Every listed URL returns 200, is the canonical version and is indexable.
• Each sitemap is submitted in the Sitemaps report without errors, or referenced in robots.txt.
• The sitemap and your crawl agree. A sitemap URL that the crawler never reached is probably an orphan, which step 9 covers.

Step 6: Measure Core Web Vitals

Core Web Vitals are three metrics measured on real visits. The thresholds below come from the PageSpeed Insights documentation (opens in a new tab).

Metric	Good	Needs improvement	Poor
Largest Contentful Paint (LCP): loading	2.5 s or less	Over 2.5 s, up to 4 s	Over 4 s
Interaction to Next Paint (INP): responsiveness	200 ms or less	Over 200 ms, up to 500 ms	Over 500 ms
Cumulative Layout Shift (CLS): visual stability	0.1 or less	Over 0.1, up to 0.25	Over 0.25

According to web.dev’s Web Vitals overview (opens in a new tab), a page passes when the 75th percentile of visits is in the good range for all three metrics, with mobile and desktop assessed separately.

Field data in PageSpeed Insights comes from the Chrome User Experience Report (CrUX) and covers the previous 28 days of real visits. Lab data comes from a simulated Lighthouse run. Use field data to decide whether there is a problem and lab data to debug it. Low-traffic pages may show only origin-level field data, or none.

In Search Console’s Core Web Vitals report, start with the templates that have the most failing URLs. Google recommends good Core Web Vitals (opens in a new tab) and says they line up with what its ranking systems try to reward. That is not a promise of a ranking gain, so treat this step as user experience work.

Step 7: Check mobile rendering

Google indexes and ranks from the mobile version of a page, crawled with its smartphone agent, according to its mobile-first indexing best practices (opens in a new tab). Responsive design is the recommended setup. If your mobile pages differ from desktop, they need the same primary content, headings, structured data, titles, descriptions and robots meta tags.

Run a live test in the URL Inspection tool on one URL per template and view the tested page. Check three things in the screenshot and the rendered HTML:

• The main content is present, not just a loading state.
• Navigation and in-content links appear in the HTML.
• Nothing important waits for a tap, swipe or keystroke. Google does not load content that depends on user interaction.

Step 8: Validate structured data

Google’s structured data introduction (opens in a new tab) recommends the JSON-LD format. Its general structured data guidelines (opens in a new tab) add the rules that matter in an audit: markup must describe content visitors can see, the page must not be blocked from Googlebot, and every required property must be present. Valid markup makes a page eligible for a rich result. It never guarantees one.

Test one URL per template in the Rich Results Test, then watch the rich result reports in Search Console. Confirm that each markup type still maps to a live feature. As of November 2026, Google’s documentation changelog (opens in a new tab) records that FAQ rich results stopped appearing in Google Search on May 7, 2026.

A minimal organization block for a home page looks like this. The property names come from the Schema.org Organization type (opens in a new tab), and Google’s organization markup guide (opens in a new tab) says none of them is required.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Company",
  "url": "https://www.example.com",
  "logo": "https://www.example.com/images/logo.png",
  "sameAs": ["https://example.org/profiles/example-company"]
}

Step 9: Review internal linking

Google’s link best practices (opens in a new tab) give you three testable rules. Google can generally crawl a link only when it is an <a> element with an href attribute. Anchor text should describe the destination. Every page you care about should be linked from at least one other page on your site.

Use your crawl export to find:

• Orphan pages: URLs in the sitemap with no inbound internal links.
• Links that only work through JavaScript click handlers, with no href.
• Generic anchor text, such as “read more”, on links to important pages.
• Internal links to URLs that redirect or return 404.

Step 10: Prioritize the fixes

Our read is to rank the findings in four tiers:

1. Blockers. Anything that stops important pages from being crawled or indexed: robots.txt blocks, stray noindex tags, server errors.
2. Conflicting signals. Wrong canonicals, redirect chains and loops, sitemaps that list non-canonical URLs.
3. Experience. Failing Core Web Vitals and mobile rendering gaps on the templates that carry the most traffic.
4. Enhancements. Structured data, anchor text and orphan pages.

Within a tier, rank each issue by how many URLs it affects, how much those pages matter to the business, and how much effort the fix takes. One template fix usually beats many page fixes. After a fix ships, use the validate option in the Page indexing report. Google says validation typically takes up to about two weeks and sometimes much longer.

Summary checklist

Area	What to check	Where to check
Crawl access	No blanket blocks; CSS and JavaScript allowed	robots.txt report
Indexing	Key pages indexed; every non-indexed reason reviewed	Page indexing report
Noindex	No stray tags; noindexed pages stay crawlable	Crawl export
Canonicals	Self-referencing, absolute, consistent	Crawl export, URL Inspection
Status codes	No 5xx errors or soft 404s	Crawl export
Redirects	One hop, permanent codes, no loops	Crawl export
Sitemaps	Canonical 200 URLs only; accurate lastmod	Sitemaps report
Core Web Vitals	LCP, INP and CLS good at the 75th percentile	PageSpeed Insights
Mobile	Same content as desktop in rendered HTML	URL Inspection live test
Structured data	Valid, visible on page, tied to a live feature	Rich Results Test
Internal links	<a href> links, clear anchors, no orphans	Crawl export

Frequently asked questions

How often should you run a technical SEO audit?

Our read: run the full checklist after any change that touches templates, URLs or hosting, such as a redesign, a migration or a new content management system. Between those events, review the Page indexing and Core Web Vitals reports every month.

Does blocking a page in robots.txt remove it from Google?

No. Robots.txt stops crawling, and a blocked URL can still be indexed from links alone. To remove a page, leave it crawlable and add a noindex rule, or put it behind a password.

Do good Core Web Vitals guarantee higher rankings?

No. Google recommends good Core Web Vitals and says its ranking systems try to reward a good page experience, but its documentation promises no specific ranking change. Fix slow or unstable templates because visitors notice them, and measure the effect on engagement and conversions as well as search traffic.