Technical SEO audit: 10 mistakes that produce a botched recommendation

The scene is familiar to anyone who has ever delivered a technical SEO audit: the document has dozens of "findings," lands in a shared folder, and disappears for six months. Matt Hollingshead, a technical SEO consultant, argues in an article on Search Engine Land that the fault almost never lies with the client. It lies with the audit: findings never validated, prioritized by a tool's notion of severity, or written in a way no developer can execute.

For those working in growth and MarTech in Brazil, deciding channel budget and which consultancy to outsource technical SEO to, the piece is less a list of tips and more a criterion for telling a good deliverable apart from an expensive report that doesn't move the needle. The sentence that sums up the argument comes right at the opening:

Your crawler finds the symptom. Your audit needs to explain the cause, why it matters, and what should happen next.

-- Matt Hollingshead, Search Engine Land

Data-collection mistakes: the data you didn't even see

The first four mistakes are about method when pulling the data, and this is where the audit is already born crooked.

Running the crawl without executing JavaScript. In Screaming Frog, with JS rendering turned on and both the original and rendered HTML stored, you can compare the two versions side by side in the View Source tab. The point Hollingshead raises speaks directly to the GEO debate: Google renders most pages, but most AI crawlers do not execute JavaScript. In other words, a page can rank on Google and be invisible to the systems that generate AI answers. Content, internal links, or canonical tags that only exist in the rendered DOM are a discovery risk that a standard crawl won't show.

Ignoring Search Console's indexing report (Indexing > Pages). It's the only place where Google directly states whether a URL is indexed, crawled but not indexed, discovered but not indexed, or a soft 404. The common mistake is treating every "Not indexed" as a problem. Pages with a canonical pointing elsewhere, with noindex, or with a redirect are the normal result of a well-configured site. What deserves investigation is the unexpected: a page you want ranking stuck at "Crawled, currently not indexed," or a "Discovered, not indexed" count that only keeps growing.

Sampling URLs at random instead of by template. Here's perhaps the most practical insight for scale. Most technical problems worth reporting are template problems. Get the canonical rule wrong on the product template and you've broken 40,000 pages at once. If the sample has three blog posts and a contact page, the mistake slips through. Sampling by page type (product, category, post, filtered view, pagination) also lowers the cost of estimating the fix: a dev can estimate "change the canonical logic on the PDP template" in a minute; nobody estimates a list of 40,000 URLs.

Auditing from a single source. Every tool is blind to something. The crawler only finds what's linked (orphan pages disappear). Search Console gives you Google's verdict, but not the reason. Analytics only logs visits where the tracking code runs, so crawler activity barely shows up. Server logs are the only source that shows every request from Googlebot or AI crawlers and what they got back: rate limiting, intermittent 5xx errors, and crawl budget concentrated on URLs that don't matter only show up there. Without logs, Search Console's Crawl Stats report serves as a sampled substitute. The golden rule: any finding that goes to the dev team should be confirmed in at least two sources, and when two disagree, the disagreement is usually the most interesting finding.

Interpretation mistakes: mistaking tool output for diagnosis

Treating the tool's classification as fact. Crawlers report missing titles and H1s on pages that render just fine, and log 429s and 503s that the site only returned because the crawl was too fast. Before the finding goes into the report, open the page and check it. To confirm a status code, a curl does the job:

curl -I -A "Googlebot" https://exemplo.com.br/produto/123

It's two minutes per finding that saves the dev from losing half a day chasing a problem that never existed. And there's a credibility cost: as the author notes, a dev sent after a phantom problem starts reading the rest of the document with suspicion.

Documenting the symptom instead of the cause. "The site has 12,000 duplicate URLs" is an observation, not a finding. The finding is what produces them: faceted navigation without parameter handling, a session ID stuck to the URL, a CMS that generates a copy of every page. The dev wipes out the 12,000 in an afternoon, and they come back with the next filter added, because the underlying behavior didn't change. Tracing the duplicate back to its origin is exactly the part the tool doesn't do for you.

Prioritizing by the tool's severity instead of business impact. The crawler doesn't know which templates generate revenue, which category the company will push next quarter, or which pages the sales team sends prospects to. The result is audits with a mountain of low-value warnings up top and a rendering failure on the highest-margin product template buried on page four. The article's example is a great one: a batch of "Page Titles: Outside " flagged as high priority, when all those URLs come from a template the team is going to delete in the redesign. Prioritizing for real requires asking the client what the tool doesn't know: which products are the priority, which pages convert, what's launching this year.

Recommendation mistakes: where the audit does or doesn't turn into a deploy

The last three mistakes are about writing, and they're what decides whether the ticket turns into code.

| Bad recommendation | Actionable recommendation | |---|---| | "Improve site speed" | "The LCP element on the PDP template is a hero image loaded via lazy-load; remove loading="lazy" and add fetchpriority="high", with LCP under 2.5s" | | "Fix canonicalization" | Affected template + root cause + expected result + enough detail to estimate the effort |

Recommending a change without understanding the architecture. Redirects, canonicals, URL removal, and noindex have second-order effects. A noindex on a filtered category ends up cutting off internal links to the products beneath it. A batch of old URLs redirected to the homepage often turns into a soft 404. Before recommending, it's worth mapping what links to the page and what it links to, and whether it's the only route to something else.

Writing a recommendation the dev can't execute. "Improve speed" isn't a recommendation; "strengthen internal linking" isn't either. A usable recommendation includes affected URLs or templates, root cause, expected result, and enough detail to estimate the work. If the dev has to come back and ask what you want, the ticket goes to the bottom of the backlog and stays there.

Prescribing the implementation instead of the result. Write the result and the constraints ("the canonical on paginated pages needs to be self-referencing," "the main product content needs to be in the initial HTML") and let the dev decide the how. You don't know the framework's limitations, what else depends on that component, or what the team has already planned for that part of the code. An acceptance criterion gives something to build and check; a prescription only opens a debate over whether your approach is the right one. The author caveats: on smaller sites, suggesting an approach makes sense and you might be right.

Where this doesn't apply (and what remains open)

The method itself has a cost: validating across two sources, tracing root cause, and writing an acceptance criterion for every finding takes time. On a small site, with few templates and a dev who knows the codebase end to end, all that rigor can be overkill, and in that scenario prescribing the solution (mistake 10) is sometimes the faster path. The value of the audit scales with the site's complexity.

What the piece doesn't resolve, and where the Brazilian reader needs to do their own homework, is the GEO layer. Hollingshead points out that AI crawlers don't execute JS, but the technical audit still measures almost everything through Googlebot's eyes. Measuring visibility in generative search (whether the brand is cited in ChatGPT, in Gemini, in AI Overview) requires instrumentation that the classic audit doesn't cover. As the article sums it up: the crawler produces a list of problems in ten minutes. The client pays for everything that comes after, when someone checks which ones are real, decides which matter to the business, and puts a cost on each fix.