Why a Generic Semrush PDF Isn’t a Site Audit
Published: March 17, 2026 · Last updated: April 7, 2026
Semrush is a great tool. The report it generates is not an audit. It’s a starting point, and a lot of consultants are selling the starting point as the finished product.
I say this as someone who runs Semrush on every site audit I do. The tool is fine. The problem is what happens next.
What the Semrush Site Audit report actually gives you
You get a crawl summary with a site health score, a ranked list of issues sorted by severity (Errors, Warnings, Notices), counts per issue, and a list of affected URLs for each issue. If you export the full PDF, you get 50 to 80 pages of findings, depending on site size, including per-page breakdowns in the back half of the report.
That is a genuinely useful artifact. It tells you what the crawler saw, where the issues live, and how severe Semrush thinks each one is. It gives you a starting list.
It does not give you context. It does not know what your business is, what your pages are supposed to do, or whether a flagged issue is an actual problem or a platform behavior that happens to score red in the tool’s logic. It does not prioritize by business impact, only by Semrush’s own severity tiering. It does not write recommendations in language your client can act on. It does not tell you which issues are cosmetic and which ones are costing you traffic.
That’s the work of an audit. The PDF is the raw material.
The 231 pages with low text-to-HTML ratio example
On a recent commercial photography audit, Semrush flagged 231 pages for low text-to-HTML ratio. In the tool, that finding is sorted into the “warnings” tier, which most clients read as “this is a problem I need to fix.”
It is not a problem. Text-to-HTML ratio is not a Google ranking factor. Google’s guidance on ranking systems doesn’t mention it, and neither do any of the documented core update signals. The reason it was flagged on that site is that the CMS generates verbose HTML with a lot of wrapper divs and inline styles. The pages were fine. The flag was platform noise.
If I had handed that client the raw Semrush PDF, they would have spent hours trying to fix something that didn’t need fixing and walked away feeling like the audit was useless. Instead, I documented the flag in my audit report, explained that it was a platform behavior and not a ranking issue, and moved on to things that actually mattered. That one paragraph of context is worth more than the entire page of raw Semrush output.
The canonical issues example
On the same audit, Semrush flagged 38 pages for canonical issues. Six of those were actual problems: genuine duplicate content, canonical tags pointing at the wrong URL, or pages that should have been canonicalized and weren’t.
The other 32 were gallery item pages, auto-generated by the CMS, correctly canonicalized to their parent pages, and working exactly as intended. The tool flagged them because the tool treats any “alternate page with proper canonical tag” status as something worth investigating. Google Search Console treats them as “working as intended.”
The audit report I wrote told the client: “You have 6 canonical issues to fix. The other 32 canonical tags are correct and doing their job. Do not touch them.”
Without that triage, a less experienced editor might have “fixed” the 32 that didn’t need fixing and broken the site’s indexing in the process.
The three things a real audit adds that Semrush can’t
- Context. Which flags are real problems, which are platform behaviors, which are cosmetic. This requires actually reading the report and knowing the platform, the client’s business, and how Google behaves.
- Prioritization by business impact. What should the client fix first because it’s costing traffic right now, and what can wait for month three of the engagement. Semrush sorts by severity tier. A real audit sorts by money.
- Written recommendations in business English. Not “resolve duplicate content issues on 38 URLs.” Instead: “Six of your product pages are duplicating content from the category pages. Here’s how to fix it, here’s what it should say, and here’s the priority order.”
A client should be able to read the audit and know exactly what to do next without needing to call me for a translation.
My honest take on the discount audit market
The reason clients think site audits are worthless is that most of the audits they’ve bought are PDF dumps. A consultant runs Semrush, exports the PDF, puts a cover page on it, and charges $300. (I’ve written before about the discount market that this work targets, and about why the cheap deliverable almost always fails the people it was supposed to help.) The client opens the file, sees 50 pages of technical findings with no explanation, and has no idea what to do with any of it. Two weeks later the audit is in a folder nobody opens.
The PDF dump is not the audit. The PDF dump is the raw material an actual audit gets built from. If your audit deliverable is a forwarded tool export with no narrative, no prioritization, and no business context, you did not do the work. You delivered the input.
Good audits are expensive because they take time. I read the entire tool export, cross-reference it against Google Search Console indexing data, investigate the flagged issues one by one, write a narrative report organized by priority, and include specific recommendations that a non-SEO person can act on. That’s hours of work. It is not a 30-minute task.
What a real audit should include at minimum
Here’s my short list. If your audit has all of these, it’s a real audit. If it’s missing half of them, it’s a PDF dump.
- A narrative summary that explains what’s healthy and what’s broken in plain language
- Priority tiers with business impact, not just tool severity
- Per-page or per-section specifics, not just site-wide counts
- Screenshots or code examples for the major findings
- A recommendations section that says what to do next, in what order
- Cross-reference with Google Search Console data, not just the Semrush crawl
- Platform-specific context (what’s fixable, what’s a platform limit)
- A clear 30, 60, 90-day plan
The GSC cross-reference that most audits skip
Here is a specific thing I do on every audit that changes the quality of the deliverable: I open Google Search Console for the site in parallel with Semrush, and I reconcile the two data sets before I write a single recommendation.
Semrush crawls the site the way it wants to, based on the sitemap and the links it finds. Google Search Console shows you what Google actually indexed, what it decided not to index, and why. Those are two different data sets, and the places they disagree are usually where the interesting findings live.
For example: Semrush might flag 38 canonical issues across the site. GSC might report that only 11 of the 65 known URLs are indexed. The overlap between those two data sets tells you which canonical issues are real problems and which are just Semrush seeing things Google has already consolidated. Without the cross-reference, you can’t tell. With it, you can cut the noise by half and focus your recommendations on the issues that are actually affecting what Google sees.
I also pull the GSC Performance data to find the pages that are getting impressions but no clicks, and the pages that used to get clicks and now don’t. That information rarely shows up in Semrush reports, and it is often the most actionable intelligence in the audit. (Related reading: how I think about keyword discovery when GSC is the primary source.)
How I structure the audit deliverable
If you’re a consultant trying to build a better audit product, or a client trying to know what to ask for, here’s the structure I use. It’s not the only correct structure, but it is one that has been working on my engagements for years.
A cover page and an executive summary in plain language. The client should be able to read the first page and know what the three biggest problems are, what the priority is, and what the timeline looks like.
A findings section organized by severity and type. Not a tool dump. A curated list of the issues that actually matter, each with a short explanation of what the issue is, why it matters, and what specifically is wrong on the client’s site.
A recommendations section that maps to the findings. Each recommendation says what to do, who should do it (client, developer, SEO consultant), and how long it should take.
A 30, 60, 90-day plan that sequences the recommendations into a rollout. This is the part clients actually use, and the part that separates a good audit from a great one.
An appendix with the tool exports for anyone who wants to dig into the raw data. This is where the Semrush PDF goes. In the back. Not at the front. As reference material, not as the deliverable itself.
The blind spot most consultants miss
The thing is, Semrush doesn’t read itself. If you don’t read all 76 pages of the export, you will miss the per-page findings that live in the back of the report. I have caught multiple audits (including some of my own, early on) that generalized from the first 40 pages and missed specific page-level issues that changed the recommendations entirely.
The tool is only as good as the person reading it. Read all of it.
I write about audit standards, deliverable templates, and the craft of writing a site audit that clients actually use from time to time on this blog. If you want the next piece when it goes up, subscribe to my low-volume email list. I send notes when there is something worth sending and not before.
If you have an existing “audit” in hand and aren’t sure whether it’s the real thing or a dressed-up tool export, send it over and I’ll tell you.
About the author
Victoria Temiz is the founder of Vita Digital, an independent SEO consultancy based in Minneapolis. She is certified in Digital Marketing and in Project Management from the University of St. Thomas, and holds an SEO credential from UC Davis Extension. She has been building and running her own websites since 2007 and has focused specifically on SEO and search since 2020. She is also a working jazz vocalist. More about her work.