SEO Fix

When someone asks me for an SEO fix, I don't start with a list of hypothetical problems. I start with a crawl. I run Screaming Frog against the full site, then group every URL by section, template, content type, or business value. A sitewide total of 400 broken links is meaningless if 380 of them are buried in a blog archive that gets three visits a month. I need to know which segment the issues belong to before I can decide what matters.

Once I have the crawl data grouped, I score each issue type. I use five criteria: SEO impact, business impact, scale, risk, and effort. SEO impact means how much fixing this could move rankings or traffic. Business impact is about revenue or conversion. Scale is how many URLs are affected. Risk is the chance of breaking something. Effort is the time to implement. I assign each a low, medium, or high rating, then classify the issue into one of four buckets: fix now, fix soon, monitor, or ignore.

For example, I recently worked on an e-commerce site. The crawl showed 1,500 pages with missing meta descriptions. That sounds alarming, but 1,200 of them were product category pages that Google already ranked well without descriptions. The business impact was low because those pages were not primary landing pages. I put them in the monitor bucket. Meanwhile, 200 of the missing descriptions were on top-selling product pages. I fixed those immediately because they appear in search snippets and directly affect click-through rate.

After prioritising, I tackle the fix-now issues first. I update the [XML sitemap](/sitemap/) to remove redirected URLs, resolve [301 redirect](/301-redirect/) chains, and fix any [canonical tag](/canonical-tag/) misconfigurations. I also check [robots.txt](/robots-txt/) and noindex tags to ensure they aren't blocking important pages. This sequence has saved me hours of wasted work.

The biggest trap is treating every warning as equal. A crawl tool might report thousands of issues, but most are noise. I once saw a report with 1,200 'missing meta descriptions' — those were all paginated archive pages that Google wasn't even indexing. Fixing them would have been a waste of time. I ignored them, and traffic didn't budge. The lesson is to always cross-reference crawl data with Google Search Console to see which pages are actually indexed. If a page isn't indexed, a missing meta description doesn't matter.

Another common pitfall is fixing issues in isolation. A broken link on a product page might be a symptom of a larger problem, like a CMS that generates incorrect URLs after a migration. If you fix the link without addressing the root cause, you'll be chasing the same problem again next week. I always look for patterns: are the 4xx errors concentrated on one template? Are all the redirects pointing to the same old domain? That tells me where the real bug lives.

Be careful with risk. Some fixes, like changing a canonical tag or updating a .htaccess rule, can temporarily drop rankings if done incorrectly. I always test on a staging environment first. For large sites, I roll out changes to a small segment of URLs and monitor crawl stats and impressions for 48 hours before expanding.

Finally, don't assume that because a fix is easy it's worth doing. A quick win like adding a meta description to a low-traffic page is still a waste of time if that page doesn't rank. I use the [SEO audit](/seo-audit/) process to validate which pages have real potential before making changes.

For years, I thought page speed was the most important technical fix. I spent entire weeks optimising images, minifying code, and setting up CDNs. I once reduced a site's load time from 6 seconds to 2.5 seconds, and organic traffic barely moved. I was frustrated, but I'd missed the real problem: the site had a robots.txt file that disallowed crawling of the entire product catalogue. No amount of speed optimisation would help if Google couldn't even index the pages.

I also used to treat [Core Web Vitals](/core-web-vitals/) as a binary pass/fail. I would panic if a page got a 'poor' Largest Contentful Paint score, and spend hours on fixes that shaved 0.2 seconds. Meanwhile, the site had [duplicate content](/duplicate-content/) issues across thousands of product pages because of inconsistent URL parameters. I should have fixed the canonicalisation first. The page speed improvements barely moved the needle, but consolidating the duplicate pages into a single canonical version recovered 15% of organic traffic within a month.

Another mistake: I trusted the 'fix all' buttons in some SEO plugins. They often apply blanket changes that break things. One plugin removed all trailing slashes from URLs, which caused a flood of 301 redirects. That slowed down the site and annoyed Google. Now I only make changes I can test and roll back.

My approach now is to start with crawl and indexing analysis, not performance. I check Google Search Console for coverage errors first. If indexing is broken, nothing else matters. I prioritise fixes that unblock crawling and indexing, then consolidate signals with canonicals, and only then optimise for speed. That order has saved me from wasting weeks on low-impact work.