Technical SEO Checklist: Audit Your Site Step by Step

A technical SEO checklist lets you work systematically through the issues that can stop Google from finding, crawling and correctly understanding your site, no matter how good the content is. Technical problems are usually silent: traffic slides slowly and you notice the cause months later. The list below covers the core checks that apply at every scale, from a small blog to a large online store.

How to approach a technical audit

Work through the list in order of priority rather than all at once. First the issues that affect Google's access to the site (crawlability, indexing), then page experience (speed, mobile), and finally content signals (titles, structured data). Note the date after checking each item; a technical audit is a routine that should be repeated at least every three months.

1. Crawlability and indexing

robots.txt

• Confirm the file is reachable at the site root (yourdomain.com/robots.txt) and returns a 200.
• Make sure important directories or CSS/JS files are not blocked by accident; blocked resources lead Google to misread the page.
• Check for a leftover 'Disallow: /' line from a staging environment. That single line can drop the whole site from search.

XML sitemap

• It should contain only canonical URLs that return 200 and that you want indexed.
• Redirected, noindexed or 404 URLs should be removed from the sitemap.
• The sitemap should be referenced in robots.txt and submitted to Search Console.
• On large sites, split the sitemap by type (products, categories, blog) so problems are easier to isolate.

Noindex and indexing status

• Check that important pages carry no accidental noindex tag or X-Robots-Tag header.
• Review the 'Crawled, currently not indexed' and 'Discovered, currently not indexed' groups in Search Console's indexing report regularly.
• Make sure low-value URLs such as filters, internal search results and parameter pages are not bloating the index.

2. URL structure and duplicate content

Canonical tags

• Every indexable page should carry a canonical tag pointing to itself.
• The canonical URL should be full and absolute (including https) and must not redirect or 404.
• Parameter, sort and paginated versions should point to the main page.
• Only one of www / non-www and http / https should be used as the canonical.

hreflang (for multilingual sites)

• Each language version must list every other version and itself; hreflang pairs that are not reciprocal are ignored.
• Language and country codes must be written correctly (for example en-GB, en-US, de) and an x-default version should be defined.
• The URLs inside hreflang must match the canonical URLs.

3. Security and redirects

HTTPS

• All pages should be served over HTTPS; HTTP requests should 301 to HTTPS in a single hop.
• Pages should contain no mixed content such as images, scripts or iframes loaded over HTTP.
• Check the certificate's expiry date and whether it renews automatically.

Redirect chains and loops

• Chains like A → B → C should be collapsed to one hop (A → C); every extra hop hurts crawl budget and page speed.
• Loops where pages redirect to each other (A → B → A) must be removed entirely.
• Internal links should point directly to the final URL, not to old redirected ones.
• Make sure permanently moved pages use 301 rather than 302.

4. Speed and Core Web Vitals

Google weighs page experience among its ranking signals and expresses it through a set of measurements called Core Web Vitals. The three core metrics are:

• LCP (Largest Contentful Paint): how long the main content takes to appear. Large images and slow server responses are the most common causes.
• INP (Interaction to Next Paint): how quickly the page responds to user interactions. Heavy JavaScript is usually responsible.
• CLS (Cumulative Layout Shift): how much elements move around during loading. Images without dimensions and late-loading ads are typical causes.

The main things you can check to improve these metrics:

• Serve images in modern formats (WebP, AVIF) at appropriate sizes; lazy-load images that are off screen.
• Remove unused CSS and JavaScript, and defer non-critical scripts.
• Measure server response time; use caching and a CDN where needed.
• Give image and video elements explicit width and height values.

A Lighthouse report is lab data; read it together with real-user data (the Core Web Vitals report in Search Console). If the Lighthouse score is high but field data is poor, the problem usually lies in real users' devices and connections.

5. Mobile usability

• The page should fit a mobile screen without horizontal scrolling, and the viewport meta tag should be set.
• Tappable elements should not sit too close together, and text should be readable without zooming.
• Mobile and desktop versions should carry the same content and the same structured data; Google evaluates sites primarily through the mobile version.
• If content is hidden on mobile, remember that this can affect indexing.

6. Broken links and 404 pages

• Crawl regularly to confirm internal links do not point to pages returning 404 or 5xx.
• Check external links too; dead outbound links hurt the user experience.
• For deleted pages, either 301 to a relevant page or deliberately return 404/410. Avoid 'soft 404s' (no content but a 200 response).
• Design a custom 404 page: a search box, popular pages and the main menu keep the user on the site.
• Find URLs that earn backlinks but no longer exist and redirect them; otherwise the authority they earned is wasted.

To see which of your old URLs still receive links from other sites, use the backlink checker and prioritize the targets that return 404.

7. Titles and meta descriptions

• Every page should have a unique title tag; duplicate or empty titles are among the most frequent problems.
• Keep titles around 50 to 60 characters and meta descriptions around 150 to 160; anything beyond is cut off on the results page.
• Each page should have a single H1, and the heading hierarchy (H1 → H2 → H3) should make sense.
• Find and fix empty or duplicate meta descriptions in bulk.

For the details of writing titles and descriptions, see the meta title and description guide.

8. Structured data

• Use schema.org markup that fits the page type: Article, Product, FAQ, BreadcrumbList, Organization, LocalBusiness and so on.
• Prefer the JSON-LD format; it is easier to maintain and validate.
• Make sure the markup matches content that is actually visible on the page; markup for invisible content violates Google's guidelines.
• Check for errors regularly with Google's rich results test and the enhancement reports in Search Console.

9. Site architecture and internal linking

• Important pages should be reachable from the homepage in no more than three clicks.
• Find 'orphan' pages that receive no internal links and either link them or remove them.
• Use breadcrumb navigation; it explains the hierarchy to both users and Google.
• Use link text that describes the target page instead of 'click here'.

10. Pagination, parameters and crawl budget

On large sites, the number of pages Google crawls per visit is limited. Spending that budget on worthless URLs means important pages get discovered late or updates take longer to show up.

• Bring structures that generate endless URL combinations, such as sort, filter and session parameters, under control with canonicals, noindex or robots.txt.
• In paginated lists, each page should have its own canonical; pointing every page's canonical at page one prevents the content from being crawled.
• Look at server logs or the crawl stats in Search Console to see where Google spends its time.
• 5xx errors and very slow responses lower the crawl rate; monitor server health as part of technical SEO.

How to make the audit routine

Checking this whole list by hand takes hours even on a medium-sized site. A site audit tool reports crawlability, redirect, broken link, title and structured data problems in one pass and shows Lighthouse page speed metrics on the same screen. weranklab's technical site audit does this with prepaid credits and no monthly subscription, so you can start a new crawl after every major change or once a quarter. Reading audit results next to your ranking data makes it easier to see which technical problem is hurting which keyword; we explained how to watch rankings in the rank tracking guide.

Re-crawl after every fix. Creating a new problem while solving one (for example a redirect loop while fixing canonicals) happens more often than you would think.