Most technical SEO audits produce a long list of findings, then sit in a shared drive for six months while nothing gets deployed. Sometimes that gap is the client’s fault. More often, it is the audit’s. The findings were never validated, never ranked by anything a developer or product team can act on, and never traced back to a cause. The result is a document no one trusts and nothing ships from.<\/p>\n
These ten mistakes show up again and again in audit work, and each one has a clear fix. Skipping them is the difference between an audit that changes a site and an audit that wastes a quarter.<\/p>\n
Screaming Frog will show both versions of a page in a single crawl when JavaScript rendering is on and the tool is set to store both the original and rendered HTML. The comparison surfaces any body copy, internal links, canonical elements, or meta robots directives that exist in the rendered DOM but not in the initial HTML response. The diff is viewable side by side in the View Source tab.<\/p>\n
Google renders most pages without issue, but content that only appears after JavaScript runs is still less reliable. A blocked resource, a script error, or a timeout can leave it out of the index entirely. Most AI crawlers do not execute JavaScript at all, so a page can rank in Google and still be invisible to the systems generating AI answers. When a gap appears, confirm it with the URL Inspection tool in Search Console. That gives Google’s own view of the rendered page, which is harder for a developer to argue with than a screenshot from a third-party crawler.<\/p>\n
The Page indexing report sits under Indexing, then Pages. It is the only report where Google tells you directly whether a URL is indexed, crawled but not indexed, discovered but not indexed, a soft 404, or something else.<\/p>\n
Not every URL in the “Not indexed” bucket is a problem, which is where people go wrong with this report. Alternate page with proper canonical tag, excluded by noindex tag, and page with redirect are all normal outcomes of a site that is set up correctly. The exclusions worth investigating are the ones you did not expect, such as pages you want ranking that sit in Crawled, currently not indexed, or a Discovered, currently not indexed count that keeps climbing.<\/p>\n
Pull URLs by page type rather than at random, so the sample covers product pages, category pages, blog posts, filtered views, paginated series, and whatever else the site generates. Most technical issues worth reporting are template issues. Get the canonical rule wrong on a product template and you have broken it on all 40,000 product pages at once. A sample of three blog posts and a contact page will miss that and report something trivial instead.<\/p>\n
Sampling by template also makes the fix cheaper to scope. A developer can estimate “change the canonical logic on the PDP template” in about a minute. Nobody can estimate a list of 40,000 URLs.<\/p>\n
Every tool is blind to something. A crawling tool only finds what is linked or what you feed it, so orphaned pages stay invisible unless you supply them. Search Console tells you Google’s verdict but not the reason behind it. Analytics only records visits where the tracking code runs, so crawler activity mostly does not show up.<\/p>\n
Server logs are the only source that shows every request Googlebot or AI crawlers make to your server and what they get back. Rate limiting, intermittent 5xx errors, and crawl activity concentrated on URLs you do not care about only turn up here. Without server logs, the Crawl Stats report in Search Console is the next-best option. It is sampled data, but the crawl request breakdown still shows examples of URLs Google requested.<\/p>\n
Not every finding needs every source. Anything about to be handed to a development team should be confirmed in at least two places, and when two sources disagree, that disagreement is usually the more interesting finding.<\/p>\n
Crawlers report missing titles and H1s on pages where the content renders fine, and they log 429 and 503 status codes that the site only returned because the crawl was running too fast. Before a finding goes in the report, open the page and check it yourself. To confirm a status code, run a curl command.<\/p>\n
It takes a couple of minutes per finding, and it prevents a developer from spending half a day chasing a problem that was never there. Developers who have been sent after one phantom issue tend to read the rest of the document with suspicion.<\/p>\n
“The site has 12,000 duplicate URLs” is an observation, not a finding. The finding is whatever produces them, which might be faceted navigation without parameter handling, session IDs appended to URLs, or a CMS that generates a second copy of every page under a different path. A developer can delete the 12,000 URLs in an afternoon. They come back the next time someone adds a filter because nothing about the underlying behavior changed. Tracing a duplicate back to its source takes longer than exporting the list, and it is the part of the job a tool cannot do.<\/p>\n
A crawler assigns severity based on the type of issue. It has no idea which templates generate revenue, which categories the business is pushing next quarter, or which pages the sales team sends prospects to. The result is audits where low-value warnings sit at the top of the list and a rendering failure on the highest-margin product template sits on page four.<\/p>\n
Fixing this means asking the client questions the tool cannot answer. What are the priority products or services? Which pages convert? What is launching this year? Then rank validated findings against those answers instead of a severity column.<\/p>\n
Redirects, canonical changes, URL removals, and noindex directives all have second-order effects. A noindex on a filtered category eventually cuts off the internal links to the products underneath it. A batch of old URLs redirected to the homepage will often end up classified as soft 404s.<\/p>\n
Before recommending any of these, map what links to the pages in question and what they link to in turn. Check whether they appear in navigation, sitemaps, or breadcrumbs. The goal is to know whether the page is the only route to something else and whether the pages it links to have another way in.<\/p>\n
“Improve site speed” is not a recommendation. Neither is “fix canonicalization” nor “strengthen internal linking.” A usable recommendation includes the affected URLs or templates, the root cause, the expected outcome, and enough detail for someone to estimate the work. If a developer has to come back and ask what you actually want, the ticket goes to the bottom of the backlog and stays there.<\/p>\n
Compare “improve site speed” to something a developer can pick up: “The LCP element on the PDP template is a hero image loading through a lazy-load script, so it needs loading=lazy removed and fetchpriority=high added, with LCP under 2.5 seconds.”<\/p>\n
Write the outcome and the constraints. The canonical on paginated pages needs to be self-referencing. Primary product content must be included in the initial HTML response. Let the developer decide how. A suggested approach is fine, and on smaller sites the auditor may be right. The auditor usually does not know the framework’s limitations, what else depends on that component, or what the team already has planned for that part of the codebase.<\/p>\n
Acceptance criteria give a developer something to build against and something to check their work against when they are done. A prescription invites a debate about whether the auditor’s approach is the right one.<\/p>\n
A crawler produces a list of problems in ten minutes. Clients are paying for everything that happens after that, when someone checks which of those problems are real, determines which ones matter to the business, and assigns a cost to each fix. An audit that ships is the one where every finding has been opened in a browser, traced to a cause, ranked against revenue, and written as an outcome a developer can build against.<\/p>\n
Most audits ship a raw list of tool findings without validation, root-cause analysis, or business context. Developers and product teams receive documents they cannot act on, so the work sits in a backlog. Validation, prioritization by impact, and acceptance criteria turn an audit into something teams can actually deploy.<\/p>\n
Yes. Enabling JavaScript rendering in a crawler like Screaming Frog reveals content, links, canonicals, and meta robots that only appear in the rendered DOM. Comparing the original and rendered HTML shows what Google and AI crawlers actually see, and the URL Inspection tool in Search Console confirms how Google itself renders the page.<\/p>\n
Rank validated findings by business impact, not by tool-assigned severity. Ask which templates drive revenue, which pages convert, and what the business is launching soon, then order fixes against those answers. A high-severity warning on a soon-to-be-deleted template ranks below a moderate issue on the highest-margin product page.<\/p>\n