SEO audit checklist: the complete beginner's guide

How to use this page

Work through the checklist below in order — it's already sequenced from "can Google find your site at all" down to "how do you turn findings into a plan," which is roughly the order problems should get fixed in too. Mark each item Pass, Fail, or Unsure as you check it in the tool mentioned. Every question has a Read more link straight to its full explanation further down this same page, including what to check, which free tool to check it with, and how to fix it if it fails.

The scoring tool

22 questions, grouped the same way as the explanations below. Hover or tap the small iA quick plain-English definition of the term in that question. next to any question you don't recognise for a one-line definition — the full version is one click away via "Read more."

Does Google even know your site exists?

Before anything else on this list matters, Google has to be able to find your pages, crawl them, and decide to keep them in its index. This is the foundation everything else sits on — a perfectly optimised page that Google never indexes ranks for nothing.

1. Indexing & coverage

"Indexed" means Google has visited a page and added it to the index it serves search results from. A page can exist, load fine in a browser, and still not be indexed — which means it's invisible to every Google search, no matter how good it is.

What to check:

• In Google Search Console's Pages report, how many of your pages are indexed vs. not, and why the non-indexed ones are excluded.
• Search site:yourdomain.com in Google as a rough sanity check — far more or fewer results than expected is a signal worth investigating.
• Whether your most important pages specifically (homepage, main service/product pages, top blog posts) are indexed — check each one directly with Search Console's URL Inspection tool.

How to fix it: for pages excluded as "Crawled — currently not indexed," the usual cause is thin or low-value content — improve or merge those pages. For unwanted pages that are indexed (tag pages, test pages, thank-you pages), add a noindex tag — see the noindex vs. robots.txt guide for the exact order that actually removes a page, since doing it backwards can lock a page in rather than remove it.

2. robots.txt & XML sitemap

robots.txt is a plain text file at the root of your domain (yourdomain.com/robots.txt) that tells crawlers which parts of your site they're allowed to visit. Your XML sitemap is a list of your URLs that helps Google discover pages faster, especially on a larger site. Get either wrong and you can accidentally hide your entire site from Google.

What to check:

• robots.txt actually loads (returns a 200 status) and doesn't contain a blanket Disallow: / — the single most common post-launch accident, usually left over from a staging site.
• CSS and JavaScript files aren't blocked — Google needs to load them to render your pages properly.
• Your sitemap exists, is submitted in Search Console, and shows a "Success" status with no broken or redirecting URLs inside it.

How to fix it: remove any accidental Disallow rules, add a Sitemap: line pointing to your sitemap's URL inside robots.txt, regenerate a clean sitemap containing only indexable canonical URLs, and resubmit it in Search Console. Google's own documentation on how robots.txt works is the authoritative reference if you want the full spec.

3. HTTPS & site versions

It's easy to end up with a site that technically answers at four different addresses: http://yourdomain.com, https://yourdomain.com, http://www.yourdomain.com and https://www.yourdomain.com. Google treats these as separate URLs unless you redirect them together, which splits the ranking signal a single page should be getting.

What to check:

• A valid SSL certificate on every page, with no browser "not secure" warning.
• All four address versions redirect to one single preferred version, in one hop (not a chain).
• No "mixed content" — images, scripts or fonts still loading over plain http on an https page, which browsers flag and can break functionality.

How to fix it: force HTTPS and redirect every other version to your one preferred address with 301 redirects, fix any hardcoded http:// links in your own resources, and keep auto-renewal on for your SSL certificate so it never silently expires.

Is your site healthy to crawl?

Once Google can find your site, the next question is whether moving around it wastes its time or confuses it. Broken links, redirect chains and duplicate URLs don't just look messy — they burn the limited "crawl budget" Google allocates to your site and can bury the pages that actually matter.

4. Status codes & broken pages

Every URL returns a status code — 200 means "here's the page," 404 means "not found," 500 means "server error." Broken pages and the internal links pointing at them waste a visitor's click and Google's crawl budget on every pass.

What to check:

• 4xx errors (page not found) and whether anything on your own site still links to them.
• 5xx errors — these are server-side failures and should be treated as urgent, since they can drop pages from the index if frequent.
• "Soft 404s" — pages that return a 200 status but show an empty or error-like page to the visitor, which confuses crawlers about whether the page is real.
• Whether you have a real, helpful custom 404 page with working navigation, not a dead end.

How to fix it: fix or remove broken internal links, 301-redirect any old URL that still has backlinks or traffic to its closest living equivalent, and fix the server errors behind any 5xx responses with your host.

5. Redirects

A redirect sends a visitor (and a crawler) from one URL to another. Done once, it's harmless. Done as a chain — A redirects to B, which redirects to C — it adds load time on every hop and can leak the ranking value the original page had.

What to check:

• Redirect chains: A → B → C should be a single A → C hop instead.
• Permanent moves use a 301 status code, not a 302 (which signals "temporary" and can tell Google not to pass ranking value through).
• Redirect loops — pages that redirect back to themselves, which never resolve.
• Whether everything is mass-redirected to the homepage instead of the actual closest matching page, which is lazy and loses relevance.

How to fix it: collapse every redirect to one 301 hop straight to the final, relevant page, then update your internal links and sitemap to point directly at that final URL instead of the old one.

6. Canonicals & duplicate URLs

A canonical tag (<link rel="canonical">) tells Google which URL is the "real" one when the same or very similar content is reachable at more than one address — common with tracking parameters, print versions, or /page vs. /page/. Without it, Google has to guess, and it doesn't always guess the page you'd pick.

What to check:

• Every indexable page has a self-referencing canonical tag pointing to itself.
• Trailing-slash and case variants aren't creating accidental duplicates.
• Parameter duplicates (?sort=, ?ref=, UTM tracking links) all canonicalise back to the clean URL.
• In Search Console's URL Inspection tool, check whether "Google-selected canonical" actually matches the one you declared — sometimes it doesn't.

How to fix it: add correct, absolute (full-URL, not relative) canonical tags site-wide, and internally link to only one version of each URL so you're not working against your own canonical signal.

7. Site structure & internal links

Your internal links are how both visitors and Google decide which pages matter most on your site. A page buried five clicks deep with no internal links pointing to it — an "orphan page" — is genuinely hard for Google to find and rank, no matter how good its content is.

What to check:

• Click depth: can your important pages be reached within 2-3 clicks of the homepage?
• Orphan pages — any page with zero internal links pointing to it.
• Whether your most important ("money") pages get the most internal links, not an unrelated handful of old blog posts.
• Descriptive anchor text ("pricing for small teams," not "click here").

How to fix it: link to orphan pages from relevant existing content, add contextual links from blog posts to the services or products they relate to, and flatten overly deep folder structures where you can.

Does it work on a phone?

Google has used "mobile-first indexing" for years now — it ranks your site primarily using the mobile version, even for someone searching on a desktop. A site that only really works on desktop is working against the version Google actually judges it by.

8. Mobile-friendliness

What to check:

• Responsive layout — no sideways scrolling on any screen size.
• Readable text without zooming (roughly 16px body text as a starting point) and good colour contrast.
• Tap targets (buttons, links) spaced far enough apart that a thumb doesn't hit the wrong one.
• The same content on mobile as desktop — text, links and structured data shouldn't be hidden or stripped out on the smaller version.
• No full-screen pop-ups or interstitials that block the content right after a visitor arrives from search.

How to fix it: test on a real phone, not just a resized browser window. Fix layout issues, confirm mobile content genuinely matches desktop, enlarge small tap targets, and replace full-screen pop-ups with a smaller, dismissible banner.

Is it fast?

Speed is both a direct ranking factor (via Core Web Vitals) and an indirect one — a slow site loses visitors before Google ever gets the chance to rank it for anything.

9. Page speed & Core Web Vitals

Core Web Vitals are three specific, measurable signals Google uses as part of its page experience ranking signals: LCP (how fast the main content loads), INP (how quickly the page responds to a tap or click), and CLS (how much the layout jumps around while loading). The official "good" thresholds, per Google's own Core Web Vitals documentation, are LCP ≤2.5s, INP ≤200ms, and CLS ≤0.1.

What to check:

• Run your key pages through PageSpeed Insights and check the field data (real visitor data) in Search Console's Core Web Vitals report — this matters more than the lab score, which is a simulation.
• Server response time (TTFB) — slow hosting makes every other speed fix less effective. This is exactly the chain the hosting pillar guide covers.

How to fix it: better hosting, caching and a CDN address server response time; deferring non-critical JavaScript and removing unused plugins address INP; preloading the hero image and setting explicit width/height on media address LCP and CLS together.

10. Image optimisation

Images are usually the single heaviest part of a page. An unnecessarily large, uncompressed image is one of the most common — and most fixable — causes of a slow load.

What to check:

• Modern formats (WebP or AVIF) instead of large PNG/JPG where supported.
• Compression — most web images should sit well under 150KB.
• Images sized to their actual display dimensions, not a 4000px-wide photo squeezed into a 400px box.
• Lazy-loading on below-the-fold images only — never on the first, largest ("hero") image, since lazy-loading that one actually slows down LCP.
• Descriptive alt text and file names, which help both accessibility and image search.

How to fix it: convert and compress images, resize to the actual display size rather than relying on CSS to shrink an oversized file, lazy-load everything below the fold, and add width/height attributes plus alt text to every image.

Can Google understand your pages?

Being crawlable isn't the same as being understandable. These two checks are about whether Google (and AI systems) can actually parse what a page is and what it says, not just that it loads.

11. Structured data (schema)

Schema (via JSON-LD, the format Google recommends) is a standardised code format that labels your content for machines — "this is a Product," "this is a Recipe," "this is an Article by this Author." It doesn't guarantee a rich result in search, but it removes the guesswork and can unlock one where eligible.

What to check:

• Organization or LocalBusiness schema with your name, logo, address and hours.
• Page-level schema matching the content type — Article, Product, FAQPage, BreadcrumbList.
• No errors in Google's Rich Results Test or Search Console's Enhancements reports.
• The schema actually matches what's visibly on the page — marking up a price or rating that a visitor can't see is a policy violation, not just a technical mistake.

How to fix it: add JSON-LD schema for your business and key page types, fix any validation errors, and keep the details identical to what's shown elsewhere (like your Google Business Profile). See the valid JSON-LD, no rich result guide for why schema passing validation still doesn't guarantee the visual result you're expecting.

12. JavaScript & rendering

If your site is built with a JavaScript framework, the content might only appear after the script runs — and Google (along with most other crawlers) can miss or badly delay anything that only shows up that way.

What to check:

• In Search Console's URL Inspection tool, check the rendered HTML — is your actual content there, or just an empty shell?
• Titles and meta tags present after render, not just in a single-page app's initial empty shell.
• Real <a href="..."> links, not onclick-only navigation that a crawler can't follow.
• Important content isn't hidden behind a click or infinite scroll with no fallback.

How to fix it: use server-side or static rendering for key pages so the content exists in the initial HTML response, not only after client-side JavaScript runs. The two-wave indexing guide covers exactly how long a JavaScript-dependent page can sit waiting for Google's second rendering pass, and why that delay matters.

On-page basics

These are the fundamentals most people think of first when they hear "SEO" — and they genuinely matter, but only once everything above them is working. A beautifully optimised title tag on a page Google can't index does nothing.

13. Title tags & meta descriptions

The title tag is the blue link text in Google's results; the meta description is the snippet underneath it. Neither directly boosts ranking by itself, but together they decide whether someone who sees your result actually clicks it.

What to check:

• No missing or duplicate titles across pages — every page needs its own.
• Main keyword near the start of the title, not buried at the end.
• Reasonable length — titles around 50-60 characters, descriptions around 150-160, so Google doesn't truncate them.
• Pages with high impressions but a low click-through rate in Search Console's Performance report — these are often the best candidates to rewrite first.

How to fix it: rewrite for keyword + a real reason to click (a benefit, a number, a specific outcome), starting with the high-impression, low-CTR pages Search Console already points you to.

14. Headings & URL slugs

Headings (H1, H2, H3) outline a page for both readers skimming it and Google parsing its structure. A URL slug is the part after your domain — /blog/post-title — and short, readable ones add a small amount of context.

What to check:

• One clear H1 per page that actually describes the main topic.
• Logical heading order — H2s and H3s nested sensibly, not skipped levels used just to make text look bigger.
• Main keyword appearing naturally in the H1 and at least one H2, not stuffed in unnaturally.
• Short, lowercase, hyphenated URLs, not long strings of parameters or IDs.

How to fix it: fix any page with zero or multiple H1s, restructure headings to actually outline the page's content, and if you change a URL, 301-redirect the old one — never just let it 404.

15. Keywords & search intent

Search intent is what someone actually wants when they type a query — informational ("what is SEO"), commercial ("best SEO tools"), or transactional ("hire SEO consultant"). Matching the wrong intent is a common reason a well-written page still doesn't rank.

What to check:

• One main keyword mapped per page — plus close variations, not a completely separate topic.
• Keyword cannibalisation — two or more of your own pages competing for the same search term, which splits ranking signal between them instead of combining it.
• Whether your page's format matches what's actually ranking for that term (a service page for a "near me" search; a guide for a "what is" search).
• Missing pages — services or topics you offer that have no dedicated page at all.

How to fix it: map one keyword to one page, merge or 301 pages that are competing for the same query, and create pages for genuine gaps rather than trying to rank one page for everything.

Content & trust

This is the hardest item on this list to fake, and Google has said as much directly.

16. Content quality & E-E-A-T

E-E-A-T stands for Experience, Expertise, Authoritativeness, Trustworthiness — the framework Google's own search quality documentation uses to describe what "helpful content" means in practice. It isn't a single checkbox; it's a pattern across a whole site.

What to check:

• Thin pages — little genuinely useful information, often created just to target a keyword.
• Duplicate or copied text, including the same content repeated across near-identical city or service pages.
• Signals of real experience and expertise — author bios, real examples, case studies, first-hand detail that couldn't be copied from a search result.
• Outdated content — old prices, dead product references, stale dates nobody has revisited.
• Trust signals — accurate contact information, clear policies, visible authorship.

How to fix it: for each thin or outdated page, decide to keep-and-improve, update, merge (with a 301) or remove it. Add real author information, proof (examples, data, specifics), and FAQs that answer what people are actually asking — not filler questions invented to pad the page.

Beyond your own pages

A few things that matter for ranking live outside your own website entirely — what other sites say about you, how you show up locally, and whether you can even see what's working.

17. Backlink profile

A backlink is a link from another website to yours. Despite plenty of shortcuts promising otherwise, links from trusted, genuinely relevant sites remain one of the stronger ranking signals — and quality matters far more than raw quantity.

What to check:

• Referring domains — the number of unique sites linking to you, not total links (ten links from one site count far less than one link each from ten sites).
• Relevance — links from sites actually related to your industry or area carry more weight than random, unrelated ones.
• Anchor text mix — mostly your brand name or natural phrasing, not the exact same commercial keyword on every link, which can look manipulative.
• Lost or broken backlinks — links pointing at a page of yours that now 404s.
• Manual actions in Search Console related to unnatural links.

How to fix it: reclaim broken backlinks with a 301 redirect to the closest live page, earn new links through directories, partnerships, PR and genuinely useful content, and only disavow links tied to an actual manual action or ones you know you paid for improperly — not preemptively.

18. Google Business Profile & local

If you serve customers in a specific area, Google Business Profile (free, separate from your website) is what powers the map pack results — and for many local searches, it brings in more calls and visits than the website itself does.

What to check:

• Verified, correct primary category — the single most influential Google Business Profile setting.
• NAP consistency — your Name, Address and Phone number matching exactly across your site, your profile and any directories you're listed on.
• A complete profile — hours, services, description, photos.
• Citations — consistent listings on relevant directories for your region and industry.
• Reviews — count, average rating, and whether you're replying to them.

How to fix it: complete every field on your Google Business Profile, fix NAP inconsistencies wherever they appear, post updates regularly, and set up a simple, repeatable process for asking satisfied customers for a review.

19. Analytics & tracking

Everything above this point is a guess without tracking. You can't know what to prioritise, or whether a fix actually worked, if you can't see what's happening.

What to check:

• Search Console verified for the domain, with your sitemap submitted.
• Analytics (GA4 or equivalent) installed on every page, not just a handful.
• Analytics and Search Console linked together, so you can see search queries next to on-site behaviour.
• Key events (form submits, calls, WhatsApp clicks) actually tracked, not left as raw, unmarked traffic.
• A saved baseline — current rankings, clicks and leads — recorded before you start making changes, so you can tell later whether anything worked.

How to fix it: fix tracking before starting any other SEO work, mark your real conversion actions as key events, and save a dated baseline snapshot for comparison later.

AI & answer engines

This is the part most SEO checklists still leave out entirely, and it's a genuinely new category of visibility, separate from classic Google ranking. Tools like ChatGPT, Perplexity and Google's own AI Overviews answer questions directly, sometimes citing a source and sometimes not — and getting cited depends on different mechanics than getting ranked.

20. AI crawler access

The bots that feed AI answer engines are separate from Googlebot, with their own user-agent names (OAI-SearchBot, PerplexityBot, and others, depending on the provider). Your robots.txt can block them without you ever noticing, since they don't show up in a basic Google-focused audit.

What to check:

• Whether your robots.txt explicitly or accidentally blocks known AI crawler user-agents.
• Whether you've published an llms.txt file — an emerging, not-yet-universal convention some AI systems check for a curated summary of a site's content.
• Your server logs (if accessible) for whether these bots are actually visiting at all.

How to fix it: decide deliberately whether to allow or block each AI crawler (there's a real, debated tradeoff here, not an obvious right answer for every site), and if you want to be discoverable by them, make sure nothing in robots.txt is blocking them unintentionally. The llms.txt and AI citation study covers what publishing one actually seems to change, and what it doesn't.

21. Answer-engine readiness

Being crawlable by an AI system doesn't mean it will quote you. These tools tend to lift a short, self-contained passage that directly answers a question — not a paragraph that only makes sense after reading three paragraphs above it.

What to check:

• Whether your key pages have a direct, standalone answer near the top of the relevant section — not just eventually, buried in narrative.
• Whether your content makes specific, checkable claims (numbers, named tools, dated facts) rather than vague generalities, which are both more useful and more quotable.
• FAQ sections that answer real, specific questions, matched with FAQPage schema.

How to fix it: add a concise, direct answer (40-60 words works well) near the start of each major section, back claims with specifics instead of generic statements, and mark up genuine FAQs with schema. See the cited by AI answer engines guide for what was actually tested here, and what wasn't.

Pulling it together

An audit that ends at a list of problems isn't finished — it needs to become an order of operations.

22. Rankings & competitor gap

What to check:

• Your current positions for the keywords that actually matter to the business, not every keyword you happen to rank for.
• What competitor pages cover that yours doesn't, and vice versa.
• "Quick wins" — queries where you already rank positions 4-20 with decent impressions; these move faster than starting from nothing.
• A written, prioritised action plan: critical issues first, then medium, then low.

How to fix it: turn every finding above into a 30-60-90 day plan — fix critical technical issues in the first 30 days, on-page quick wins in the next 30, then content and link-building work after that. Working the list in a sensible order beats trying to fix all 22 points simultaneously.