Write redirect rules for one page or a whole list of moved pages, for Apache (.htaccess), nginx, Vercel, Netlify, Cloudflare Pages or IIS. Paste old and new addresses from a spreadsheet; the tool catches loops, chains, duplicates and pages sent to the home page before they reach your server.
Type the old and new address to see the rule.
A redirect sends visitors and search engines from an old address to a new one. When you rename a page, restructure a site or move to a new domain, redirects keep old links, bookmarks and search results working, and pass the old page's ranking to the new one. This tool writes the rules for the server or host you use, for one page or thousands, and checks the list first for the mistakes that break sites: loops, chains, clashing duplicates and whole sections sent to the home page.
Tip: Map every old page to its closest new equivalent, not to the home page. A matching page keeps the visitor and the ranking; a home-page redirect loses both and is treated by Google as a missing page.
Loops: A goes to B and B back to A, or an address goes to itself, including the same path with and without a trailing slash. Browsers stop with "too many redirects" and the page disappears from search. Chains: A goes to B, which goes to C. Each hop slows the visitor, and Google follows only a limited number of hops; with Shorten redirect chains on, the tool sends A straight to C. Clashes: the same old address listed twice with different targets. Only one can win, so the tool keeps the first and tells you.
It also warns when many pages are sent to the home page, when temporary codes are used, when old addresses come from several domains (each domain needs its own configuration), and when old addresses contain a query string such as ?id=42. Those are matched exactly with extra conditions on Apache, nginx, Vercel and IIS; Netlify and Cloudflare Pages can't match a fixed query value, so the line is shown as a comment for you to handle another way.
Apache: the rules use mod_rewrite and go near the top of the .htaccess file in your site's top folder, before rules from WordPress or other software, so they run first. Each rule matches the path with or without a trailing slash and, unless you turn it off, keeps the visitor's query string. nginx: paste the lines inside the server block of the old site, run nginx -t to test the configuration, then reload. Very long lists are faster as a map block.
Vercel: merge the redirects array into vercel.json at the project root; 301 and 302 use statusCode, while 308 and 307 use permanent true or false. Netlify and Cloudflare Pages: save the lines as a file named _redirects in the folder that gets published. IIS: the rules need the URL Rewrite module and go in web.config; IIS has no 308, so those rules use 301.
Many content systems have their own redirect settings: Shopify (Navigation, URL redirects), Wix, Squarespace and WordPress plugins such as Redirection. If yours does, use the clean list from this tool there instead of editing server files.
Export every old address that has traffic, links or rankings: from your analytics, Search Console's Pages report, a crawl of the old site and your sitemap. Map each one to its new address in a spreadsheet, paste it here, fix what the checks find and deploy the rules at the same moment as the new site. Then crawl the old addresses to confirm each returns one 301 to a page that answers 200, update internal links and the sitemap to the new addresses, and keep the redirects for at least a year, ideally for good.
Redirects are a safety net. Change links on your own site to the new address so visitors and crawlers skip the hop.
Google recommends keeping redirects for at least a year after a move; old links elsewhere keep working only while they exist.
Try a few old addresses on a staging site, and run nginx -t or check the .htaccess syntax before deploying.
If a page has no replacement, a 404 or 410 is honest and fine. Don't redirect everything just to avoid errors.
Each rule matches the path with and without a final slash, so list a page once. A rule from /page/ to /page would loop, so the tool leaves it out.
Site-wide moves such as http to https or www to non-www are usually a host setting, not a list of single redirects.
No. Google has said for years that 301, 302 and 308 redirects pass full ranking signals. Rankings can shift during a move while Google recrawls, then settle.
Thousands are fine on Apache and nginx. Hosted platforms set limits on file-based rules, so very large lists may need their bulk redirect features or middleware.
It's how site moves are planned: a spreadsheet of old and new addresses. Export two columns and paste them here.
On the same site a path such as /new-page is enough. For another domain, write the full address with https://.
Yes, unless you turn Keep the query string off. Campaign tags such as utm_source then survive the redirect.
No. The checks and previews run in your browser, on your device. Nothing you type or paste is uploaded, stored or logged.
Updated