How to Run Your First Semrush Site Audit

A Site Audit crawls your website like a search engine does and reports technical issues in one dashboard. This tutorial walks through setup, the first crawl, and how to read the results without panicking.

How to Run Your First Semrush Site Audit

A Semrush Site Audit crawls your website the way a search engine does, then reports technical issues in a dashboard with a Health Score and issue counts by severity. Setup takes a few minutes: scope, limits, and schedule. HowToSemrush is an independent guide and is not affiliated with or endorsed by Semrush.

Key takeaways

  • Site Audit crawls your site like a search engine and reports technical issues — it finds problems; it doesn’t fix them for you.
  • Spend two minutes on setup — crawl scope, page limits, and schedule are the settings that shape everything the audit tells you.
  • The dashboard centers on a Health Score plus issue counts sorted by severity: errors, warnings, and notices.
  • A big issue count on a first audit is normal. Triage before you touch anything — the fix order is its own skill.
  • Re-crawl after fixes to confirm what actually changed; the audit is a loop, not a one-time event.

On this page

What Site Audit actually checks

Search engines discover your pages by crawling — following links from page to page, reading each one. Site Audit does the same thing to your site on demand, then checks every crawled page against a long list of technical checks: Are pages reachable? Do links work? Are titles and meta descriptions present? Are there redirect chains, duplicate content, slow pages, mobile problems?

Think of it as a building inspector for your website. It doesn’t judge your writing or your design taste; it checks the structure — the wiring and plumbing that search engines depend on. A beautiful page that search engines can’t reach is invisible, and invisibility is what most technical issues cause.

Two honest boundaries: the audit reports what it finds — fixing is your job — and not every flagged issue matters equally. A first audit can surface hundreds of findings, most of them minor. Severity sorting exists so you don’t treat them all the same.

Before the crawl: settings worth two minutes

When you configure a Site Audit, you set the rules of the crawl. Three settings deserve your attention:

Crawl scope. Which part of the site should be crawled? For most sites, the answer is the whole domain. Scope options exist for special cases — subdomains, specific folders — but a first audit should see everything. A partial crawl gives you partial answers.

Page limits. Crawls consume resources, and plans set limits on how many pages get crawled. For a small site this doesn’t matter — everything fits. For a large site, the limit determines how much of the site each crawl covers. Don’t guess at your plan’s current limits; check Semrush’s official pricing page at semrush.com/pricing for the numbers that apply to you, since limits change over time.

Schedule. You can run audits manually or on a recurring schedule. For a first audit, run it manually — you want to watch what happens. Once you’re in a fix-and-verify rhythm, a weekly or monthly scheduled crawl keeps the data fresh without you remembering to click.

Leave advanced settings at defaults for your first run — they’re sane, and exotic settings are for exotic problems you don’t have yet.

Running the audit, step by step

  1. Set up a Project first. Site Audit lives inside a Semrush Project tied to your domain. If you haven’t created one, our first-project setup guide walks through it — the audit assumes that foundation.
  2. Open Site Audit from the Project dashboard. You’ll find it among the project tools. (Semrush updates its interface — if a label moved, search Semrush’s help center for the current name.)
  3. Configure the crawl settings — scope, page limits, and schedule as described above. Keep everything else at defaults.
  4. Start the crawl. Depending on your site’s size, this takes minutes to a while. Large sites can take considerably longer; that’s normal.
  5. Wait for completion — a half-finished crawl shows partial data. Let it finish, then read the dashboard.

If the crawl fails or stalls, the usual suspects are site-level blocks: the site was down, a firewall blocked the crawler, or login requirements stopped it at the gate. Check that the site loads in a normal browser first, then look at the crawl settings for anything that would stop an unauthenticated visitor.

Reading the dashboard for the first time

The finished audit presents a dashboard built around a few core elements:

Health Score. A single-number summary of your site’s technical health as the audit sees it. Treat it as a trend indicator, not a grade — what matters is whether it rises as you fix things. No visitor sees it and no search engine uses it; it’s a management metric for you.

Issue counts by severity: errors, warnings, notices. Every finding is bucketed by severity. Errors are the serious ones — things that can block crawling or indexing. Warnings deserve attention but are less urgent. Notices are minor observations. The counts tell you where to look first, and the next article in this series — errors, warnings, and notices: what to fix first — is a full triage framework for exactly this.

Crawl stats. How many pages were crawled, how the crawl went, basic technical facts about the site. Useful context: if only 40 pages were crawled on a 400-page site, your settings — not your site — are the first thing to check.

The issue list. Each finding links to the affected pages, with explanations of what the issue means. This is where you’ll spend your fixing time. Don’t start there today — read the dashboard first, understand the shape of the problems, then triage.

The numbers always look worse than they are: a site that ranks well can show hundreds of warnings and notices. Let severity separate signal from noise before you react.

Abstract editorial illustration of a circular gauge with a needle pointing into a healthy zone, suggesting a website health score dashboard

What a first audit typically surfaces

Every site is different, but first audits rhyme. Here’s what commonly appears, in plain terms:

  • Broken internal links. Links pointing to pages that no longer exist. Common on any site that’s been edited over time — old posts link to removed pages.
  • Redirect chains and loops. Redirects pointing to other redirects (chains), or worse, to each other (loops). Usually leftovers from site restructures.
  • Missing or duplicate titles and meta descriptions. Pages without titles, or many pages sharing one title. Extremely common on large or old sites.
  • Thin or duplicate content flags. Pages with very little text, or pages substantially identical to other pages on the site.
  • Slow pages and mobile issues. Pages that load slowly or render poorly on mobile — increasingly worth attention as mobile traffic dominates.
  • Images without alt text, missing H1s, minor markup quirks. The long tail of small findings that fill out the warnings and notices columns.

None of this means your site is broken. It means your site is a real website that has been lived in. The audit’s job is to inventory the wear and tear; your job is to decide what to repair first.

Your first pass: look, don’t fix yet

Resist the urge to start fixing during your first read. A first audit deserves a full reading before any action, for three reasons.

First, patterns beat individual issues. Fifty broken links might trace back to one removed section — one fix, not fifty. Reading the whole list first reveals these clusters; fixing row by row hides them.

Second, severity needs context. An “error” on a page you deleted intentionally (and correctly redirect) is not the same as an “error” on your homepage. You can’t tell which is which until you’ve seen the landscape.

Third, some findings aren’t problems. Notices especially include observations that are fine as-is — intentional noindex pages, paginated archives behaving normally, development subdomains you meant to exclude. Fixing non-problems wastes the energy you need for real ones.

So: read the dashboard, note the big clusters, and stop. Triage is the next skill, with its own article. Channel fix-it energy into documenting — write down the three biggest issue categories and bring that list to the triage guide.

Re-crawling after fixes

An audit is a loop: crawl, triage, fix, re-crawl, confirm. The re-crawl is what closes the loop — without it, you’re guessing whether your fixes worked.

After a batch of fixes, run the audit again (manually, even if you set a schedule). Compare the new results against the old: did the error count drop? Did the specific issues you fixed disappear from the list? New issues appearing after fixes are normal too — fixing redirect chains, for example, can surface the broken links hiding behind them.

Fix in batches, re-crawl after each batch — not after every single fix, and not once after everything. Batches keep the feedback loop tight enough to learn which fixes move the numbers.

Keep a simple log — date, fixes, Health Score and error count before and after. Six months of this log is the story of your site getting healthier.

Mistakes to avoid

Panicking at the issue count. Hundreds of findings on a first audit is normal. Severity sorting exists so you don’t treat a missing alt tag like a blocked homepage.

Chasing a perfect Health Score. The score is a trend indicator for you, not a ranking factor. Fix real problems; don’t polish the metric.

Fixing before reading. Row-by-row fixing hides patterns. Read the whole report, find the clusters, then act on the clusters.

Re-crawling after every single fix. Crawl credits and time are finite. Batch your fixes, then re-crawl.

Auditing without a Project. Site Audit needs the project foundation first. Our dashboard tour explains where everything lives if the interface feels unfamiliar.

Ignoring crawl scope. If the crawl covered 40 pages of a 400-page site, the dashboard describes a tenth of your site. Check scope and limits before trusting the numbers.

Abstract editorial illustration of stacked geometric report cards with severity-colored edge tabs, suggesting an audit issue list

Frequently asked questions

How long does a Semrush Site Audit crawl take?
It depends on your site’s size and your plan’s crawl settings. A small site can finish in minutes; a large site can take considerably longer. Let the crawl complete before reading results — a half-finished crawl shows partial data that can mislead you. If a crawl stalls repeatedly, check the site was reachable and that no firewall or login blocks unauthenticated visitors.

What is a good Health Score?
There is no universal “good” number, and chasing one misses the point. The Health Score is a trend indicator for your own management — what matters is whether it rises as you fix real issues, not the absolute value. No visitor sees it and no search engine uses it. Rankings depend on far more than technical hygiene. Track the trend, fix real problems, ignore the vanity of the number.

Do I need to fix every issue the audit finds?
No. A first audit on an established site can surface hundreds of findings, and most are minor. That’s what severity levels are for: errors first, then warnings, then notices — and even then, some findings describe intentional choices (like noindexed pages) rather than problems. Our triage guide on errors, warnings, and notices gives you the full fix-first order so you spend energy where it counts.

Why does my audit show fewer pages than my site has?
Check your crawl scope and page limits first — the most common cause is settings, not site problems. Scope may be limited to part of the domain, or the page limit for the crawl may have been reached before the whole site was covered. Current plan limits change over time, so verify yours on semrush.com/pricing rather than guessing. Large sites may need the crawl split across runs.

How often should I run a Site Audit?
Run it manually while you’re actively fixing things — after each batch of fixes, re-crawl to confirm. Once the big issues are handled, a scheduled crawl (weekly for active sites, monthly for quiet ones) keeps the data fresh and catches new problems early: broken links from edited posts, new duplicate titles, pages that slowed down. The audit is a monitoring loop, not a one-time event.

Your concrete next step

Run your first audit today with default settings and a full-domain scope. Don’t fix anything. Read the dashboard, note the three biggest issue categories, and write down your Health Score and error count. Then open the triage guide and plan your first batch of fixes from a position of understanding, not panic.


HowToSemrush publishes independent educational guides about SEO tools. HowToSemrush is not affiliated with or endorsed by Semrush. Semrush updates its features and interface over time — verify current details on semrush.com before relying on them.