Most technical SEO audits fail the same way: two hundred issues sorted alphabetically, with a missing alt attribute sitting next to a noindex header on the entire product catalogue. That is a crawl dump, not an audit.
A useful audit answers three questions: can search engines reach the page, can they understand it, and does it deserve to outrank the pages already there? These checks are ordered by how often they are the actual cause of a ranking problem.
1. Crawlability of the pages that matter
Crawl your own site, not a random sample. Record the status code and noindex state of every URL, then compare that set against the pages you expect to rank.
The common failure is not that Google cannot crawl the site. It is that Google crawls thousands of parameterised URLs and never reaches product pages buried four clicks deep. A page linked only from a JavaScript menu that requires interaction is effectively unlinked.
Run the checks yourself
Paste your URL and get the audit, not a checklist.
Launchkit checks metadata, canonicals, structured data, and Lighthouse in one pass.
2. robots.txt is not a removal tool
Disallow stops crawling. It does not reliably stop indexing, because a blocked URL can still appear in results when other pages link to it. If a page must not appear in search, use noindex and allow the crawl so the directive is seen. Blocking CSS or JavaScript also breaks rendering, which makes every downstream check unreliable.
3. Canonicals point one way
Every indexable page should declare one canonical URL that returns 200, is the version you want in results, and matches the internal links pointing at it. A canonical that points to a redirect wastes the signal. A canonical that disagrees with the sitemap tells search engines two different things. Pick one and make links, sitemap, and canonical agree.
4. Sitemaps list only real, indexable pages
A sitemap is a hint, not a guarantee. Its value is discovery and freshness signalling, and that collapses when the file is full of 404s, redirects, and noindex pages. Generate it from the same source of truth as the pages, filtered to status 200 and indexable. Include lastmod only when content meaningfully changed; a field that updates on every deploy gets ignored.
5. Status codes are honest
A 301 is for permanent moves and passes most signal to the target. A 302 is temporary and should not persist for years. A 404 is correct for a page that never existed; a 410 is clearer for one deliberately removed.
Audit redirect chains. Each hop costs latency and can dilute signals. Collapse A → B → C into A → C and remove loops. Check that your custom 404 page returns 404, not a soft 200.
6. Core Web Vitals, with caveats
Core Web Vitals measure loading, interactivity, and visual stability.
| Metric | Good | Needs work | Poor |
|---|---|---|---|
| LCP (largest contentful paint) | ≤ 2.5s | 2.5s–4.0s | > 4.0s |
| INP (interaction to next paint) | ≤ 200ms | 200ms–500ms | > 500ms |
| CLS (cumulative layout shift) | ≤ 0.1 | 0.1–0.25 | > 0.25 |
These are field thresholds at the 75th percentile of real users. A lab score of 100 does not prove a page passes, and one slow run does not prove it fails. Fix the specific cause, such as an unoptimised hero image or a font that shifts the layout, rather than chasing the number.
7. Duplicate and missing metadata
Every indexable page needs a unique title and description. Duplicates are usually a template bug: the same title on every paginated page, or the site name repeated twice. Missing descriptions are less damaging but waste the chance to earn a click. Write titles for the query and descriptions for the click.
8. Internal linking with intent
Internal links tell search engines which pages matter and what they are about. The common problem is navigational boilerplate: every page links to the homepage, pricing, and blog, and nothing links to the deep comparison pages that need authority. Link from relevant body copy with descriptive anchor text.
9. Structured data that matches the page
Valid structured data is not a ranking factor by itself. It describes the page unambiguously and can qualify it for richer results. The failure mode is markup that claims something the visible page does not show, such as a rating that is not on the page. Validate it, keep the JSON-LD in sync, and use the most specific type that fits.
10. hreflang only when you have real locales
If the site serves the same content in multiple languages or regions, hreflang tells search engines which version to show. If it does not, hreflang is noise that creates conflicting signals. Each version should reference itself and every other version, and every URL must return 200. If the site is English-only, skip this section.
11. Mobile parity
Search engines index the mobile version of most sites. Anything missing on mobile, including links, content, and structured data, may as well be missing from the index. Check that the mobile DOM matches desktop, that tap targets are usable, and that nothing important hides behind a hover state.
12. Think in log files
Server logs show what search engines actually fetched, how often, and what they got back. They answer what a crawl cannot: are bots wasting time on faceted navigation, hitting the same page with dozens of parameters, or seeing the canonical version? A week of logs filtered to known bot user agents reveals the worst crawl waste.
13. Rendering and JavaScript
If the page needs JavaScript to show its main content, fetch the URL with JavaScript disabled and compare it to the rendered version. Missing titles, empty main content, or links that only exist after a click are all symptoms. Server-render or statically generate the content that needs to rank; use client rendering for interaction.
14. Orphaned and thin pages
An orphaned page has no internal links pointing to it. It may be in the sitemap, but it has no context and little chance of ranking. Find them by comparing the sitemap against the crawled link graph. Thin pages are the same problem from the other side: merge them, improve them, or remove them.
Prioritising the work
Not every finding deserves the same week. Use impact and effort to decide the order.
| Check | Typical impact | Effort | Do it when |
|---|---|---|---|
| Accidentally blocked or noindexed pages | Very high | Low | Always first |
| Broken canonicals and redirect chains | High | Low | Always first |
| Duplicate titles across templates | Medium | Low | Same sprint |
| Sitemap hygiene | Medium | Low | Same sprint |
| Internal links to money pages | High | Medium | Next sprint |
| Core Web Vitals on key templates | Medium | High | After indexing is clean |
| Structured data | Medium | Medium | When rich results apply |
| hreflang | High if multi-locale | High | Only with real locales |
Fix the cheap, high-impact things that control whether a page can rank at all, then spend the expensive effort on performance and content. A crawlable, canonical, internally linked site will benefit more from one good page than from a perfect Lighthouse score on a page nobody links to.
If you want the first pass done for you, run a free technical audit on a site you own. It checks the items above and shows the offending value, not just the rule name. For more on how scores are calculated, read our guide to the Lighthouse SEO score, and see the privacy policy for how submitted URLs are handled.