301 redirect without losing rankings: moving pages, domains and https

A properly configured 301 redirect passes almost all of the old URL's authority to the new one, so rankings dip only briefly after a move, typically for two to four weeks, and then recover. Sites lose traffic not because of the redirect itself but because of the mistakes around it: everything pointed at the homepage, chains of three hops, old links still sitting in the menu, and a sitemap full of retired URLs. Below we cover how 301 differs from 302 and 308, when you actually need it, how to write the rules in .htaccess and nginx, and how to confirm it all worked.

301, 302, 307, 308 and meta refresh: what is the difference

The server response code tells the browser and the search engine that a page has moved and how to treat that move. For SEO, the distinction between permanent and temporary is what matters: with a permanent move Google gradually replaces the old URL in its index with the new one, with a temporary move it keeps the old URL and waits for it to come back.

For most sites the choice boils down to two options: 301 for good, 302 for a few days. The "302 or 301" dilemma is settled by one question: will the old URL ever come back? If not, use 301. Google has long confirmed that both codes pass PageRank, but with a 302 the search engine keeps the old page in the index longer and may never switch to the new one at all. At Query we have seen plenty of sites where a 302 stayed in place for a year after a redesign, while the search results kept showing old URLs that returned a 404 on click.

Google also understands meta refresh and JavaScript redirects, but processes them more slowly and not always reliably. Treat them as a fallback for website builders with no access to server configuration, not as the main tool.

When you need a 301 redirect

• A page URL changes. You renamed a category, removed dates from blog URLs, or restructured your permalinks. Every old path needs its own new destination.
• Merging pages. Three similar articles were combined into one: the two leftovers redirect to the one that remains.
• Moving from http to https. The https redirect applies to every URL without exception, including images, PDFs and other files.
• www and non-www mirrors. Pick one primary version and redirect the other to it. The same goes for trailing slashes and letter case.
• Moving a website to a new domain. The riskiest scenario: here redirects work together with notifying Google about the change of address. We have collected everything else to consider on our SEO for a domain change service page.
• Removing a product or service. If there is a close equivalent, redirect to it. If there is none, an honest 404 or 410 beats sending everyone to the homepage.

How to set up a 301 redirect without losing rankings

The line itself takes a minute to write. Rankings are lost in the preparation, so the order of steps matters.

1. Collect the full list of old URLs. Export addresses from Search Console, analytics, the sitemap and a crawler (Screaming Frog or similar). Flag pages with traffic and external links separately: those hurt the most to lose.
2. Build a 1:1 mapping. Each old URL gets a specific new one with the same content. Google treats a blanket redirect of everything to the homepage as a soft 404 and passes no authority.
3. One hop, not a chain. The old URL leads straight to the final destination. If the site already has older redirects, rewrite them to point at the new target, otherwise you end up with chains of two or three hops, and Googlebot follows only a limited number of them.
4. Update internal links. Menu, footer, in-text links, canonical, hreflang: all of them should point directly at the new URLs, not through a redirect.
5. Regenerate sitemap.xml with the new URLs only and submit it in Search Console. Do not keep the old sitemap with retired addresses.
6. Tell Google about a domain change. Search Console has a Change of Address tool: it works only for moves between domains and speeds up the transfer of signals. The official guide: Site moves with URL changes.
7. Pick a quiet period. Not right before the season and not on the day an ad campaign launches. For the first two or three weeks, check coverage in Search Console daily.

Examples for .htaccess and nginx

On Apache, redirects live in the .htaccess file in the site root; on nginx, in the server configuration (nginx.conf or the site file in sites-available). After editing nginx you need to reload it with nginx -s reload; Apache picks up .htaccess changes immediately.

.htaccess (Apache)

One page to a new address:

Redirect 301 /old-page/ https://site.com/new-page/

The whole site from http to https and to the non-www version in a single rule:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ https://site.com/$1 [R=301,L]

Moving to a new domain while keeping the paths:

RewriteCond %{HTTP_HOST} ^(www\.)?old-site\.com$ [NC]
RewriteRule ^(.*)$ https://new-site.com/$1 [R=301,L]

nginx

A single page:

location = /old-page/ { return 301 https://site.com/new-page/; }

The whole domain, http and www together:

server {
    listen 80;
    server_name old-site.com www.old-site.com;
    return 301 https://new-site.com$request_uri;
}

In nginx, rules written with return 301 run faster than rewrite, and they are the right choice for large-scale moves. WordPress and other CMSs have redirect plugins, but for hundreds of URLs a server-level rule is more reliable and does not load PHP on every request.

How to check that the redirect works

The fastest way: run curl -I https://old-site.com/old-page/ in a terminal. The response should contain the line HTTP/2 301 and a location: header with the final address. If the first 301 is followed by another 301 or 302, that is a chain, and it needs to be shortened to a single hop. The curl -IL command shows the whole chain at once.

For bulk checks, run the old URL list through Screaming Frog in List mode: it shows the response code, the final address and the number of hops for every row. There are plenty of free online redirect checkers too, and for a dozen URLs they are perfectly adequate.

In Search Console, watch two reports. Pages (indexing) shows whether old URLs got stuck in the "Page with redirect" bucket without the new page being indexed. Performance should show, two or three weeks in, that clicks on the new URLs have recovered to the level of the old ones. The URL Inspection tool lets you see separately how Googlebot views a specific address and which page it considers canonical.

How long to keep redirects

Google recommends keeping 301 redirects for at least a year: roughly the time it takes the search engine to recrawl all the old URLs, transfer the signals and stop coming back to them. In practice we advise not removing them at all while the old domain is alive or while the old URLs still receive visits. Nobody will rewrite external links from other sites, and a year later each of them will still hit the old address.

The exception is technical rules that create load or conflict with the new structure. Review those after a year using server logs: if nobody has requested an address in 12 months, the rule can go without consequences.

Common mistakes that eat rankings

• Everything to the homepage. The most common and most expensive mistake. Google ignores such a redirect as a soft 404, and the old pages' rankings vanish.
• 302 instead of 301. The old URL stays in the index for years, the new one never gains authority.
• Chains and loops. The old address leads to an intermediate one, which leads to yet another. Every extra hop slows crawling, and a loop blocks the page completely for both people and bots.
• Redirects for pages only. Images, PDFs and files that drew traffic from image search and had external links get forgotten.
• Old domain not renewed. Two years later the domain expires, the redirects disappear with it, and so do all the external links.
• New page blocked from indexing. It returns noindex or is disallowed in robots.txt, and the authority goes nowhere.
• Different content. An old delivery page redirects to a payment page. Technically the redirect exists; in substance it is the same soft 404.

If the site has hundreds of URLs and no developer who knows the server configuration, it is safer to hand the move over as part of technical website improvements: the redirect map, server rules and post-launch checks come as one package there.

Where to start

1. Export the full list of current URLs and flag those that bring traffic and have external links.
2. Build a 1:1 "old address to new" table with no blanket redirects to the homepage.
3. Write the rules at the server level and check a sample with curl -I for chains.
4. Update internal links, canonical tags and the sitemap, submit the sitemap in Search Console, and run Change of Address if the domain changes.
5. Watch the Pages and Performance reports for three weeks and keep the redirects for at least a year.