Semrush Site Audit takes a couple of minutes to launch, and half an hour later you have a Site Health percentage and a list of several hundred issues. That is where the difficulties start: which settings you should have changed before the run, why the percentage is so easy to raise without fixing anything, and where to begin. This article is about this particular tool, from setup to the repeat crawl. The general order of technical checks, whichever tool you use, is in our technical audit checklist; here the subject is how to get that data out of Semrush.
What Site Audit does, and what it cannot see
Site Audit crawls your site with its own bot and checks the pages it finds. According to the Semrush knowledge base, the tool runs more than 140 technical and on-page checks, from broken links and duplicates to HTTPS and AMP (semrush.com/kb/31-site-audit, checked 27 September 2026).
It is worth being clear about the boundary. The crawler sees the site the way the Semrush bot sees it and knows nothing about what is happening in the search engines' indexes. How many pages are indexed, and why the rest were excluded, only Search Console and Yandex Webmaster can tell you. Semrush answers "what is broken on the site"; the webmaster consoles answer "which of it is hurting search", and decisions need both answers.
The second boundary concerns Yandex. The published list of Site Audit checks mentions neither Yandex nor its Clean-param directive for robots.txt (semrush.com/kb/542-site-audit-issues-list, checked 27 September 2026). Anything specific to that search engine has to be checked separately.
Setting up the project step by step
Semrush splits the audit settings across several screens. The order and names below come from the Configuring Site Audit guide (checked 27 September 2026).
Scope and page limit
The Scope field takes a domain, subdomain or folder. The page limit per audit is set in the same place. The limit depends on your plan, so for a large catalogue check it before the run: a crawl that hits the ceiling shows only part of the site, and conclusions drawn from it will be incomplete.
Crawl source
The options under Pages to crawl are the website itself (following links), the sitemap from robots.txt, a sitemap at a given URL, or a list of URLs from a file. For a first audit, crawling by links is better: it finds what internal linking really connects. A sitemap crawl is useful as a second run, more on that below.
User agent and crawl delay
By default Semrush crawls as the mobile SiteAuditBot. A desktop version and OpenAI-Search are also available. Mobile as the default is sensible, since indexing has long been mobile-first. The delay between requests can be set to minimum, one URL every two seconds, or whatever robots.txt specifies. On weak hosting, the minimum delay can produce a wave of 5xx errors that never appear under normal load.
Allowed and excluded sections, parameters
Allow and Disallow subfolders limit the crawl to the sections you need. In Parameters to ignore, enter straight away the parameters that do not change a page's content: UTM tags, session IDs, sorting parameters. Otherwise the audit will count thousands of duplicates, half of which exist only as far as the crawler is concerned.
Bypassing restrictions and scheduling
If the site is behind a password or bot protection, the restrictions section lets you upload a verification file, enter a login and password, or use a Web Bot Auth signature. The schedule can be weekly, daily or once.
Settings to change before the first run
The defaults suit a small site. For anything else, a few changes are worth making straight away.
- Enter the parameters to ignore. This is the most common reason for a bloated duplicates report.
- Check the page limit against the real size of the site. If the catalogue is bigger than the limit, restrict the crawl to one section and audit the site in parts.
- If the site relies heavily on JavaScript, check whether rendering is on. According to the Semrush knowledge base, JavaScript rendering is optional and not available on every plan.
- On a weak server, choose the robots.txt delay so the audit does not turn into a load test.
Orphan pages, the ones in the sitemap with no internal links pointing at them, Semrush finds by itself: the check list includes Orphaned pages (in sitemap). The reverse problem it handles less well. To see which working pages are missing from the sitemap, run two audits of the same site, one by links and one by sitemap, and compare the exports. URLs that turned up only in the link crawl are candidates either for adding to the sitemap or for closing from indexing.
How Site Health is calculated, and why not to trust it blindly
Site Health is the first thing you see in the overview, and it is usually what ends up in a report. According to Semrush (semrush.com/kb/114-total-score, checked 27 September 2026), the score is built from the number of errors and warnings on the crawled pages. Errors weigh more than warnings, and notices have the least effect.
Two details from the same article change how the percentage should be read.
First, fixing every issue of one type raises Site Health more than fixing two errors of different types. Clearing all broken links does more for the percentage than closing one issue in each of several categories.
Second, excluded checks stop counting towards the score on later crawls. So by hiding an awkward category you can raise Site Health without a single change to the site.
The lesson for client work: Site Health is a usable internal indicator of progress, provided the set of checks stays the same from crawl to crawl. It is no good as a contractor KPI, because settings control it. Put concrete numbers in the report instead: how many pages return an error, how many duplicates, how many orphans. Which numbers are worth showing a client at all is covered in our article on the monthly SEO report.
The overview and the thematic reports
According to the Semrush knowledge base (semrush.com/kb/540-site-audit-overview, checked 27 September 2026), the Overview screen brings together Site Health, the split between errors and warnings, widgets on visibility to AI search, and a Top issues block. Semrush defines Top issues as problems ordered by priority level and the number of pages affected. That is a good starting point for a first look, although the priority there is the same for every site and knows nothing about your business.
The thematic reports group checks by task. The same article lists Robots.txt, Crawlability, HTTPS, International SEO, Performance and Internal Linking. Three are the most useful in practice.
- Crawlability gathers whatever stops the bot reaching and understanding pages. It is a good place to start, because crawl problems cut pages off from search entirely.
- Internal Linking shows how well pages are linked to each other and flags the problem ones. This is usually where you find the reason some sections index poorly.
- International SEO checks hreflang. For sites with Russian and English versions, it is one of the most common sources of errors that are invisible to the eye.
The Issues report: making sense of hundreds of lines
Everything the audit found is collected in the Issues report across three tabs: Errors, Warnings and Notices. According to Semrush (semrush.com/kb/541-site-audit-issues-report, checked 27 September 2026), each issue comes with an explanation of how to fix it, and advanced filters narrow the report to a particular section of the site.
A working order that saves time:
- Filter the report by section first. An issue on two utility pages and the same issue across the whole catalogue carry very different weight, and the total hides that.
- Hide what you have consciously decided not to fix, but keep a note of what was hidden and why. Remember that hidden issues drop out of the Site Health calculation.
- Give developers one export per issue with its list of URLs. Semrush can send tasks to Trello; for other trackers, the export works.
What to fix first
The split into errors, warnings and notices reflects how serious an issue is in general. Priority for a particular site is worked out differently: how many pages are affected, and what those pages lose. It helps to sort the audit's findings along the same funnel a search engine follows to reach a page.
| Order | What to look for in Semrush reports |
|---|---|
| First | 5xx and 4xx errors on important pages, pages blocked in robots.txt or set to noindex by mistake, mass duplicates caused by parameters |
| Next | Redirect chains and loops, wrong canonicals, pages with no inbound internal links, hreflang errors |
| After that | Load speed and heavy resources, duplicate titles and descriptions |
| When you get round to it | Most notices: title length, missing alt text on decorative images |
To find things faster in the Issues report, it helps to know what the checks are called in the interface. For the first row they are Pages returning 5XX status code and Pages returning 4XX status code, Pages that were blocked from crawling, and Pages blocked by X-Robots-Tag: noindex HTTP header. For the second row: Redirect chains and loops, Pages with a broken canonical link, Pages with multiple canonical URLs, Orphaned pages (in sitemap), and the group of hreflang checks. The names are taken from the published Semrush check list (kb/542, checked 27 September 2026).
Before raising a task from the first row, check it against the webmaster consoles. If Semrush found pages with noindex and Yandex Webmaster shows they are not supposed to be indexed anyway, there is nothing to do. If Webmaster shows excluded pages that do not appear in the audit at all, the crawler never reached them, and the internal linking needs work. How the exclusion reasons differ between Yandex and Google is described in Yandex and Google.
Repeat crawls and checking the fixes
A single audit is a snapshot. It becomes useful from the second crawl, when you can see what was fixed and what has reappeared. Site Audit has Compare Crawls and Progress reports for this; the Semrush knowledge base lists them among the tool's standard reports.
Tie the schedule to the site's release cycle. A weekly crawl makes sense if developers ship changes every week. For a site that changes once a month, a daily crawl only creates noise and uses up the limit.
A useful habit is to run the audit by hand after every release rather than waiting for the schedule. Broken canonicals or a stray noindex on a template get caught the same day that way. On the schedule they would surface a week later, when pages were already starting to drop out of the index.
When Semrush alone is not enough
For most sites Site Audit covers crawling completely. There are three cases where you need something else.
A very large site. If there are more pages than your plan's limit, you will have to audit by section or use a separate desktop crawler.
Log analysis. Which pages the Yandex and Google bots visit is visible only in the server logs, and Semrush does not read them.
A Yandex project. Exclusion reasons and engine-specific directives have to be checked by hand in Yandex Webmaster.
If you are new to Semrush, start with our Semrush tutorial for beginners: it sets out a first week in which the audit comes on day six. Access to Semrush can be priced in the calculator on the homepage.
Frequently asked questions
How many checks does Semrush Site Audit run?
More than 140 technical and on-page checks, according to the Semrush knowledge base as of 27 September 2026. The full list of checks is published in the same knowledge base.
Can Semrush audit a password-protected site?
Yes. In the settings for bypassing restrictions you can upload a verification file, enter a login and password, or use a Web Bot Auth signature.
Why did Site Health go up when nothing on the site changed?
Most likely the set of checks changed: hidden or excluded checks are not counted. Another possibility is a different page limit or a different crawl source.
Does Semrush check Yandex's requirements?
Yandex is not mentioned in the published list of checks. Yandex-specific directives and index exclusion reasons have to be looked up in Yandex Webmaster.
How often should you run the audit?
As often as changes go out to the site, plus a manual run after every major release. The Semrush schedule offers daily, weekly and one-off runs, so for a site that barely changes, a weekly crawl or a manual run once a month is enough.