How to fix a 404 error, step by step

Finding your 404 errors is the easy part. Deciding what to do with each one is where most webmasters hesitate, because the right answer is different for every broken address. A page you deleted on purpose, a link with a typo in it, and an article that moved to a new address all produce the same 404, but they need three different repairs.

This guide gives you a decision process you can apply to every entry in your list, plus the exact rules to write once you have decided.

Step 1: build the complete list

You cannot repair what you have not found. There are three complementary sources, and each one shows errors the others miss.

Crawl your own site

A crawler starts from your homepage, follows every internal link, and records the response of each address. This catches the broken links that exist inside your own pages, which are the ones fully under your control and therefore the ones you should fix first. The Bye404 link checker does exactly this, and reports both the broken address and the page where the faulty link was found, so you know precisely which file to edit.

Read your server logs

Your access log records every request, including the ones that failed. On an Apache server the relevant lines contain the code 404 in the status field. This source is valuable because it shows addresses that nobody links to any more but that visitors and robots still request, often because of an old bookmark or an external site pointing at you.

Check Search Console

Google Search Console lists the addresses Google tried to crawl and could not reach, under the page indexing report. These are the errors that directly affect your presence in search results, which makes them the highest priority of the three. The same report is where soft 404 errors surface, which no other source will show you.

Step 2: choose the right repair for each address

For every broken address, ask the questions below in order and stop at the first one that applies.

Does an equivalent page exist somewhere else on the site?

If the content moved, or if another page covers the same subject well, redirect the old address to it with a permanent redirect. This preserves the visitors arriving from old links and transfers the accumulated ranking signals to the surviving page.

Be honest about what counts as equivalent. Redirecting a deleted product page to your homepage is not a repair, it is a way of hiding the problem. Search engines treat a redirect to an irrelevant page as a soft 404 and handle it as if the page were simply missing, so you gain nothing and the visitor is confused. Google sets out which redirect to use in which situation in Redirects and Google Search.

Is the address itself simply wrong?

A surprising share of 404 errors come from the link, not the destination. Look for a trailing character that should not be there, a missing extension, an uppercase letter in a path that is served case sensitively, or a relative path that breaks when the page is viewed from a subdirectory. In these cases the destination is fine and you only need to correct the link in the source page. The crawl report tells you which page contains it.

Was the page deliberately removed with nothing to replace it?

Return a 410 Gone instead of a 404. It carries the same result for the visitor but tells search engines that the removal was intentional, which clears the address from the index faster than a 404 does. Use this for expired offers, discontinued products with no successor, and articles you retired on purpose.

None of the above?

Leave the 404 in place. A 404 is not a defect in itself, it is the correct answer to a request for something that does not exist. What matters is that the visitor lands on a helpful page rather than a blank server message, which is the subject of step 4.

Step 3: write the rules

On an Apache server, redirections live in the .htaccess file at the root of your site. The examples below use the classic directives, which are enough for the vast majority of cases. They are documented by the Apache Software Foundation in mod_alias and Custom Error Responses.

Redirect one page permanently

Redirect 301 /old-article.html https://www.example.com/new-article.html

Redirect a whole directory that moved

RedirectMatch 301 ^/old-section/(.*)$ https://www.example.com/new-section/$1

Declare a page permanently gone

Redirect 410 /discontinued-product.html

Point to your own error pages

ErrorDocument 404 /page404.php
ErrorDocument 403 /page403.php

Avoid redirect chains and loops

When you redirect a page that was already the target of an earlier redirect, you create a chain. Each additional step slows the page down and dilutes the signals passed along. Whenever you add a rule, check whether an older rule already points at the address you are about to move, and update that older rule to point directly at the final destination.

A loop is the pathological version of the same problem: A redirects to B and B redirects back to A. The browser gives up after a few round trips and shows an error instead of your page. If a page suddenly becomes unreachable after an .htaccess edit, a loop is the first thing to suspect.

Chains and loops never appear in a broken link report, because a redirection is not an error. To see them you need to look at the codes themselves, which is what our 301 and 302 redirect checker does across a whole site.

Step 4: build a 404 page that actually helps

Some 404 errors will always exist. Visitors mistype addresses, other sites link to you incorrectly, and old bookmarks outlive the pages they point to. The question is what those visitors see when it happens.

A useful 404 page has four things:

• A clear statement that the page does not exist, in plain language rather than a technical code.
• The same header, navigation and styling as the rest of the site, so the visitor knows they are still in the right place.
• Links to the main sections, and a search field if your site has one, so the visitor can continue instead of leaving.
• A genuine 404 status code in the server response. This is the part people get wrong.

Step 5: verify and keep watching

After the repairs, crawl the site again. The second crawl confirms that the addresses you redirected now answer correctly, and it catches the errors you introduced while fixing the first batch, which happens more often than anyone likes to admit.

Broken links reappear over time. Internal pages get renamed, and external sites you link to disappear without warning. A quick scan after each significant update, and a full scan every few months, is enough to keep a site clean.

If your report contains missing images rather than missing pages, the causes are different and are covered in our guide on broken images and soft 404 errors. For the meaning of each response code you will encounter, see the HTTP status code reference.