Fixing 404s and broken links on large sites: a working method
On a site with tens of thousands of URLs, 404s are not an emergency but a stream to manage. Here is what to fix, what to leave, and how to measure it.
404s are not harmful in themselves
Google states plainly that 404 pages are a normal part of the web and do not demote a site on their own. What hurts is lost link equity and a broken user journey, not the status code.
So the task is not 'eliminate all 404s' but 'triage the 404s that have internal links, external links or traffic'. The rest can stand and will fade out of reports.
Other things are genuinely dangerous: 404s on pages that used to earn traffic; broken template links replicated site-wide; and soft 404s, where the server returns 200 for a page that does not exist.
Where to look
First source: the Search Console Page Indexing report, 'Not found (404)' section. It lists URLs Google tried to crawl, and clicking a URL shows where links to it come from.
Second: a crawler. Screaming Frog's Response Codes report shows broken URLs and, more importantly, the Inlinks column — how many of your own pages point at them. That is your priority fix list.
Third: Ahrefs or similar with a Best by Links report filtered to broken pages. It finds URLs deleted long ago that external sites still link to. Those get redirects first — free recovery of link equity.
301, 410 or 404: choosing correctly
Use 301 when a relevant replacement exists. A discontinued product with an equivalent or a live category; an article rewritten under a new URL; a relocated section. The redirect must land on something close in meaning, not on the homepage.
Bulk-redirecting every 404 to the homepage is a common and harmful practice. Google classifies such redirects as soft 404s and excludes the pages anyway, while you lose visibility into the site's real state.
Use 410 Gone when a page was removed deliberately with no replacement: an ended promotion, a discontinued SKU with no equivalent. Google processes 410 slightly faster than 404, but the end result is the same. Plain 404 is an acceptable default.
Soft 404s: the hidden problem
A soft 404 tells the user 'nothing found' while returning HTTP 200. Typical sources: empty internal search results, categories emptied after a clearance, out-of-stock product pages stripped of content.
Search Console flags them with a dedicated status in the indexing report. The harm is that the crawler spends budget on empty pages and treats them as indexable.
The fix depends on the case: for an empty category, return 404 or fill it with content; for an out-of-stock product, keep 200 with price, description and links to alternatives, because such a page is useful and often carries link equity.
Broken links in templates
One typo in the footer template produces a broken link on every page of the site. In a crawl report that appears as a single 404 with tens of thousands of inlinks — such findings get fixed first.
After fixing, verify links point at final URLs rather than redirects. Chains of link → 301 → 301 → page waste crawl budget and slow the page for users.
Set up a monthly crawl and compare with the previous run. On a large site new broken links appear constantly through content edits, and a one-off cleanup does not hold.
The 404 page as a working element
The error page itself must return 404, not 200, and offer something useful: site search, links to main sections, popular products, contacts. A blank 'Error' page sends the user straight back to the SERP.
Style it in the site design with working navigation, and in the language of the current site version. A frequent oversight on multilingual .uz projects is a single Russian 404 page for every language version.
Track 404 hits in analytics as a dedicated event recording the requested URL and referrer. That gives a live problem list from real users, not just from the crawler.