Site Audit Errors, Warnings & Notices: What to Fix First

Site Audit sorts issues into errors, warnings, and notices by severity, and the fix order matters more than the count. Fix crawl blockers and indexation first, polish later. HowToSemrush is an independent guide and is not affiliated with or endorsed by Semrush.

Key takeaways

Errors block or break things, warnings deserve attention, notices are minor observations — severity is a triage system, not a grade.
Fix in this order: crawl blockers → indexation → broken links and redirects → duplicates → speed and mobile → nice-to-haves.
The fix order is editorial judgment, not tool output — the audit lists issues; you decide what matters for your site.
Some findings aren’t problems. Intentional noindex pages and normal pagination quirks don’t need “fixing.”
Fix in batches and re-crawl — the audit is a loop, and each loop should confirm the last batch worked.

What the severity levels actually mean

Every finding in a Site Audit lands in one of three buckets. (New to the platform itself? Our plain-English guide to what Semrush is explains the toolkit these tutorials assume.) Understanding the buckets is half the triage battle:

Errors are the serious findings — issues that can prevent pages from being crawled or indexed, or that break the experience outright. A page returning a server error, a critical page blocked from crawlers, a broken redirect loop on an important URL: these belong here. Errors get fixed first, always.

Warnings are significant but not critical. A page with a missing meta description, a redirect chain three hops long, images without alt text — real issues worth scheduling, but your site functions with them in place. Warnings are the middle of the queue.

Notices are minor observations — small optimizations, informational flags, things that are technically suboptimal but harmless. A slightly long title tag, a minor markup quirk, an informational note about a page’s structure. Notices get attention last, and many never need action at all.

The key insight: severity describes the type of issue, not its importance to you. An error on a forgotten staging subdomain matters less than a warning on your homepage. The buckets sort the list; your judgment finishes the job. New to audits? Our walkthrough of running your first Semrush Site Audit covers setup and first reading.

The fix-first order

Here is the triage order, most to least urgent — editorial judgment based on how search engines work, not tool output:

1. Crawl blockers. Anything stopping crawlers from reaching your pages: server errors, DNS failures, robots.txt blocks on important sections, pages that time out. If crawlers can’t get in, nothing else matters. Fix these before you look at anything else.

2. Indexation problems. Pages crawlers reach but search engines won’t index: accidental noindex tags, canonical tags pointing at the wrong URL, important pages excluded by mistake. A page that can’t be indexed can’t rank, no matter how good it is.

3. Broken links and redirects. Internal links to dead pages, redirect chains (A → B → C → D), and loops. These waste crawl budget and leak internal link equity. Collapse chains to single hops; point dead ends somewhere real or remove them.

4. Duplicate content and duplicate metadata. Multiple pages with identical or near-identical content, and pages sharing the same titles and descriptions. Search engines have to pick which version to show; help them by consolidating or differentiating.

5. Speed and mobile. Slow pages and mobile rendering problems. Genuinely important — but they come after structural issues, because a fast page that can’t be indexed is still invisible.

6. Nice-to-haves. The polish layer — minor markup, slightly long titles. Worth doing in quiet weeks, never before the five layers above.

Work top-down. Don’t fix a single notice while an error sits unresolved — that’s the triage equivalent of polishing the windows while the roof leaks.

Common errors and what they mean

A few error types show up on nearly every audit. Here’s what they mean in plain terms. (Semrush updates its interface — if a label moved, search Semrush’s help center for the current name.)

4xx errors (page not found). The crawler followed a link to a nonexistent page — the classic 404. If the link is yours, fix it or restore/redirect the page; otherwise redirect to the closest real page.

5xx errors (server errors). The server failed to deliver the page. Unlike 404s, these suggest hosting or application trouble — and they need your host or developer fast, because crawlers that repeatedly hit server errors stop coming back as often.

Broken internal links. Links within your own site pointing to pages that return errors. These are entirely your responsibility and entirely fixable — update the link targets or set up proper redirects. A batch of broken internal links often traces to one removed section, so look for the pattern before fixing row by row.

Redirect chains and loops. A chain is redirects pointing at more redirects; a loop is redirects pointing at each other. Collapse chains so each old URL points directly at its final destination — loops break pages entirely and count as urgent.

Blocked important pages. Crawl blocks (via robots.txt or similar) on pages you actually want indexed — sometimes left over from development, sometimes from an overzealous plugin setting. Verify that what’s blocked matches what you intend to block.

Common warnings and notices

Warnings and notices are where most of the issue count lives. Common residents:

Missing or duplicate meta descriptions. Pages without descriptions, or many pages sharing one. Descriptions don’t directly determine rankings, but they shape what searchers see — duplicates make your results look sloppy, and missing ones let search engines improvise. Fix duplicates on important pages first.

Missing or duplicate title tags. More significant than descriptions — titles are a primary signal of what a page is about. Duplicates across many pages (common on e-commerce and large blogs) confuse the “which page is which” question. Give important pages unique, descriptive titles.

Thin content flags. Pages with very little text. Sometimes legitimate, sometimes a real problem. Judge each against its purpose — the flag is an observation, not a verdict.

Slow pages. Load-time findings, often naming the culprit (usually oversized images on content sites). Speed work is its own discipline; start with the biggest wins.

Images without alt text. Accessibility and understanding issue. Prioritize meaningful images (diagrams, product photos, infographics); decorative images matter less. This is classic batch work for a quiet afternoon.

Minor markup quirks. Multiple H1s, skipped heading levels, slightly long URLs. Real but low-impact — the polish layer. Address them when you’re in the page anyway, not as dedicated projects.

Notice the pattern: warnings and notices are dominated by page-level issues, while errors are dominated by site-level breakage. That matches the triage order — structure first, pages second, polish last.

When a “problem” isn’t one

Not every finding deserves a fix. Common false alarms:

Intentional noindex pages. Thank-you pages, internal search results, paginated archives, staging areas — pages you deliberately keep out of search results. The audit flags the noindex; you know it’s intentional. Verify intent, then ignore.

Pagination and faceted URLs. Sorting, filtering, and pagination create URL variations; some duplication here is structural and normal, handled by architecture decisions (canonical tags, parameter handling), not row-by-row cleanup.

Development and staging subdomains. If the crawl scope included a staging copy of the site, its findings describe a copy, not your live site. Exclude it from scope and re-crawl.

Third-party embeds and external links. Some findings point at things you don’t control — a slow third-party script, a broken link to someone else’s page. Fix what you can (replace the dead external link), accept what you can’t (the vendor’s slow script), and don’t burn hours on either.

The discipline: for each finding, ask “is this describing something I intended?” before asking “how do I fix this?” Intentional architecture is not a bug.

The fix-re-crawl loop

Triage produces a plan; the loop produces results:

Batch related fixes. Group by issue type or site section — all broken links in the blog, all duplicate titles in the shop. Batches are efficient and their results are readable.
Fix the batch. Do the actual work — update links, rewrite titles, collapse chains, fix the server issue.
Re-crawl. Run the audit again and compare: did the specific issues disappear? Did the error count drop? Did the Health Score move?
Log it. Date, what you fixed, before/after counts. This log becomes your evidence of progress and your memory of what worked.

Then take the next batch from the triage order. Once the technical layer is clean, page-level optimization is the natural next step — our On Page SEO Checker guide picks up where the audit leaves off, one page and one keyword at a time. Resist two temptations: fixing one issue and immediately re-crawling (wasteful), and fixing everything before re-crawling once (you lose the feedback on what worked). Batches keep the loop tight enough to learn from.

One honest note: fixing redirect chains often surfaces new findings — broken links hiding behind the redirects. That’s progress, not regression.

Mistakes to avoid

Treating the issue count as the goal. Dropping from 400 findings to 50 by fixing notices while errors sit untouched is motion, not progress. Severity order beats count reduction.

Fixing notices before errors. The classic triage inversion. Roof before windows: crawl blockers and indexation first, polish last.

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

“Fixing” intentional architecture. Noindexing a page the audit flagged, then removing the noindex to satisfy the report, can put junk pages into search results. The report describes; you decide.

Expecting rankings from technical fixes. Fixing errors removes obstacles — it doesn’t promise anything.

Frequently asked questions

What is the difference between an error, a warning, and a notice in Site Audit?
Errors are serious findings that can block crawling or indexing or break the experience — server errors, blocked important pages, redirect loops. Warnings are significant but not critical — missing meta descriptions, redirect chains, slow pages. Notices are minor observations and small optimizations. Always triage in severity order, but weigh each finding against the affected page’s importance. Severity describes the issue type, not its importance to you — an error on a staging subdomain matters less than a warning on your homepage.

Should I fix all errors before touching warnings?
In general, yes — that’s what the severity system is for. Crawl blockers and indexation errors outrank every warning. But apply judgment: an error on an unimportant staging subdomain matters less than a warning on your homepage. The triage order in this guide (crawl blockers → indexation → broken links/redirects → duplicates → speed/mobile → nice-to-haves) is the sensible default; adjust only when a specific page’s importance clearly overrides it.

Can I ignore notices completely?
Mostly, yes — especially on a first pass. Notices are the polish layer: minor markup quirks, slightly long titles, informational observations. Many describe intentional choices rather than problems. Revisit them in quiet weeks. Never let notice-fixing delay error-fixing. Notices are the polish layer: minor markup quirks, slightly long titles, informational flags. Address them when you’re already editing a page for other reasons, not as dedicated projects.

Will fixing site audit issues improve my rankings?
Fixing genuine technical problems removes obstacles — pages that couldn’t be crawled can now be found, broken internal links stop leaking equity. But no technical fix promises rankings or traffic. Think of the audit as necessary maintenance, not a ranking lever. Rankings depend on content, relevance, and competition too — be skeptical of anyone tying a specific technical fix to a specific position gain.

How do I know my fixes actually worked?
Re-crawl. Run the audit again after each batch of fixes and compare the results: the specific issues should disappear from the list, error counts should drop, and the Health Score should trend upward. Keep a simple log — date, what you fixed, before/after counts — so you have evidence rather than memory. If an issue persists after a fix, the fix didn’t take (a redirect pointing at the wrong place, a cached old version), and the re-crawl is how you catch that.

Your concrete next step

Open your latest Site Audit and sort the issue list by severity. Take the top error category — just one — and fix every instance of it this week. Re-crawl when done. One error category eliminated beats ten warnings half-addressed.

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.