The Semalt Website Audit: Finding in 20 Minutes What a Manual Technical Review Misses in Two Days

There is a specific kind of meeting every SEO consultant has had. The client's developer opens a 900-row spreadsheet exported from an audit tool, scrolls through it slowly, and asks the only question that matters: "Which of these actually costs us money?" Most audit tools cannot answer that. They are very good at finding things and very bad at ranking them.

The audit inside the Semalt platform is built around that question rather than around completeness. This article walks through what it checks, how it decides what matters, and — the part most guides skip — how to turn its output into a development ticket sequence that a busy engineering team will actually complete.

What the audit actually is

Semalt's audit is not a one-off report you download. It is a scheduled crawl attached to a project, so each run produces a diff against the previous state. That distinction changes how you use it. A snapshot audit answers "what is wrong today". A continuous crawl answers "what broke this week", which is the question that actually prevents disasters.

The crawler renders JavaScript, follows internal links to a configurable depth, respects or deliberately ignores robots directives depending on how you configure the run, and pulls in external signals: Search Console data if you connect it, Core Web Vitals field data where available, and live SERP positions for the project's keyword set. The output is a single issue list where each entry knows how many URLs it affects and what those URLs are worth.

Setting up a run that produces useful data

Three settings determine whether the first crawl is useful or noise.

• Scope. On large sites, crawl a representative subset before crawling everything. A 5,000-URL sample across all templates finds the same template-level bugs as a 400,000-URL crawl, in a fraction of the time.
• Rendering. If your site builds its main content client-side, rendering must be on, or the crawl will report thin content everywhere and you will chase a problem that does not exist.
• Parameter handling. Faceted navigation can generate effectively infinite URLs. Decide up front which parameters to ignore, otherwise the crawl budget goes into colour filters.

Getting these right takes ten minutes and saves a day of misreading. If you are setting up your first project, open the dashboard, add the domain, and configure the crawl before running it rather than accepting defaults on a complex site.

All three figures come from the worked examples in this article.

Indexation: the errors that silently delete pages

The most valuable category, consistently. Indexation problems do not degrade performance gradually — they remove pages from search entirely, and because the pages still load fine for humans, nobody notices until traffic reporting catches it months later.

We cover this in detail in Semalt Analytics and Rank Tracking.

The audit flags the usual suspects: noindex tags left in place after a staging deploy, canonical tags pointing at the wrong URL, canonical chains, pages blocked in robots.txt that are also linked in the sitemap, redirect loops, and soft 404s where a "no results" page returns a 200.

Two of these deserve special attention because they are the ones we find most often in real audits. The first is the staging noindex: a template ships with the tag, the deploy pipeline does not strip it, and an entire section quietly leaves the index. The second is self-referencing canonicals gone wrong on paginated or filtered pages, where every page in a series canonicalises to page one, and the platform obligingly deletes the rest of the catalogue from search results.

See also: The New Semalt: One Platform That Runs Your Entire SEO Workflow.

Duplication and thin content at template level

Duplicate titles and descriptions are almost never a content-writing failure. They are a template failure. When 1,400 product pages share the title "Product | Shop", one line of template code caused it, and one line will fix it.

This is where Semalt's cause-based grouping earns its place. Instead of 1,400 rows, you get one issue with a URL pattern and a count. You hand the developer the pattern, not the spreadsheet. The same applies to thin pages: the audit clusters them by template so you can see instantly whether you have a content problem (individual pages nobody finished writing) or an architecture problem (a template generating hundreds of near-empty pages that should never have been indexable).

Core Web Vitals: separating lab noise from field reality

Speed reporting is where most audits mislead. A lab score from a single synthetic run tells you what one simulated device experienced once. Field data tells you what your actual users experienced over 28 days. They frequently disagree, and when they do, field data wins because it is the data that affects rankings.

The audit presents both and, more usefully, groups URLs by template so you can see that the problem is not "the site is slow" but "the category template has a Largest Contentful Paint problem on mobile". That is an actionable statement. "The site is slow" is not.

The practical advice we give clients: fix LCP first, because it is usually the failing metric and usually caused by something specific and fixable — an unoptimised hero image, a render-blocking font, a slow server response on uncached pages. Cumulative Layout Shift is second, and it is almost always ad slots or images without dimensions. Interaction latency is third and usually the hardest, because it means JavaScript, and JavaScript means a real engineering conversation.

Structured data and hreflang

Two checks that punch above their weight for multilingual and local businesses.

Structured data validation catches the errors that silently remove rich results: a Product schema missing a price, a LocalBusiness entry with an address that does not match the visible page, Review markup on a page with no visible reviews. Losing star ratings in the SERP costs click-through rate immediately and quietly.

Hreflang is the one that matters most on sites like the ones we run in Budapest, where Hungarian, English and German versions coexist. The rules are simple and almost universally broken: every language version must link to every other version including itself, the annotations must be reciprocal, and each version needs its own self-referencing canonical. The audit surfaces missing return links and versions that canonicalise across languages — an error that effectively tells search engines to ignore your entire translated site.

There is a full walkthrough in Competitor and Backlink Analysis with Semalt.

How to prioritise when the list is longer than the budget

Every audit produces more findings than anyone will fix. The skill is sequencing, and the sequence should follow business impact rather than issue severity labels.

Semalt's impact scoring approximates this automatically by weighting issues against each URL's traffic and position data, but the score cannot know which pages drive your revenue. Spend fifteen minutes tagging your commercial URLs as a group at project setup, and the prioritisation becomes considerably more accurate.

Turning findings into tickets developers will accept

This is where most SEO work dies. An audit finding is not a ticket. "Fix duplicate titles" will sit in a backlog forever. A ticket that gets done looks like this:

1. Where

   The exact template file or URL pattern — not a list of URLs pasted from an export.

2. What

   The current output and the desired output, written as a rule the developer can implement once.

3. Why

   One sentence of business consequence. Not an SEO lecture, and not a severity label.

4. How to verify

   The specific check that confirms it — here, the next scheduled crawl, which either drops the issue or does not.

That last point is the one the platform helps with most. Because the crawl is scheduled and diffed, a fixed issue disappears from the next run and appears in the change log as resolved. You are not asking the developer to trust you, and you are not manually re-checking 1,400 URLs. The system verifies the fix and tells both of you.

Five mistakes people make with audit tools

Treating the issue count as a score. Going from 400 issues to 40 means nothing if the 40 you left are the ones on your category pages. Weight, do not count.

Crawling with default settings on a JavaScript site. You will get a report claiming the site has no content. It has content. The crawler was not rendering.

Fixing what is easy instead of what matters. Alt text on 300 images is satisfying, visible progress. It is also, on most sites, worth close to nothing compared to a single canonical error on the category template.

Running the audit once. A one-time audit finds today's problems. Sites break continuously — deployments, plugin updates, CMS changes. The value is in the diff, not the snapshot.

Sending the raw export to the client. Nobody outside SEO can read it, and it makes your work look like a list of complaints rather than a plan. Send three prioritised items and what each is worth.

A repeatable monthly audit workflow

Here is the loop we run on retainers, which takes roughly ninety minutes per client per month once it is set up.

Open the crawl diff and read only what changed. New issues get triaged immediately; resolved issues get noted for the report. Anything new on a commercial template is investigated the same day, because new problems on money pages are almost always caused by a deployment, and deployments are easiest to reverse while everyone still remembers them.

Next, cross-reference against position data on the same timeline. If rankings dropped in the same window as a technical change, you have a hypothesis rather than a mystery. This single habit — reading technical changes and ranking changes on the same chart — catches more real problems than any individual check in the audit.

Finally, write the two or three tickets that are worth writing this month, and let the rest wait. An audit backlog that grows slowly and gets worked steadily beats a heroic quarterly cleanup that never happens.

What a crawl cannot tell you

Being clear about the boundary makes the tool more useful, not less. A crawler sees what a crawler can reach. It does not see what Googlebot actually chose to fetch, how often, or what it did with the response. That lives in server logs, and log analysis remains a separate discipline that no audit tool fully replaces. On sites under a few thousand URLs the difference rarely matters. On a large ecommerce catalogue where crawl budget is the binding constraint, the audit tells you what is wrong and the logs tell you whether Google ever looked.

A crawl also cannot judge content quality in the way a reader does. It can measure length, detect near-duplication and flag pages with no unique text, and those signals correlate usefully with problems. But a 2,000-word page that says nothing passes every automated check ever written. If your rankings are flat and the technical report is clean, the problem is very likely the thing the crawler is structurally unable to evaluate.

Finally, it cannot see intent mismatch. A page can be technically perfect, fast, well-marked-up and entirely wrong for the query it targets — a service page competing for a query where every ranking result is a comparison article. That diagnosis comes from looking at the SERP, which is why the audit is one input to a strategy rather than the strategy itself.

Verdict

Judged purely on the breadth of technical checks, Semalt's audit sits comfortably alongside the established crawlers without being dramatically different — most serious tools check the same things, because the things worth checking are well understood.

Where it separates itself is in what happens after the crawl: cause-based grouping instead of URL lists, impact weighting instead of flat severity, and continuous diffing instead of snapshots. Those three decisions turn an audit from a document into a process, and a process is what actually gets sites fixed.

If you want to test that claim cheaply, run it against a site whose problems you already know. Set up a project, configure the crawl properly, and check whether the first three items it prioritises match the three you would have picked yourself. That comparison is the only benchmark that matters.