You deleted a page. Maybe you renamed it, maybe you merged it into another post, maybe you just decided it was outdated. And now, weeks later, you type the old address into a browser and land on a 404. Or worse, you see the old title in a search result, click it, and get the same dead end.
This looks worse than it is. Two separate things are happening, and they need two separate fixes.
The first is a human problem: someone clicked a stale link, or a search result that hasn’t updated yet, and landed on nothing. The second is a search problem: Google is still holding onto the old URL and showing it to people. You can fix the first one in a few minutes. The second one mostly fixes itself once the first one is done.
What a redirect actually does
A redirect resolves an existing URL to a different one. In Google’s own words, it tells your visitors and Google Search that a page has a new location. That’s the whole idea. You’re not deleting the old address; you’re putting a forwarding order on it.
For a WordPress site, you have two realistic places to set that forwarding order without touching server files: a redirect plugin that lives inside wp-admin, or a redirects section in your host’s control panel. Both produce the same result. The choice between them is mostly about which one you can find and undo more easily.
The one decision that matters: permanent or temporary
Everything else in this process is mechanical. This is the part where you can actually affect what Google shows.
Google’s documentation draws the line clearly. Permanent redirects show the new redirect target in search results. Temporary redirects show the source page in search results. That’s the practical difference, and it’s the only one you need to care about.
So the test is simple. Ask yourself: is the old URL gone for good, or might it come back?
If the page is permanently gone — you merged it, you replaced it, you’re never restoring it — use a permanent redirect. The status code is 301. Google recommends a permanent server-side redirect whenever possible when you’re changing the URL of a page as it appears in search results.
If the page is temporarily unavailable — you’re rewriting it, you’re pausing a service, you might bring it back next month — use a temporary redirect. The status code is 302. Google will keep showing the old URL in results, which is what you want in that situation.
If you’re not sure, ask whether you’d be upset if Google replaced the old URL with the new one permanently. If the answer is no, use 301.
Why you should not hand-edit .htaccess
You’ll find advice online telling you to open your .htaccess file and add a redirect rule. That advice is technically correct and practically wrong for your situation.
Google’s documentation notes that setting up server-side redirects requires access to server configuration files — such as .htaccess on Apache — or setting redirect headers with server-side scripts. That’s the mechanism. But a syntax error in a server config file can take your entire site down, not just the one page you were trying to fix. You’d go from one broken URL to every URL broken at once.
This isn’t a claim that .htaccess is impossible to learn. It’s a claim about blast radius. A wrong entry in a plugin screen or a host panel is usually reversible in the same screen you typed it into. A wrong entry in a server config file can lock you out of the site entirely. For a single-site owner with no developer on retainer, that asymmetry is the whole argument.
Tool path A: a redirect plugin inside wp-admin
The most common approach for non-technical WordPress owners is a redirect plugin. The Redirection plugin is the one most people encounter first. Its purpose is exactly what you need: managing redirects from inside wp-admin, without editing server files.
I want to be straight with you about a limitation here. I could not retrieve the plugin’s current official documentation while writing this, so I’m not going to walk you through specific menu names, button labels, or settings screens. Those details change between versions anyway, and guessing at them would be worse than saying nothing.
What I can tell you is the shape of the task. You install the plugin, you find its add-redirect screen, you enter the old URL path and the new URL path, you choose 301 or 302, and you save. The plugin’s own on-screen instructions will tell you the exact field names. Follow those.
One thing to watch for: some redirect plugins log 404 errors as they happen, which is genuinely useful. If yours does, that log becomes your to-do list. Every 404 that represents a page you deliberately removed is a redirect you haven’t added yet.
Tool path B: your host’s control panel
Before you install anything, check your hosting account. Many hosts expose a redirects section in their control panel. If yours does, that’s a server-side redirect set up without you editing any files — which is the best of both worlds.
I can’t point you to a specific host’s documentation here, because I didn’t retrieve any. But the check itself takes two minutes: log into your host, look for a section labeled something like “Redirects” or “URL Forwarding,” and see what’s there. If it exists, use it. If it doesn’t, go back to the plugin path.
The advantage of the host panel is that it sits outside WordPress entirely. If you ever break your WordPress install badly enough that you can’t reach wp-admin, a host-level redirect still works. That’s a real benefit for a single-site owner.
The step almost everyone skips
After you save the redirect, open a private or incognito browser window and type the old URL. You should land on the new page.
Do this in a private window specifically. Your normal browser may have cached the old 404, and you’ll see the dead page even though the redirect is working fine. A private window starts clean.
If you want to confirm the status code — that it’s actually a 301 and not a 302 — use a header-checking tool. Search for “HTTP header checker” and you’ll find several free ones. Paste the old URL in, and look for the status code in the response. A redirect you haven’t tested is a guess, not a fix.
If the old URL still 404s after you’ve saved and tested, the most common causes are a typo in the old path, a trailing slash mismatch, or the redirect being saved but not activated. Check those three before you assume the tool is broken.
What Google does afterward — and why you shouldn’t panic
Here’s the part that sends people back to re-do work they already did correctly.
Google keeps track of both the redirect source — the old URL — and the redirect target — the new URL. One of them becomes the canonical URL, and which one depends on signals like whether the redirect was temporary or permanent. The other becomes what Google calls an “alternate name.”
Alternate names can still appear in search results. Google’s documentation says it’s very likely that old URLs will continue to occasionally show up in results even after the new URLs are indexed. This is normal, and it fades as users get used to the new name, without you doing anything.
So if you set up a 301, tested it in a private window, confirmed the status code, and Google is still showing the old URL — that is not a broken redirect. That’s the alternate-name behavior working as documented. Don’t add a second redirect. Don’t delete and recreate the first one. Leave it alone.
The distinction matters: a failed redirect means the old URL 404s when you test it. An alternate name means the old URL redirects correctly when you test it, but Google is still showing the old title in results for a while. Test first, then decide which one you’re looking at.
A note on the developer-facing side
You may run into references to wp_redirect() if you search for WordPress redirect help. That’s a function for theme and plugin developers, not something you’ll use from wp-admin. Two things about it are worth knowing as background, because they explain why redirect plugins exist at all.
First, wp_redirect() defaults to a 302 status code, not a 301. So if a developer writes a redirect without specifying the status, it’s temporary by default. That’s a common source of the “why is Google still showing my old page” confusion.
Second, wp_redirect() does not exit automatically and should almost always be followed by a call to exit. If it isn’t, the rest of the page can keep loading after the redirect header is sent. Again — this is developer territory. You don’t need to write any of it. But knowing it exists helps you understand why the plugin screen is doing something more than it appears to.
The habit that prevents all of this
Add the redirect in the same sitting where you delete or rename the page. Not next week. Not when you notice the 404. The same sitting.
The reason is simple: right now, you know what the old URL was. Three months from now, you’ll be reconstructing it from memory, from a browser history you’ve cleared, or from a search result you can’t quite read. The redirect takes seconds when you add it at deletion time. It takes an afternoon when you add it later.
Keep a plain list somewhere you’ll actually find it — a note, a spreadsheet, a draft email to yourself. Two columns: old URL, new URL. When you delete a page, add a row. When you’re not sure whether you already redirected something, check the list before you go digging through plugin screens.
That list is also your recovery plan. If a redirect plugin ever breaks or gets removed, you have every old-to-new mapping in one place, ready to re-enter in your host panel or a replacement plugin.
Questions that come up
Do I need a redirect if the page is truly gone and I don’t want it back?
You need one if people are still linking to it or finding it in search. If the page had no inbound links and no search presence, a 404 is fine — it’s the honest answer. But if you’re seeing the old URL in search results or in your analytics, add the redirect. Send those visitors somewhere useful rather than to a dead end.
What if I don’t have a relevant new page to redirect to?
Redirect to the closest thing you do have — a category page, a related post, your homepage. A redirect to a relevant page is better than a 404. A redirect to your homepage is better than nothing, though it’s a weaker signal than sending someone to genuinely related content.
Can I redirect to a page on a different website?
Yes, technically. But be careful. If you’re redirecting to a site you don’t control, you’re sending your visitors and your search signals somewhere you can’t manage. For a single-site owner, redirecting within your own site is almost always the right move.
How long should I keep the redirect in place?
For a permanent redirect, keep it indefinitely. There’s no cost to leaving it, and removing it later re-creates the 404 you just fixed. Google’s documentation doesn’t give a timeframe for how long old URLs keep appearing as alternate names, so don’t set a calendar reminder to remove the redirect. Just leave it.
I set up the redirect but Google still shows the old page. What now?
Test the old URL in a private window first. If it redirects correctly, the redirect is working and you’re seeing alternate-name behavior. If it 404s, the redirect isn’t working and you have a configuration problem. Those are two different situations and they need two different responses. Test before you change anything.
Will a redirect bring back my search rankings?
No. A redirect tells Google the page has moved. It doesn’t restore lost position or traffic. What it does is prevent the situation from getting worse — it stops visitors from hitting a dead end and gives Google a clear signal about where the content went. Treat it as damage control, not recovery.
Where to start
Check your host’s control panel for a redirects section. If it’s there, use it. If it isn’t, install a redirect plugin and follow its on-screen instructions. Choose 301 if the page is gone for good, 302 if it might come back. Test the old URL in a private window. Confirm the status code with a header checker. Then leave it alone and let Google catch up.
The 404 you’re looking at right now is not a crisis. It’s a missing forwarding order, and you’re about to write one.
