Article · Technical audits

What to put in an SEO audit for a client, and what to leave out

A crawl export is raw material, not a deliverable. Turn crawl and Search Console data into a few pages the client can act on: a summary, ranked fixes, the evidence for each, who owns it, and what looks wrong but is fine. Includes a findings table you can copy.

Google details checked on 29 October 2026. Semrush details as listed on 29 October 2026.

What the client is actually buying

A client cannot act on hundreds of rows of crawler output. They can act on a short list: what is wrong, why it matters to the business, how much work it is, and who does it. That list is the audit; the crawl is how you found it. For selling it as a fixed-price product, see how to sell a fixed-price SEO audit online.

Google's page on hiring an SEO says an audit should include "an estimate of the work involved," and tells site owners to check a third-party tool's audit recommendations against Google's official guidance before making significant changes. So deliver findings you have confirmed, not everything a tool flagged. Open findings feed question 1 of the five-question report structure and the site health section of the outline.

The five parts of the deliverable

1. Summary in three lines

   The main problem, what is in good shape, and what you need from the client. Written for the owner.

2. Top fixes, ranked

   Five to ten findings, sorted by impact, then effort, so quick fixes to important pages come first.

3. Evidence

   The report behind each finding, the date you looked, and two or three example URLs the developer can check.

4. Owner and next step

   One person or role per finding and one concrete action. A finding without an owner has no one to fix it.

5. Not a problem

   What you checked and found fine, including statuses that look alarming but are expected.

Before you start: access and scope

Request Search Console access during onboarding. For an audit, Google advises site owners to grant only read access, not write access at that stage. A Restricted user is enough: it views most data, but URL Inspection is fetch-only and it cannot submit sitemaps or verify fixes. Ask for Full user, which can verify fixes, when implementation starts. Only an owner can add users, so the client sends the invite.

Agree in writing on the property, the sections in scope, and the money pages: the ones that bring in leads, calls or sales. They decide what counts as high impact. See setting up Search Console for client reporting.

The free route: what to check in Search Console

Google Search Essentials has three parts: technical requirements, spam policies, and key best practices. The technical requirements are short: Googlebot is not blocked, the page returns HTTP 200, and it has indexable content. Meeting them, Google adds, does not mean a page will be crawled, indexed or served. So check what is happening to the pages that matter, in this order:

1. Manual actions and Security issues. A green check mark means nothing to report. Anything listed goes first; both reports offer Request Review once every listed issue is fixed.
2. Page indexing. Only reasons that touch important pages. The All submitted pages filter shows how your sitemap URLs fare.
3. URL Inspection on each money page, as below.
4. Sitemaps. Success, Has errors, or Couldn't fetch. Only sitemaps submitted through the report or the API are listed.
5. Core Web Vitals. Poor and Need improvement groups, mobile and desktop separately.

Reading the Page indexing report

Google's stated goal is the canonical version of every important page indexed, not every URL. "Not indexed" is not necessarily bad; the reason tells you. Reasons that usually need a fix: Server error (5xx), Soft 404 (a "not found" page without a 404 code), Redirect error, and 401 or 403 on pages that should be public. Most others go on the not-a-problem list. For each reason in detail, see Page indexing statuses explained.

Two limits: the example list stops at 1,000 rows and may not show every affected URL, and validation typically takes up to about two weeks, sometimes much longer.

URL Inspection on the pages that matter

Inspect each money page, not a random sample. The indexed result comes from Google's last crawl: discovery, last crawl date, Crawl allowed?, Page fetch, Indexing allowed?, and the user-declared and Google-selected canonicals. Canonicals that differ on a money page are a finding.

Test live URL checks the page as it is now, but no test guarantees indexing, and it cannot predict canonical selection. Request indexing has a daily limit and no guarantee; for many changed URLs, Google points to a sitemap with updated <lastmod> dates. URL Inspection does not check manual actions or security issues, which is why those reports come first.

Core Web Vitals: field data, with gaps

Google recommends aiming for good Core Web Vitals. The Search Console report uses real-world data from the CrUX report, groups URLs with a similar experience, and gives each group the slowest status assigned to it, per device.

"No data available" means a new property or not enough CrUX data for that device: a gap, not a defect. For page-level tests the report points to PageSpeed Insights and Lighthouse. Name the tool behind each number. For a monthly status table and a developer ticket, see Core Web Vitals in a client report.

The findings table template

Copy this into a spreadsheet or the audit document. One row per confirmed finding.

Example only: a hypothetical dental practice in a fictional Springfield, with made-up URLs. Replace every row with findings confirmed on your own client's site.

Impact and effort scales

Define these once, above the table, so the client reads every row the same way.

• High: stops Google from crawling, indexing or showing a money page, or is a manual action or security issue.
• Medium: affects which version of an important page Google picks, how it performs for visitors, or a site-wide file such as the sitemap.
• Low: housekeeping on pages that bring in no leads or sales.
• Effort: S under an hour, M about half a day, L a day or more or someone else's budget.

Impact means risk to important pages, not a forecast. Do not translate it into traffic, leads or rankings; Google's hiring page says no one can guarantee a #1 ranking.

The "not a problem" list

A client who opens Search Console alone will see statuses that look alarming. Answer them in the audit.

What to leave out

• Raw issue counts. A warning total tells the client nothing and invites the question of why it is not zero.
• Tool scores without context. A crawler's health score is that tool's measure, not Google's.
• Unconfirmed crawler findings. Check each in Search Console or on the page.
• The raw export, and items that touch no important page. A separate file for the developer, or nowhere.
• Forecasts and jargon. No traffic or ranking numbers on fixes. Write "Google cannot read the sitemap", not "sitemap fetch failure".

When a crawler earns its place

Search Console shows what Google found, on Google's schedule, with capped example lists. A crawler runs when you choose and follows the internal links it can reach. On a small site where the examples show every affected URL, Search Console is enough. Add a crawler when any of these is true:

• You need every broken internal link or redirect, not a sample.
• An issue affects more URLs than the 1,000-row example list shows.
• You want scheduled crawls, so problems surface before the monthly report. See when a paid suite earns its place.

A crawler's bot is not Googlebot. A page it can reach is not proof that Google can, so confirm money pages with URL Inspection.

Semrush Site Audit, as listed on 29 October 2026

• Checks: more than 140 on-page and technical checks, per its help page, including duplicate content and broken links.
• Without an SEO Toolkit: 100 pages per month, 100 per audit, one audit at a time. Limits reset on the 1st of each month; unused pages do not roll over. Enough to learn the tool on a small site of your own.
• Paid allowances depend on the SEO Toolkit tier; Pro lists 100,000 pages per month and 20,000 per audit. The pricing page lists Site Audit in the "SEO" plan ($139 per month, or $117.33 per month billed annually, five websites to monitor) with no page number, so confirm the allowance in your account.
• Setup: General settings holds the scope, Limit per audit, Pages to crawl (Website, Robots.txt sitemap, Sitemap by URL, or Import URLs from file) and Schedule (Weekly on a day you pick, Daily, or Once, which stops automatic re-runs). Other wizard steps are optional; the default user agent is SiteAuditBot (Mobile), and JS rendering needs a Guru or Business SEO Toolkit. Later changes go through the gear, then Audit settings. Exports come as Excel, CSV or PDF.
• Slots: setting up Site Audit uses the project's one Website Monitoring slot, and the domain can then no longer be changed. A Site Audit campaign cannot be deleted alone: you delete the whole project, and its data cannot be restored.

A weekly crawl on a fixed day keeps the site health section of the monthly report current. For the wider costs, see the guide's cost section.

For the Site Audit setup step by step, see step 2 of the walkthrough. With one or two small sites, the free route may be enough.

A summary page you can copy

The first page of the deliverable. Edit the brackets and attach the findings table.

After delivery

1. To validate fixes yourself, ask the client to make you a Full user.
2. When a fix is live, run Test live URL on a few affected pages, then click Validate fix in the Page indexing report. Do not click it again until validation has passed or failed.
3. For Core Web Vitals, click Start Tracking. The issue counts as fixed only if it appears on no URL during the 28-day window.
4. Carry open findings, with status, into the "Visibility and site health" line of the monthly report email.

If a client links a later traffic drop to a fix, use how to explain a ranking drop and return to the agreed KPIs.

---

Sources

checked on 29 October 2026

• Three parts; no guarantee of crawling, indexing or serving: Google Search Essentials
• Googlebot access, HTTP 200, indexable content: Technical requirements
• Indexing goal, reasons, sitemap filter, 1,000-row limit, validation: Page indexing report
• Indexed result, Test live URL, Request indexing: URL Inspection tool
• CrUX data, groups, thresholds, No data available, Start Tracking: Core Web Vitals report
• Recommendation to aim for good Core Web Vitals: Core Web Vitals and Google Search
• Sitemap statuses and which sitemaps are listed: Sitemaps report
• When a site may not need a sitemap: Sitemaps overview
• Manual actions and Request Review: Manual actions report
• Security issues and Request Review: Security issues report
• Owner, Full user, Restricted user: Search Console users and permissions
• Read access, estimate of work, checking tool audits, no guaranteed #1 ranking: Do you need an SEO?
• Checks, page limits by tier, resets, exports, deleting a campaign: Semrush KB 31, Site Audit
• Wizard, crawl sources, schedule, user agent, JS rendering, settings gear: Semrush KB 539
• Schedule options and what Once does: Semrush KB 1108
• Website Monitoring slots and locked domains: Semrush KB 243
• "SEO" plan price, websites to monitor, Site Audit included (as listed on 29 October 2026): semrush.com/pricing/seo-ai-search