One of the less useful ways to judge the state of a website is by the number of issues that appear in a technical SEO audit.
This is not because those issues are necessarily wrong or unimportant. Crawling tools are extremely useful, and much of technical SEO would be considerably more difficult without them. The problem begins when the output of the crawl is treated as a ready-made list of work, with the size of the report becoming an indication of how unhealthy the website is.
If an audit returns 200 issues, for example, there may be a temptation to start with everything marked critical, work down through the warnings and eventually arrive at the smaller errors. In practice, I would want to know considerably more before deciding what should be fixed. I would want to know which pages are affected, whether those pages are supposed to appear in Search, whether the same issue is being repeated because of a single template or CMS rule, whether there is any evidence that the problem is affecting organic performance, and, perhaps most importantly, what we expect to change if it is fixed.
This distinction becomes important surprisingly quickly. An accidental noindex directive on an important service page may appear as a single affected URL in an audit, while a template problem might produce hundreds of warnings about metadata. The latter makes for a much larger number in a report, but I would almost certainly investigate the service page first.
The audit has found both problems correctly. It simply cannot make the entire prioritisation decision for you.
The number of affected URLs can be misleading
Technical SEO tools generally report what they find at URL level, which is useful when you are investigating individual pages but can give a distorted impression of the amount of work involved.
Suppose a crawl finds 500 broken internal links. There are circumstances in which that would represent hundreds of unrelated links that need attention, but it could just as easily be one faulty component that appears across a particular template. If every product page contains the same incorrectly generated category link, the useful diagnosis is not that the website has 500 broken links. It is that something in the product template is generating the wrong destination.
Canonical problems often work in much the same way. An audit may report incorrect canonicals across 2,000 product URLs, when the underlying cause is one rule in the CMS. Treating those URLs as 2,000 individual SEO tasks would not only create unnecessary work; it would obscure the thing that actually needs to be corrected.
This is why I usually want to group audit findings before I prioritise them. If several hundred errors share the same template, directory, URL pattern or technical cause, they may belong to the same investigation. Conversely, a problem affecting only a handful of URLs may deserve immediate attention if those URLs happen to be particularly important.
The count tells you the scale at which something has been detected. It does not necessarily tell you the scale of the underlying problem, and it certainly does not tell you its importance.
What is the issue actually preventing?
Once the findings have been put into some sort of context, I am more interested in what each problem changes about the way the site can participate in Search.
There is an obvious difference between a problem that prevents Google from accessing or indexing a page that should be searchable and one that makes an otherwise healthy page technically less tidy. That does not mean every crawl or indexation issue should automatically be placed at the top of an audit. It means that the consequence of the issue matters more than its label.
Take noindex. Finding a noindex directive on a website is not, by itself, evidence of a problem. Plenty of pages are intentionally kept out of Google’s index. The same directive appearing on a service page that the business expects customers to find through Search is a very different matter.
The same reasoning applies to robots directives, canonical tags, redirects and XML sitemaps. A redirect is not problematic merely because a crawler has reported one. A canonical pointing elsewhere may be entirely intentional. A URL omitted from a sitemap may not need to be there in the first place. Before deciding that any of these needs fixing, you have to understand what the affected page is for and what the website is trying to achieve with it.
This is also where I would stop relying exclusively on the crawl.
If the affected pages already receive impressions and clicks in Google Search Console, that tells me there is established Search visibility attached to them. If they generate enquiries or revenue, there is a business consequence to consider as well. If the problem occurs across a template that contains hundreds of pages the business is actively trying to grow, the potential impact is different again.
There will also be pages that do not yet receive meaningful organic traffic but remain important. A newly launched service page should not be considered low priority simply because it has no historical clicks. Existing performance is useful evidence, but it is not the same thing as strategic value.
The same technical issue can have a different priority on two different pages
This is one of the reasons generic severity scores have their limits.
Imagine that an audit finds two broken internal links. The first appears in a five-year-old blog post that receives almost no traffic and is rarely visited. The second is part of the navigation used by product pages to link to their parent categories.
Technically, the crawler has found the same class of error twice. From the point of view of prioritisation, however, the two cases are not especially similar. One may be a routine housekeeping task; the other may warrant an investigation into whether an important part of the site’s internal linking is failing more broadly.
This is where information from outside the audit becomes useful. Search Console can tell you whether affected pages have visibility and which queries they appear for. Analytics can help establish which pages contribute to the business. Backlink data may show that a URL has external authority worth preserving. Knowledge of the company’s priorities may tell you that an apparently insignificant section is about to become commercially important.
None of that information necessarily exists inside the crawling tool, which is why I would be cautious about allowing its severity classification to become the SEO roadmap.
Severity is evidence. It is not context.
Some warnings are perfectly legitimate and still not particularly urgent
A technical audit can also uncover things that are worth knowing about without necessarily deserving immediate action.
Meta descriptions are a simple example. If an audit finds 47 pages without one, I would not ignore the finding, but I would not assume that writing 47 descriptions is now one of the site’s most important SEO tasks either. A missing meta description does not prevent a page from being indexed or ranked, and Google may create a search-result snippet from the content of the page itself.
The useful question is whether those particular pages have enough Search opportunity to make improving their presentation worthwhile. If an important page is already receiving substantial impressions and its snippet is poor, working on the description may be sensible. If the same warning occurs across pages that have little Search value, it can probably wait while more consequential problems are addressed.
I think about performance findings in much the same way. Core Web Vitals matter, and poor performance can be a genuine problem for both Search and users, but there is a difference between improving a seriously underperforming commercial template and spending development time trying to move an already reasonable score closer to 100 because an audit tool has made the current number look unsatisfactory.
Google’s own guidance on page experience is useful here. It recommends good Core Web Vitals, but it also makes clear that achieving good scores does not guarantee top rankings and that pursuing a perfect score solely for SEO may not be the best use of time.
Technical SEO tends to become inefficient when passing the audit becomes the objective. The website does not need to satisfy a crawler for its own sake.
I would rather find the cause than clear the warning
Another reason to resist working directly from the issue list is that the thing reported by the crawler is not always the thing that needs to be fixed.
If 412 internal links are broken because a component is generating the wrong category URL, changing those links individually would treat the symptom while leaving the mechanism that created them untouched. The recommendation should explain the faulty component and the intended behaviour, because that is the information a developer needs in order to solve the problem properly.
The same principle applies to duplicated metadata, canonical inconsistencies, redirect patterns and many indexing problems. When something appears hundreds of times, I want to know why it appears hundreds of times before I decide what the work involves.
This also makes the audit more useful to people who have to act on it. “Fix 412 broken links” transfers a considerable amount of investigation to the developer. “The category-link component on the product template is generating URLs that no longer exist, which has created broken links across 412 product pages” gives them a much clearer starting point.
A good recommendation should therefore describe more than the error. It should explain where the behaviour occurs, what appears to be causing it, why it matters on this particular website and what the correct behaviour should be.
That requires more work during the audit, but it tends to save considerably more work afterwards.
Search Console can change the meaning of an audit finding
There is another reason I like to look at Search Console alongside crawl data: it can turn a technically plausible concern into something much more specific.
Suppose an audit identifies conflicting canonical signals across a group of pages. That warrants investigation. If Search Console also shows that those pages have lost impressions and Google is selecting different canonical URLs from the ones declared by the site, there is now more evidence connecting the technical finding with something happening in Search.
It is still important not to confuse correlation with proof, but the investigation has become much better informed.
The opposite is useful as well. You may find a technically untidy section of a site and discover that the URLs are intentionally excluded, have no strategic Search purpose and are behaving as expected. The issue can still be documented, but there may be little reason to interrupt more valuable work in order to resolve it.
This is why I find it difficult to separate technical SEO auditing from prioritisation. Finding an implementation problem is only part of the job. You also need enough evidence to decide whether it matters and enough understanding of the site to explain what should happen next. It’s the same reason I don’t think an AEO strategy should be treated as another checklist to add on top of SEO.
What should you actually do with 200 technical SEO issues?
I would not begin by trying to reduce 200 to zero.
I would first look for patterns. Which findings belong to the same template or technical cause? Which ones affect pages that should be visible in Search? Which ones touch parts of the site that already generate demand or are important to the business? Are any of the warnings simply describing intentional behaviour?
From there, I would investigate the issues that appear capable of interfering with something important. For some, that may mean checking crawl and indexation behaviour. For others, it may mean comparing the audit with Search Console, looking at rendered pages, tracing redirects or speaking to the development team about how a particular template works.
The resulting priority list will usually be much shorter than the original audit.
It may also contain decisions not to act. There is nothing inherently wrong with leaving a technically imperfect element alone when you understand why it exists, what effect it has and why other work is more important. An audit is supposed to help make those decisions, not remove the need for them.
If I were reviewing a technical SEO audit for a client, I would therefore be far less interested in whether the tool found 20 issues or 200 than in whether we can answer a few fairly ordinary questions about the important ones: what is happening, where is it happening, why does it matter here, what is causing it, and what do we expect to improve if we change it?
Once those questions have been answered, deciding what to fix first becomes considerably easier.
Need help figuring out which Technical SEO issues actually matter?
If you have an audit full of errors but no clear sense of what deserves attention first, I can help you work through the findings, identify the issues most likely to affect Search performance, and turn them into a practical order of priority.
Learn more about my Technical SEO consulting →