New format
301 redirects in .htaccess: common rules
On Apache, `.htaccess` is often used for permanent 301s: merge mirrors, move a URL, strip leftover tails. A bad rule can take the site down — edit with a backup.
Below: typical scenarios and cautions. Theory of 301/302 codes lives in the redirect piece; nginx uses different syntax.
When you need a 301
Slug changes, section moves, http→https and www/non-www merge, domain migration. Goal — one canonical address without chains.
Signs it’s time:
- old URLs in Webmaster with 404 after a move
- two mirrors in the index
- external links to outdated paths
Typical rules
Enable `RewriteEngine On` and write conditions + `RewriteRule` with `[R=301,L]`. Exact syntax depends on the directory and `RewriteBase`.
Idea examples (don’t copy blindly): force https; www→non-www (or reverse); one page URL to a new path; `domain-old` → `domain-new` keeping the path.
Before going live:
- backup the current `.htaccess`
- test on staging
- check chains (one hop)
- verify with `curl -I` or similar
When a redirect isn’t needed
Don’t dump all junk to home — it blurs meaning. Don’t duplicate 301 and canonical on conflicting URLs without need. Don’t leave A→B→C chains.
Mistakes:
- redirect loops
- a temporary 302 forever
- editing production without a backup
- forgotten HTTP after enabling HTTPS
Prepare a URL migration map
Before a mass move, make a table: old URL, new URL, reason, response type, check status. Include important pages from analytics, XML sitemaps, external links, and Webmaster reports — not only URLs you remember easily.
Map pages by meaning. A product card goes to a replacement or relevant category; an article to an updated piece on the same topic. If there’s no equivalent, an honest 404 or 410 beats a home redirect.
In the migration map include:
- full old and target URL
- rule purpose — domain, section, or single page
- expected 301 code
- deploy date and test result
Mind rule order and context
`.htaccess` runs in directory context, so path patterns and rule starts can differ from a virtual-host config. Don’t paste article examples literally until you check the document root, current CMS rules, and `AllowOverride`.
Place general canonical protocol/host rules first, then point moves. Every condition should be clear: mixed www, HTTPS, slash, and CMS rules without testing often create an extra hop or an infinite loop.
Be especially careful with:
- rules that redirect the whole domain
- regex with broad matches
- duplicate settings in a CDN or hosting panel
- automatic CMS and plugin rules
Test after every change
Apply a rule on staging or a small URL group first. Check the source address, target, query-string variants, HTTP and HTTPS, www and non-www. Result should be one hop to the final canonical page.
After publish, watch status codes in a crawler and Webmaster. Fix A→B→C chains: the final address should be stated immediately. Don’t use a permanent redirect as a temporary experiment — browsers and search engines may cache it.
Acceptance checklist:
- no loops or multiple sequential redirects
- parameters kept only where needed
- destination returns 200 and is crawlable
- important old URLs checked selectively and in bulk
FAQ
Where does .htaccess live?
Usually in the site root (or the virtual host directory). Not every host enables `AllowOverride`.
Will these rules work on nginx?
Not as-is. On nginx you write `return 301` / `rewrite` in the server config.
Should the examples use 301 or 302?
For permanent moves — 301. Temporary promos — 302/307.
Can you paste rules in a batch?
Carefully: order matters, loops are easy. Test one at a time.
Should I redirect instead of deleting a page?
If there’s a close-in-meaning URL — yes. If the topic is gone — better 404/410 than everything to home.
How do I check the status code?
Open response headers via DevTools, `curl -I`, or a checker. Test the original URL without a browser-cached redirect.
Moved URLs — and the site fell to a redirect loop?
We’ll map old→new with backups and one-hop 301s — no dumping everything to home.
Discuss the task
