When you rename a service, move your website or delete an old article, people may still try to visit the previous address.
Some visitors arrive through bookmarks or old emails. Others follow links from another website or a search result. If they reach the wrong place—or a page that doesn’t explain what’s happened—you can lose a potential enquiry.
Redirects and useful 404 pages help handle those changes without pretending every old URL still has a matching replacement.
What is a 404 page?
A 404 response means the requested resource wasn’t found.
That isn’t always a technical failure. Sometimes the page was genuinely removed. A well-designed 404 page should explain that the address isn’t available and give people a way to recover: find core services, visit the blog, return home or contact the business.
The page must still return the correct HTTP 404 status. A friendly design with an incorrect 200 response can confuse search engines and monitoring tools.
When a permanent redirect makes sense
A 301 redirect is appropriate when an old URL has a genuinely relevant new home.
For example, if a service page moves to a new path but still describes the same offering, redirect the old address to the new one.
If two overlapping articles are consolidated into one useful replacement, a redirect may also make sense after reviewing the content, incoming links and search performance.
Don’t automatically redirect every missing URL to the homepage. Someone expecting a detailed repair guide won’t be helped by an unrelated generic introduction.
Use the closest relevant destination
The guiding question is what the visitor originally wanted.
If the old page explained a service that still exists, send people to the best current explanation. If the information was retired with no suitable equivalent, a normal 404 or 410 response may be more honest.
A redirect shouldn’t be used merely to hide missing pages from reports.
Make a redirect map before a redesign
Create a simple table with old URL, new URL, reason for the change and status.
Include important service pages, blog articles, advertising destinations and URLs with known backlinks or existing traffic.
Check the map before launching the new site. This is much easier than discovering later that valuable links now lead nowhere.
For broader launch checks, see the website launch checklist.
Avoid unnecessary redirect chains
Ideally, an old URL should take the visitor straight to the final destination.
A chain through two or three intermediate addresses adds complexity and can make maintenance harder. Update your internal links to the preferred destination instead of knowingly pointing them through a redirect.
Check canonical tags and the XML sitemap to make sure they use the intended new URLs.
Fix broken internal links at the source
A redirect can protect old external links, but it shouldn’t excuse leaving wrong links inside your own navigation and articles.
Find links pointing to old paths and replace them with the current addresses. Check buttons, menus, footer links and contextual links from older content.
The internal linking guide gives a practical way to connect useful pages after the technical route is fixed.
What to do when you move from /resources/ to /blog/
If your website used an old resources section and now publishes articles under /blog/, map each old article path to the equivalent current post when one exists.
Also consider the old listing route. It may need to direct visitors to the new blog index.
Keep the sitemap and navigation focused on current canonical URLs. Don’t create two indexable copies of the same article simply because you can keep both paths working.
Google’s canonicalization guidance explains how redirect signals fit into this.
Check for soft 404s and misleading responses
A “not found” message rendered with a normal 200 success status isn’t the same as a genuine 404. And an irrelevant redirect may confuse the visitor rather than solve the problem.
Test response codes with appropriate tools, not just by looking at the page.
For service pages that have moved, also inspect the final content. The redirect only helps if the destination still provides a useful answer.
Test redirects locally before releasing changes
In an Astro project, redirects may be configured by the hosting platform or build setup rather than inside each page.
Inspect the project’s existing redirect configuration and avoid introducing a second competing system. Run local build checks and verify route handling where the tooling permits.
Do not deploy merely to see whether a redirect works. If a behaviour can only be confirmed in a hosting environment, report that limitation and request approval for the next stage.
Audit older 404s with real priorities
Use Search Console, your own link checks and any available logs to find broken URLs.
Start with links customers actually use, pages with relevant external links and routes associated with important services.
Not every historic random path deserves a redirect. Keep the audit practical rather than creating a thousand rules that obscure real problems.
Redirect decisions should sit inside a wider technical SEO audit and be tested against the visitor’s original intent.
Frequently asked questions
Should every 404 redirect to the homepage?
No. Redirect only when there is a relevant replacement. Otherwise return a useful not-found response.
What’s the difference between 301 and 302?
A 301 signals a permanent move; a 302 indicates a temporary redirect. Choose based on whether the move is meant to be permanent.
Can I delete a page without a redirect?
Yes, when it has no suitable replacement. Review whether it has useful traffic, links or customer value first.
Can I change blog URLs just to make them shorter?
You can, but changing established URLs creates unnecessary risk when the existing address is already suitable. Keep stable URLs whenever possible.
A good redirect plan protects the visitor’s original intent. That’s more useful than sending every old address somewhere just to eliminate errors from a report.