Your Website Audit Found 700 Problems. Here Is What to Fix First.

By Frank Alfano, LL.B., LL.M.

Every site audit ends the same way. A tool hands you a spreadsheet, the spreadsheet has hundreds of rows, and every row is coloured red. Missing meta descriptions. Redirect chains. Images without alt text. Pages eleven clicks from the homepage. Schema that does not validate. The report is accurate and the report is useless, because it tells you everything that is wrong and nothing about what to do on Monday morning.

Backlinko published a short video on exactly this problem, The #1 Skill That Separates Expert SEOs from Everyone Else. The host is Erika Braeger, Manager of Organic Growth Strategy at Ten Speed. Her answer is one word: triage. Not tooling, not coding, not a decade of experience. The ability to sort a pile of problems into the order they should be solved.

She is right, and I want to add the part that matters to a solo practice rather than an in-house SEO team with developers on staff.

I did this for thirty-three years before I did it for websites

For more than three decades I ran a paralegal practice in Ontario courtrooms. A file would land on my desk with four hundred pages of disclosure, one hearing date, and a client who could not afford unlimited hours. Nothing about that job was about knowing more law than the other side. It was about deciding, quickly, which three issues were going to decide the case and which forty were going to eat a week and change nothing.

That is triage. Emergency rooms do it. Courtrooms do it. Anyone with more problems than hours does it, whether they have a name for it or not.

A website audit is the same document in different clothing. Seven hundred issues, one budget, one person with a real job to do. The audit is not the work. The order is the work.

The 90-second test almost everyone fails

The video runs a quiz. You have a list of audit findings and ninety seconds to pick what you would fix first. Most people pick wrong, and they pick wrong in a predictable way: they choose whatever is easiest to understand.

The three findings that should have gone first in her example were all about whether search engines can see your site at all:

• A static sitemap. Someone has to remember to update it every single time a page is published, and eventually nobody does. Switching to a dynamic sitemap is a one-time job that keeps working forever.
• Broken pagination. If crawlers and users cannot get past page one of your resource section, everything behind page one may as well not exist.
• Canonical tag conflicts. When several URLs claim to be the original, the search engine picks one and you do not get a vote. Clean canonicals settle the argument in your favour.

None of those are glamorous and none of them show up on a homepage. They are foundational to indexation and visibility, and I will not push them down a list for anything. There is no point optimizing a page that is never going to be indexed. I wrote about the whole category in what a technical SEO audit actually looks for, and about the diagnosis end in why your website isn't showing up on Google.

Build one overview tab and stop opening five reports

The first practical move in the video is the one I would give anyone: build an overview tab.

An audit pulls from several places. PageSpeed Insights for speed. Screaming Frog for the crawl. Google Search Console for what Google actually thinks. Analytics for what people actually did. Each tool exports its own tab in its own format, and if you leave them that way you will spend every session re-reading reports instead of fixing anything.

One tab. Every issue in it. That tab is the job.

Log by issue type, not by URL

This is the detail that turns 700 rows into 40. If you have 300 broken links, do not write 300 lines. Write one line that says "404s on internal links, volume 300, mostly in the old blog category pages." One decision covers all 300. You are not tracking URLs, you are tracking decisions.

The number itself matters, though. Keep the volume in the row, because volume is half of impact.

What every row needs

Five columns, and the fifth is the one people skip:

• What is the problem, in plain language, not the tool's error code.
• What it costs you in traffic, rankings or conversions if it stays broken.
• How long it takes to fix, honestly, in hours or sprints.
• How hard it is, which is not the same as how long it takes.
• Who has to do it. You, a developer, a writer, or whoever controls the product pages.

Ownership is not bureaucracy. It is the difference between a plan and a wish. A developer has a sprint cycle. A writer has a queue. If eleven of your top twenty items all need the same developer, you do not have a twenty-item plan, you have a two-month queue and seven things you could have done yourself this week.

Score by combination, because high impact does not mean first

Here is the line from the video worth writing on a wall: high impact does not automatically mean do it first.

A high impact fix that needs three months of developer time does not jump ahead of a medium impact fix you can finish on Thursday. Rank on the combination, not on impact alone.

• High impact, low effort. Top of the list, every time, no discussion.
• High impact, high effort. It matters and it waits its turn. Start the conversation with whoever has to build it now, so the queue is moving while you do other work.
• Medium impact, low effort. Still worth doing, still gets done, usually while you are waiting on something bigger.
• Low impact, high effort. The bottom of the list, possibly forever. That is a legitimate answer.

You are not avoiding the hard work. You are sequencing it. Doing the fast, valuable things first buys you two things: results you can point at, and the credibility to ask for the expensive fix later.

Where the quick wins actually hide

Five places, in the order I check them.

Page speed

Google indexes the mobile version of your site first. If a phone cannot parse your pages quickly, nothing downstream helps. Most speed fixes are developer tickets, but they are small, scoped tickets: defer a third-party script, compress the hero image, drop the font you are not using. That is an afternoon, not a rebuild.

Crawl depth

Count the clicks from your homepage to your most valuable page. If the answer is more than three, that page is being treated as an afterthought by the crawler and by your visitors. The fix is internal linking, not code. You can do it yourself, this week, for free. It is the single most underused lever in on-page SEO.

Content decay

Old content quietly drags. Large language models favour freshness and so do readers, who check the date before they check the argument. The video's rule of thumb is to flag anything older than eighteen months for a refresh or a cut. That is a writer's task, not a developer's, which is exactly why it usually gets done fast. I laid out the method in content refresh and pruning, and the structuring work that makes an older piece quotable by AI answers is in how to get cited by ChatGPT.

Crawl errors

Redirect chains and 404s accumulate the way clutter does, one at a time and unnoticed. Clean the ones sitting on your most important pages first. A 404 on a page nobody visits is a rounding error. A redirect chain on your main service page is money.

Schema

Last, and only once the site is fast and crawlable. Structured data makes an already-readable site easier to read. The type has to match the page, though. Marking a service page up as an Article, or a blog post as a Product, is worse than having no schema at all, because now you are actively telling the search engine something untrue about your own site.

Benchmark before you touch anything

This is the step beginners skip and the step that pays your invoice.

Before every fix, write down where you are. Position for the target query, impressions, clicks, load time, indexed page count. Whatever the fix is supposed to move, record it first. After the fix, record it again.

Now you have a sentence: this action produced this result. That sentence is the entire case for search engine optimization being worth the money. Without a baseline you have opinions and a bill. With one you have evidence, and I have never met a professional who does not respond better to evidence.

If you would rather not build the baseline yourself, my free website audit produces one in about five minutes. No charge, no obligation.

Delaying a fix is not the same as ignoring it

Something in most people resists a prioritised list, because moving an item down feels like admitting you are not going to do it.

Not right now is not never. Sequencing exists so the work you do first creates the room, the budget and the goodwill for the bigger lifts later. I never walked into a hearing having read every page of disclosure with equal care. I walked in having read the pages that decided the case, and I knew exactly which pages I had chosen to leave. That is a plan. Reading all four hundred at the same depth is not diligence, it is panic with a highlighter.

What changes when you are a practice, not a marketing department

The video is pitched at someone starting an in-house role with tools, teammates and a manager. Most of the people I build for are a dentist, a paralegal, a chiropractor or a two-lawyer firm. The framework holds. Three things shift.

Your list is shorter than 700 and it is still too long. A typical small professional site audits at 30 to 80 real issues. That is not a relief. It means every item is a bigger share of the total, and the ordering matters more, not less.

You are the owner of every row. There is no sprint cycle to blame and no content queue to wait on. That is faster and more dangerous, because nothing forces you to sequence. Write the owner column anyway, even when the answer is your name eleven times, so you can see how much of the plan depends on hours you do not have.

You cannot fix what you do not control. This is the one that stops small practices cold. If your site sits on a platform you rent, half your top-priority list is unfixable by anyone. You cannot edit the template, add the schema or clean the URLs. Triage assumes you have access. If you are not sure you do, read whether you actually own your website before you spend an hour ranking issues you are not permitted to touch.

That is the whole reason I build the way I do. You own the code, you own the box, you own the domain. A priority list is only worth writing if you are allowed to work through it.

The plan, in four lines

1. Build one overview tab. Every issue from every tool, logged by type with its volume, plus impact, effort and owner.
2. Rank by combination. High impact and low effort goes to the top. High impact and high effort waits its turn and starts its conversation early.
3. Work from the top down. Take the quick wins first, publicly, so the momentum is visible.
4. Benchmark before and after every fix, so you can say what you did and what happened.

Prioritising is not the glamorous part of this work. It is also the part that separates the people who improve a website from the people who describe one. If you would like a second opinion on what should be at the top of your own list, that is what the SEO and visibility work is for, and site care is what keeps the list from filling back up.

Common questions

What is SEO triage?

SEO triage is the practice of sorting website audit findings into the order they should be fixed, based on the impact of each issue, the effort it takes and who has to do the work. The name is borrowed from emergency medicine, where the same principle applies: you cannot treat everything at once, so you treat in the order that produces the best outcome. In practice it turns a spreadsheet of hundreds of errors into a short, ordered list of decisions.

What should I fix first after an SEO audit?

Fix anything blocking indexation first, because nothing else matters if search engines cannot see or correctly identify your pages. That means sitemap problems, broken pagination, conflicting canonical tags and pages accidentally set to noindex. After that, work from the top of an impact-versus-effort ranking, taking high impact and low effort items before high impact items that need months of development.

Does high impact mean I should fix it first?

No, and this is the most common mistake. Impact is only half the decision. A high impact fix requiring three months of developer time should not jump ahead of a medium impact fix you can complete this week. Rank issues on the combination of impact and effort. High impact plus low effort always goes first, and low impact plus high effort can sit at the bottom of the list indefinitely without any guilt attached.

How do I know if something is a quick win?

A quick win is an issue you can fix in hours rather than sprints, without waiting on anyone else, that affects a page or a signal that actually matters. Internal linking to buried content, refreshing a stale but well-ranking article, fixing broken links in the main navigation and correcting a wrong schema type all qualify. The test is simple: if it needs one person, one afternoon and no new approvals, it is a quick win.

How old is too old for content on my website?

Eighteen months is a useful trigger point. Content older than that should be flagged for review, then either refreshed with current information or removed if it no longer serves a purpose. Age alone is not a problem; a piece from 2019 that still answers the question accurately is fine. The problem is stale facts, dead links, outdated pricing and advice that has been overtaken, all of which cost you trust with readers and with the systems deciding what to cite.

Why does every audit issue need an owner?

Because the owner determines the timeline. Issues you can fix yourself happen this week. Issues needing a developer enter a sprint cycle. Issues needing a writer join a content queue. Without an owner column, a list of twenty items looks like twenty weeks of steady progress when it is really seven things you could do immediately and thirteen sitting behind one busy person. Naming owners is how you set realistic expectations before you promise anything.

Why should I benchmark before making SEO changes?

Because without a baseline you cannot prove a change worked. Record the position, impressions, clicks, load time or index count before each fix, then measure again afterward. That gives you a specific sentence, this action produced this result, which is the only credible way to show that search work is paying for itself. It also protects you in the other direction: if a change made things worse, a benchmark tells you within weeks instead of months.

How many issues does a small business website usually have?

A typical small professional site comes back with 30 to 80 genuine issues, not the several hundred rows a crawler reports, because most tools list every affected URL separately rather than grouping by problem type. Three hundred broken links are one decision, not three hundred. Grouping by issue type before you prioritise is what makes the list workable, and it usually cuts the apparent size of the problem by an order of magnitude.