SEO Audit Checklist: What to Check, and in What Order

An SEO audit checklist is a fixed sequence of checks that tells you whether search engines can crawl, index and understand your pages, and what is stopping them. Run it in order: crawl access and indexing first, then status codes, canonicals and sitemaps, then titles, content, links, structured data and speed, because a page Google cannot index gains nothing from a better title.

Each check below says where to look, what a pass looks like, and which Google document backs it.

Key takeaways

• Run an SEO audit in order, crawl access and indexing first, because a page Google cannot index gains nothing from a better title.
• Google lists three technical requirements for indexing eligibility: Googlebot is not blocked, the page returns HTTP 200, and it has indexable content.
• Google treats a canonical tag as a hint, not a rule, and weighs it alongside redirects, HTTPS and sitemap inclusion, per its canonicalization overview.
• Google caps each XML sitemap file at 50,000 URLs or 50MB uncompressed and ignores priority and changefreq, per its sitemap build guide.

Before you start

Collect three things first: the URLs in your XML sitemap, the pages with search traffic in the Search Console Performance report, and access to the CMS or codebase. Comparing the first two shows pages you think matter that search ignores, and pages with traffic you forgot about.

Keep findings in one sheet with five columns: URL, check, problem, fix and owner. An audit that ends as a list of problems with no owner tends to stay a list of problems.

Check what Google already reports

Open the Page indexing report in Search Console first. It groups known URLs by status and gives the reason each unindexed page was left out, such as Server error (5xx), Soft 404, Redirect error, URL marked 'noindex' or Duplicate, Google chose different canonical than user, according to Google's Page indexing report help. Note which reasons cover pages you want indexed. Some, like Alternate page with proper canonical tag, mean the site is working as intended.

Then look at the Manual actions and Security issues reports. Either one can explain a sudden drop that no on-page fix will solve.

Can Googlebot reach the page?

Google lists three technical requirements for a page to be eligible for indexing: Googlebot isn't blocked, the page returns an HTTP 200 status, and the page has indexable content. The same technical requirements page states that meeting them does not guarantee indexing.

Check crawl access in this order:

• robots.txt. Open the robots.txt report in Search Console to see the file Google last fetched, its fetch status and any parse errors. The robots.txt report help also explains how to request a recrawl after a fix.
• Meta robots and X-Robots-Tag headers. Search templates for a stray noindex left over from staging. A URL blocked in robots.txt can still appear in results without its content, so Google's technical requirements point to noindex, with crawling allowed, as the way to keep a page out.
• Logins and firewalls. Pages behind authentication, or a CDN rule that challenges bots, appear as 401 or 403 blocks in the Page indexing report.

Do status codes and redirects behave?

Crawl the site and sort every URL by status code. Pages you want indexed should return 200, removed pages should return 404 or 410, and moved pages should redirect permanently. Google recommends permanent redirects such as 301 and 308 for moved URLs and keeping them for at least one year, per its site move guidance.

Look closely at redirect chains. Googlebot can follow up to 10 hops, but the same site move guidance advises redirecting straight to the final URL, or keeping chains ideally to no more than 3 and fewer than 5. Test the four versions of your home page (http, https, with and without www) and confirm each lands on one URL in a single hop. XeoRank's free redirect checker shows those variants hop by hop.

Is the canonical URL the one you want?

Every indexable page should carry a self-referencing canonical with an absolute URL, and duplicates should point to the main version. Google treats a canonical as a hint, not a rule, and weighs it alongside redirects, HTTPS and sitemap inclusion, as its canonicalization overview explains.

For each key template, run the URL Inspection tool and compare User-declared canonical with Google-selected canonical. When they differ, look for signals that disagree: a sitemap listing the non-canonical version, internal links to parameter URLs, or a canonical that points at a redirect. Google's guide to consolidating duplicate URLs asks you not to send different canonicals through different methods.

Does the sitemap list only pages you want indexed?

The XML sitemap should contain canonical, indexable URLs that return 200, and nothing else. Google requires fully qualified absolute URLs, caps each sitemap file at 50,000 URLs or 50MB uncompressed, uses lastmod only when it is consistently accurate, and ignores priority and changefreq, according to its sitemap build guide.

Submit the sitemap in Search Console, then filter the Page indexing report by that sitemap. Any gap between submitted and indexed URLs tells you where to look next: redirects, noindexed pages, duplicates and thin pages that should not be in the file.

Are titles, descriptions and headings doing their job?

Each page needs a unique, descriptive title and a meta description that summarizes it. Google sets no character limit on either but truncates both to fit the device width, and it can build the title link from the H1, og:title or anchor text when the title element is vague or repetitive, per its docs on title links and snippets.

Flag these patterns:

• Duplicate titles across a template, such as every product page titled with the store name alone
• Boilerplate titles that differ by a single word
• Missing or repeated meta descriptions
• Pages with no H1, or an H1 about a different topic than the title

The free meta tag checker pulls the title, description, canonical, robots tag, H1 and Open Graph tags for up to 10 URLs at a time, enough to sample each template.

Does the mobile version match the desktop version?

Google indexes and ranks the mobile version of a page, crawled with its smartphone agent. Its mobile-first indexing guide asks for the same content, structured data, robots meta tags, titles, descriptions, headings and image alt text on mobile as on desktop, and warns against lazy-loading primary content on user interaction.

At phone width, look for tabs that never load, desktop-only sections and structured data the mobile template drops.

Can Google see content rendered by JavaScript?

If the site uses a client-side framework, compare the raw HTML with the rendered page in the URL Inspection live test. Google queues pages for rendering after crawling, still calls server-side rendering or pre-rendering "a great idea," and only reliably finds links that are a elements with an href, according to its JavaScript SEO basics. Our breakdown of how JavaScript frameworks affect SEO covers the framework-specific fixes.

Does every important page get internal links?

Google's guidance here is short: "Every page you care about should have a link from at least one other page on your site," from its page on crawlable links. Compare your crawl with your sitemap to find orphan pages, then add links to them from related pages and hub pages.

The same page asks for descriptive, reasonably concise anchor text, so replace "click here" and "read more" with words that name the target page.

Is the content worth indexing?

Technical fixes get a page considered. Content decides whether it deserves to rank. Google's guide to helpful content asks whether a page provides original information or analysis, gives a substantial and complete description of its topic, and was created primarily for people rather than to manipulate rankings.

Mark pages that:

• Target the same query as another page on the site
• Reach the answer only after several paragraphs of preamble
• Carry outdated prices, dates or product details
• Repeat what is already on other sites with nothing added

Give each one a decision: improve it, merge it into a stronger page and redirect, or remove it.

Is the structured data valid and honest?

Run each key template through the Rich Results Test and check the rich result reports in Search Console. Markup must describe what is visible on the page, and Google states that it does not guarantee your structured data will show up in results, per its structured data guidelines.

Review markup that no longer earns a search feature. Google removed HowTo rich results in 2023, and FAQ rich results stopped appearing in Google Search on 7 May 2026, as the FAQPage documentation records. Google's AI features guidance also says no special schema is needed to appear in AI Overviews or AI Mode. For how classic SEO relates to answer engines, see AEO vs GEO vs SEO.

Do pages pass Core Web Vitals?

Open the Core Web Vitals report in Search Console. It uses field data from real Chrome users over the last 28 days and gives each URL group the status of its weakest metric, per Google's report help. The targets are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less at the 75th percentile, according to web.dev.

Keep this in proportion. Google says Core Web Vitals are used by its ranking systems, but also that it "always seeks to show the most relevant content, even if the page experience is sub-par," in its page experience documentation. Fix the failing templates that carry traffic, then move on.

The checklist at a glance

How often should you run an SEO audit?

Run the full checklist after any migration, redesign, CMS change or major plugin update. Those are the moments when canonicals, redirects and robots rules change without anyone noticing. Between full audits, the Page indexing and Core Web Vitals reports flag new problems as Google finds them, so make a habit of opening both whenever you check traffic.

The order matters more than the tool: fix access and indexing first, then the signals that tell Google which URL to show, then the page itself.