How to Change URLs in Bulk with 301 Redirects

Google treats changed URL paths as a site move, even when the domain stays the same. Search traffic usually fluctuates while Google recrawls the site: for a medium-sized site, Google says it can take a few weeks or more before the new URLs replace the old ones in results. So change URLs in bulk when there is a lasting gain:

• The old URLs are broken or misleading. Examples are index.php?p=123 addresses, dates that make evergreen posts look stale, or slugs that no longer match the page.
• The structure is changing anyway. A new CMS, a merged blog or a new folder layout will change URLs no matter what, so fix the slugs in the same move.
• You are consolidating content. Several thin pages become one stronger page.

Do not change URLs only to make slugs a few characters shorter. Our URL slug length guide explains why the length of a published slug is rarely worth a migration.

Google recommends server-side redirects whenever possible. A 301 and a 308 are both permanent; 301 is what most tools, including ours, write by default. Google also states that 301 and other permanent redirects don't cause a loss in PageRank, so a correct redirect passes the old page's signals to the new one.

You cannot redirect what you do not know about. Combine several sources, because each one misses something:

1. Your XML sitemap and CMS export. These cover the pages you know you published.
2. Server logs and analytics. These show the URLs that people and crawlers actually request, including old variants.
3. Search Console. The Pages and Links reports show indexed URLs and the pages that other sites link to.
4. Images, PDFs and videos. Files with changed paths need redirects too.

Put everything in one spreadsheet column and remove exact duplicates. Keep the original capitalization, because URL paths are case-sensitive: /Blog/Summer_Sale_2024 and /blog/summer_sale_2024 are different URLs.

Every old URL needs exactly one destination, and that destination should match the old content as closely as possible.

• Redirect to the equivalent page. A post goes to the same post at its new address, a category to the new category.
• Do not send everything to the home page. Google warns that redirecting many old URLs to one irrelevant page, such as the home page, can confuse users and might be treated as a soft 404.
• Let removed content go. If a page is deleted with no replacement, return 404 or 410 instead of redirecting it somewhere unrelated.
• Merged pages are the exception. If several old pages were combined into one new page, redirecting all of them to it is correct.

When the new URLs do not exist yet, map each old URL to the new page title and let a tool create the slug. Here is a real input for the redirect generator in Old → new title (slug) mode, with the path prefix /blog/ and the site URL https://example.com:

/blog/2019/05/10-tips-for-better-slugs -> 10 Tips for Better URL Slugs
/index.php?p=123 -> How to Bake Sourdough Bread at Home
/Blog/Summer_Sale_2024 -> Summer Sale, Up to 50% Off

The generator turns the titles into these targets with its default settings:

Have hundreds of rows in a CSV? The bulk CSV slug generator creates the slugs and the redirect column in one pass.

Write the rules in the format your server understands. These are the real outputs for the three redirects above.

Apache (.htaccess):

Redirect 301 /blog/2019/05/10-tips-for-better-slugs https://example.com/blog/10-tips-for-better-url-slugs
Redirect 301 /Blog/Summer_Sale_2024 https://example.com/blog/summer-sale-up-to-50-percent-off

RewriteEngine On
RewriteCond %{QUERY_STRING} ^p=123$
RewriteRule ^index\.php$ https://example.com/blog/how-to-bake-sourdough-bread-at-home? [R=301,L]

Apache's Redirect matches the start of the path, but only complete path segments, and the match is case-sensitive. Rules are processed in the order they appear and the first match wins, so put specific paths before broader ones. Redirect cannot see the query string, which is why /index.php?p=123 needs RewriteCond and RewriteRule. The trailing ? drops the old query string from the target.

Nginx:

location = /blog/2019/05/10-tips-for-better-slugs { return 301 https://example.com/blog/10-tips-for-better-url-slugs; }
if ($request_uri = "/index.php?p=123") { return 301 https://example.com/blog/how-to-bake-sourdough-bread-at-home; }
location = /Blog/Summer_Sale_2024 { return 301 https://example.com/blog/summer-sale-up-to-50-percent-off; }

location = is an exact match, so /Blog/Summer_Sale_2024/extra is not affected. Put these lines inside the right server block.

Cloudflare Bulk Redirects (CSV):

example.com/blog/2019/05/10-tips-for-better-slugs,https://example.com/blog/10-tips-for-better-url-slugs,301
example.com/index.php,https://example.com/blog/how-to-bake-sourdough-bread-at-home,301
example.com/Blog/Summer_Sale_2024,https://example.com/blog/summer-sale-up-to-50-percent-off,301

The CSV must not have a header row, and a URL that contains a comma must be wrapped in double quotes. Cloudflare source URLs cannot include a query string, so the second line matches every request to /index.php, whatever its parameters. If you have several ?p= URLs, handle them on your origin server with the Apache or Nginx rules instead.

A chain is a redirect whose target is redirected again: /old-a → /old-b → /new-c. Googlebot follows up to 10 hops, but Google advises redirecting to the final destination directly, and otherwise keeping chains to ideally no more than 3 and fewer than 5 hops. Chains add latency, and not every browser follows long chains.

Chains appear when an old redirect list meets a new one. Given these four lines:

/old-a -> /old-b
/old-b -> /new-c
/x -> /y
/y -> /x

the generator flags all three problem lines. With Flatten redirect chains turned on, it writes:

Redirect 301 /old-a /new-c
Redirect 301 /old-b /new-c
Redirect 301 /x /y
Redirect 301 /y /x

The first two are now direct redirects. /x → /y → /x is a loop: it can never resolve, so it cannot be flattened. The generator keeps both lines so you can see them and shows a "Redirect loop" warning for lines 3 and 4. Decide which URL is the real page and delete the other rule before you deploy.

Redirects catch old links from other sites. Everything you control should point to the new URLs directly:

• Internal links in navigation, body text and templates.
• Canonical tags: each new page should have a self-referencing rel="canonical".
• hreflang annotations on multilingual pages, in HTML or in the sitemap.
• XML sitemaps: list the new URLs. Google's site move guide also suggests submitting a sitemap of the old URLs, so you can watch them drop out of the index as the new ones replace them.
• Ads, emails and social profiles that link to old pages.

Search Console's Change of Address tool is only for moves from one domain or subdomain to another. You don't need it when paths change on the same domain.

Test the whole list, not a sample. This Bash script reads old_url,expected_url lines and checks that each old URL returns a 301 to the expected address, and that the target returns 200:

#!/usr/bin/env bash
# usage: ./check-redirects.sh redirects.csv   (lines: old_url,expected_url; no header)
fail=0
while IFS=, read -r old expected; do
  expected=${expected%$'\r'}
  read -r code location < <(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "$old")
  final=$(curl -s -o /dev/null -w '%{http_code}' "$expected")
  if [[ $code == 301 && $location == "$expected" && $final == 200 ]]; then
    echo "OK   $old"
  else
    echo "FAIL $old -> $code $location (target $final)"; fail=1
  fi
done < "$1"
exit $fail

Then inspect a few important URLs with the URL Inspection tool in Search Console to confirm that Google sees the redirect.

• Keep redirects for at least a year. Google recommends keeping them as long as possible, generally at least 1 year, so that all signals move to the new URLs. Keeping them forever is fine.
• Watch Search Console. Check the Pages report for new 404 and soft 404 errors, and compare the two sitemaps: indexed pages in the old-URL sitemap should fall toward zero while the new-URL sitemap rises.
• Expect some fluctuation. Rankings can move while Google recrawls. A few weeks or more is normal for a medium-sized site, and longer for large ones.

[ ] The change has a lasting benefit (not just a few characters shorter)
[ ] Old URLs collected from sitemap, CMS, logs, analytics and Search Console
[ ] Every old URL mapped to the closest new page; deleted pages return 404/410
[ ] No mass redirects to the home page
[ ] Rules generated for the right server (Apache, Nginx or Cloudflare)
[ ] Query-string URLs handled on the origin server
[ ] No chains (each old URL points to its final URL) and no loops
[ ] Internal links, canonical tags, hreflang and sitemap updated
[ ] Every redirect tested: 301 to the expected URL, target returns 200
[ ] No noindex or robots.txt block left on new pages
[ ] Redirects kept for at least 1 year; Search Console monitored

Use the bulk CSV slug generator to create new slugs from a spreadsheet of titles, then paste the old and new URLs into the 301 redirect generator to get Apache, Nginx or Cloudflare rules with chain and loop checks. For non-English titles, read how to transliterate slugs first, and see the URL slug SEO guide for what makes a good slug. Moving a WordPress site to a new permalink structure? See the WordPress permalink guide.

• Google Search Central: Redirects and Google Search
• Google Search Central: Site moves with URL changes
• Google Search Central: HTTP status codes and Google's crawlers
• Apache HTTP Server 2.4: mod_alias Redirect directive
• nginx: location directive
• Cloudflare: Bulk Redirects CSV file format