Changing a page's address looks like a minor detail until you see next month's traffic drop. Every ranking address accumulated value over months or years: links from other sites, people who bookmarked it, the position it earned in results. If the address changes and nobody is told, all of that is lost at once. The permanent redirect is the mechanism that prevents that loss, and using it well is one of the technical skills that saves the most money.
What a permanent redirect actually does
When someone requests an old address, the server answers: "this moved for good, go to this other one." The browser goes on its own, with the visitor noticing nothing but a flicker. And the search engine does something more important: it transfers practically all the authority the old address had accumulated to the new one, and over time replaces the old with the new in its results.
The key word is "practically." The transfer is very high but not always perfect, and it isn't instant: it can take weeks to settle. That's why the best redirect is still the one you don't have to make. Before changing an address that works, the honest question is whether the change is worth the risk.
Permanent or temporary: which to use
The rule is simple and almost nobody applies it correctly. Use permanent when the change is definitive: a redesign with a new structure, a domain change, merging similar pages, fixing badly built addresses, forcing a secure connection. Use temporary when the change will be reverted: a page under maintenance, a two-week promotion, a test between two different versions.
The costly mistake is using temporary where permanent belonged. The engine understands the old address is still the good one, so it transfers nothing and keeps the old one indexed. Months later, someone wonders why the new page won't climb. The reverse error, using permanent for something later reverted, also stings: browsers memorize permanent redirects very stubbornly, and going back can take a while to take effect.
How to plan a URL migration
If you're changing the structure of an entire site, the difference between a calm month and a disaster is preparation. The order I recommend:
- Export every current address. From the sitemap, from the database, and from webmaster tools, which additionally tells you which ones actually get visits.
- Build a two-column table: old address and new address. No exceptions, no "I'll deal with that one later."
- Prioritize by traffic and by inbound links. If you have two thousand addresses, the top hundred concentrate nearly all the value. Those have to be perfect.
- Decide what to do with the ones that have no equivalent. The right answer is almost never sending them all to the homepage: search engines read that as a disguised missing page. Better the closest category, and if there genuinely is nothing related, let it return an error, which is an honest answer.
- Test before publishing, in a staging environment if you can.
- Publish the redirects at the same time as the new site, not the next day. That one day of gap is what creates the disaster.
- Update the sitemap with the new addresses and resubmit it.
- Monitor for a month for not-found errors, which is where the ones you missed will surface.
The mistakes that sink your traffic
- Redirecting everything to the homepage. It's convenient and it's the worst thing you can do. A visitor looking for something specific lands somewhere generic and leaves, and the engine transfers no value.
- Long chains. A leads to B, B to C, C to D. Every hop adds load time and dilutes the transfer. Always point straight at the final destination, even if it means rewriting old rules.
- Infinite loops. A leads to B and B leads to A. The browser gives up and shows an error. It usually happens when mixing secure-connection rules with domain rules.
- Redirecting to a page that also moved without updating the original rule.
- Forgetting the variants. With and without a trailing slash, with and without "www," uppercase and lowercase: every combination is a different address to the server.
- Not updating internal links. Redirects are for the outside world; inside your own site, links should point directly at the new address. Leaving them old makes every click take an unnecessary bounce.
Where to configure them
There are three possible places and each has its moment. In the server configuration file is the fastest to execute and ideal for general, bulk rules, with the downside that a syntax error takes the whole site down. From a plugin or from the application itself is more convenient, leaves a record, and carries no risk of breaking anything, but each redirect costs a bit more because it's resolved after the system boots. And at the level of an external service, if you use a layer in front of your site, that's the fastest of all because it never reaches your server.
My practical rule: general and permanent rules in the configuration file, one-off redirects that change often from the application.
How long to keep them
The short answer: far longer than you think. Even after the engine consolidates the change in a few months, there will always be people with the old address saved and outside sites that never updated their links. Removing a redirect after a year means throwing away links that still send you visitors. If they work, leave them: they cost almost nothing and keep recovering traffic for years.
One technical detail that matters: on LiteSpeed servers, rewrite rules use the same Apache syntax but are processed much faster, which shows once you have hundreds of accumulated rules. That's one of the reasons I use BanaHosting: LiteSpeed with LSCache, full cPanel with a file editor and redirect manager, free migration of up to 3 sites with no downtime — which is precisely when you'll need redirects most — and 24/7 support that will review the rules if something came out wrong. Plans start at $4.95 a month with a 30-day money-back guarantee.