ChatGPT answers, unedited

If you’re talking about thousands to tens of thousands of 301 redirects, I’d avoid putting thousands of individual rules into functions.php or blindly generating a giant .htaccess file.

My recommendation

Best overall: use the Redirection plugin as the management layer, but move the actual redirects to the web server when your infrastructure allows it.

Redirection is specifically designed for sites with thousands of redirects and supports CSV import/export, WP-CLI, regex rules, 404 monitoring, and exporting rules for Apache/Nginx. Redirection WordPress.org

redirection.me

I'd structure it like this:

The important part: don't create 10,000 regex rules

If you have mappings like:

/old-blog/foo       → /blog/foo
/old-blog/bar       → /blog/bar
/old-blog/baz       → /blog/baz

don't necessarily create 3,000 independent rules. A single pattern such as:

^/old-blog/(.*)$ → /blog/$1

can replace them if the mapping is genuinely systematic.

This is usually the biggest performance and maintenance win.

For 5,000–50,000+ arbitrary redirects

This gets more interesting.

I'd use:

CSV/source-of-truth → automated import → redirect database → caching

rather than manually maintaining them in the WordPress UI.

Redirection supports CSV import/export and WP-CLI, which makes this approach practical. Redirection

Also, don't assume that "server-level = always faster." With thousands of rules, a huge sequential Nginx/Apache rule file can itself become inefficient. The Redirection developer specifically notes that 6,000 Nginx rules aren't necessarily faster than its database lookup approach. WordPress.org

For example, WP Engine currently recommends Redirection/Yoast rather than putting more than ~1,000 redirects into its Nginx configuration, citing performance/overhead concerns. WP Engine

What I'd choose by site size

< 5,000 redirects

→ Redirection plugin

Simple, reliable, searchable, importable, and easy for non-developers to maintain.

5,000–50,000 redirects

→ Redirection + WP-CLI/CSV as the source of truth

Use regex aggressively where appropriate, disable/limit unnecessarily long 404/redirect logging, and automate imports.

50,000+ redirects or extremely high traffic

→ Consider moving the lookup outside WordPress entirely, ideally into an edge/CDN or optimized server-level lookup structure.

At that scale, I'd want the redirect decision made before PHP/WordPress is bootstrapped.

One thing I would not do

I wouldn't install a big SEO plugin just because it has a redirect manager if redirects are its only purpose. A dedicated redirect manager gives you a cleaner architecture.

Likewise, I wouldn't put something like this into functions.php:

if ($_SERVER['REQUEST_URI'] === '/old-url') {
    wp_redirect('/new-url', 301);
    exit;
}

Doing that thousands of times turns your redirect system into application code and makes deployment, auditing, importing, testing, and rollback unnecessarily painful.

My preferred architecture

For a serious WordPress site, I'd aim for:

Redirect CSV / migration data
          ↓
       WP-CLI
          ↓
   Redirection database
          ↓
   cached/indexed lookup
          ↓
       301 response

And separately:

404 monitoring
      ↓
identify legitimate old URLs
      ↓
add only useful redirects
      ↓
periodically remove obsolete rules

That last part matters: don't let your redirect database become a permanent dumping ground.

If you tell me roughly how many redirects you have (e.g. 5k / 50k / 500k), whether you're on Apache, Nginx, LiteSpeed, Cloudflare, etc., and whether the redirects are mostly 1-to-1 or pattern-based, I can recommend the exact architecture I'd use and how I'd implement it.

For thousands of redirects, I’d avoid treating WordPress itself as the first layer if performance is the priority.

My recommendation

Best overall architecture:

1. Put the redirects at the web-server/CDN layer
Use Nginx, Apache, Cloudflare, or your host’s edge redirect system for the bulk of your permanent redirects.

2. Use a WordPress redirect plugin only for redirects you actually need to manage in WordPress.

That means:

CDN/server → bulk/static redirects
WordPress → exceptions, temporary redirects, 404 discovery, editorial management

This keeps redirect processing out of PHP/WordPress for the vast majority of requests.

If you want a WordPress plugin

My first choice is Redirection.

It is specifically designed for sites with thousands of redirects, supports regex, bulk import/export, CSV, WP-CLI, and can export redirects to Apache .htaccess or Nginx configuration. wordpress.org

The particularly useful part for a large site is that you don't necessarily have to leave the redirects running through WordPress. Redirection can generate server-level rules, which is much better for high-volume traffic. wordpress.org

What I'd choose at different scales

Important performance consideration

I would not put thousands of individual redirects into WordPress's rewrite_rules system. WordPress stores its rewrite rules as a cached rewrite_rules option, and those rules are fundamentally part of the WordPress permalink machinery. developer.wordpress.org

For example, I'd rather have:

old-site.com/product-a → /products/a
old-site.com/product-b → /products/b
old-site.com/product-c → /products/c
...

handled by Nginx/Apache/CDN than have every request enter WordPress and query a redirect system.

Don't overlook redirect logs

At scale, 404/redirect logging can become a bigger maintenance problem than the redirects themselves. Redirection records redirect/404 data and supports configurable logging; its documentation specifically includes bulk management and log handling. wordpress.org

For a high-traffic site I'd therefore:

• Keep redirect rules permanently.
• Keep 404/redirect logs for a limited retention period.
• Export/analyze logs periodically.
• Remove obsolete redirect chains.
• Avoid A → B → C; make it A → C.
• Prefer exact rules over giant regexes where practical.
• Don't redirect everything to the homepage.
• Use 301 for genuinely permanent moves.

What about Yoast?

If you're already heavily invested in Yoast SEO, its redirect manager is a reasonable choice. Yoast explicitly supports scaling with regex and can write redirects directly to Apache or Nginx configuration. yoast.com

I wouldn't install Yoast just for redirects, though. If redirects are the main requirement, Redirection is the cleaner choice.

My preferred setup

For a large production WordPress site, I'd build it like this:

                    ┌── CDN / Edge
Incoming request ───┤       ↓
                    │   Redirect? ── YES → 301
                    │
                    └── Web server
                            ↓
                       WordPress
                            ↓
                  Redirection plugin
                  (exceptions / 404s)

Then maintain the redirects from a CSV/database/source-of-truth, rather than manually maintaining thousands of entries in wp-admin.

If you tell me roughly how many redirects you have (e.g. 5k, 50k, 500k), whether you're on Nginx/Apache/Cloudflare, and whether they are mostly exact URLs or regex/pattern-based, I can recommend the architecture I'd use and how I'd structure the redirect database/import process.

If you're talking about thousands of redirects, I’d avoid treating this like a normal “install a redirect plugin and add rules” problem. The best architecture depends mainly on where the redirect is executed.

My recommendation

Best for performance: put redirects at the web-server/CDN layer whenever possible.

Best WordPress-native option: Redirection.

Best if you already use Rank Math: use its built-in Redirect Manager rather than adding another plugin. It supports bulk CSV import/export and regex/pattern rules. rankmath.com

Best developer-oriented lightweight option: Safe Redirect Manager, although I'd be cautious with it for many thousands because its documented default limit is 1,000 redirects unless you raise it with a filter. wordpress.org

How I'd architect thousands of redirects

The important distinction is that a PHP/WordPress redirect happens after the request has already reached WordPress. A server/CDN redirect can terminate the request before WordPress, PHP, the theme, and most plugins execute.

For example, instead of thousands of individual rules:

/old-products/foo  → /products/foo
/old-products/bar  → /products/bar
/old-products/baz  → /products/baz
...

I'd look for an opportunity to collapse them into a pattern:

/old-products/(.*) → /products/$1

One good regex/prefix rule can replace thousands of database entries.

If you need the redirects inside WordPress

I'd pick Redirection.

It is specifically designed for sites ranging from a handful of redirects to thousands, supports regex, groups, import/export, and caching, and is actively maintained. wordpress.org

One thing I'd pay attention to is its 404 logging. On a high-traffic site, don't let an enormous 404 history become a permanent database workload. Use logging for discovery/auditing, then prune or disable it once the migration is stable.

For a serious migration, I'd do this

1. Normalize your redirect dataset in CSV/database first.
2. Eliminate duplicate rules and redirect chains.
3. Collapse repetitive redirects into prefix/regex rules wherever safe.
4. Put the highest-volume/simple rules at the CDN/server layer.
5. Keep WordPress/Redirection for exceptions and ongoing editorial redirects.
6. Make sure every redirect goes directly to the final URL:

A → C, not A → B → C.

7. Monitor hits and periodically remove redirects that are no longer receiving traffic.
8. Test the complete redirect set on staging before deploying.

For 10,000–100,000+ redirects, I'd strongly favor a server/CDN-based implementation rather than making WordPress/PHP evaluate tens of thousands of rules on every request.

If you tell me your hosting stack (Cloudflare, Nginx, Apache/LiteSpeed, Kinsta, WP Engine, etc.) and roughly how many redirects (5k / 20k / 100k+), I can recommend the exact architecture and show you how I'd structure the rules.

If you're talking thousands of redirects—say 5,000–50,000+—I would not treat this as a normal “install a redirect plugin” problem. The best architecture depends on where you can execute the redirect.

My recommendation

Best for performance: put the redirects at the web-server/CDN layer, not inside WordPress.

Best WordPress-native option: Redirection.

Redirection on WordPress.org specifically says it is designed for sites ranging from a few redirects to thousands of redirects, and supports regex, groups, import/export, and 404 monitoring. wordpress.orgrankmath.com

I'd rank the approaches like this:

1. If performance is the priority: server/edge

For a site with, for example, 20,000+ static redirects, I'd prefer:

CDN → web server → WordPress

rather than:

CDN → WordPress → redirect plugin → database

The request can be redirected before WordPress/PHP loads at all. This is especially attractive if the redirects are permanent and don't need WordPress-specific logic.

For example, if you're on Nginx, a large set of redirects can be handled through an appropriate map/configuration rather than making WordPress inspect thousands of rules.

This also makes redirect performance essentially independent of WordPress/PHP load.

2. If you need to manage them from WordPress: Redirection

This is my default recommendation.

Redirection plugin

It's mature, free, actively maintained, supports thousands of redirects, regex, groups and import/export. wordpress.orgrankmath.com

The important thing is to configure it sensibly:

• Use exact-match rules wherever possible.
• Use regex/wildcards for patterns, rather than creating thousands of nearly identical rules.
• Avoid unnecessary 404 logging if you don't actually need it.
• Keep redirect chains to a minimum.
• Periodically remove obsolete rules.
• Keep your redirects in a CSV/source-of-truth as well as in WordPress if they're business-critical.
• Test the import and redirect behavior on staging before changing thousands at once.

Redirection's own documentation says its implementation is designed similarly to WordPress's permalink handling and shouldn't cause noticeable slowdown. en-gb.wordpress.org

3. Safe Redirect Manager is interesting, but I'd choose it selectively

Safe Redirect Manager is built by 10up and is explicitly designed with scalability in mind. It stores redirects as custom post types and caches redirect data. wordpress.org

However, there's an important catch for your use case:

It defaults to a maximum of 1,000 redirects to prevent performance problems.

You can raise that limit with the srm_max_redirects filter. wordpress.org

So if you have 2,000–10,000+ rules, I'd lean toward Redirection unless you have a specific reason to use Safe Redirect Manager.

The architecture I'd use for a large site

If I were designing this for a site with, say, 10,000–100,000 redirects, I'd do:

                    ┌── Redirect? ──→ 301
                    │
Request
   │
   ▼
CDN / Edge
   │
   │ no match
   ▼
Nginx / Apache
   │
   │ no match
   ▼
WordPress

Put large, stable redirect sets at the edge/server, and reserve WordPress's redirect system for redirects that editors actually need to manage.

That gives you the best of both worlds:

• extremely fast redirects
• no PHP execution for redirected requests
• less database work
• WordPress admin for the exceptions
• easier migration/version control
• fewer opportunities for a redirect plugin to become a bottleneck

One thing I'd avoid

Don't install multiple redirect systems simultaneously—e.g. Redirection + Rank Math redirects + server redirects—with overlapping rules.

That's a maintenance nightmare and makes debugging chains/loops unnecessarily difficult.

If you're already using Rank Math, its built-in redirect manager is also worth considering rather than adding another plugin; Rank Math provides a dedicated redirect manager and advertises it as lightweight/optimized for speed. rankmath.com

Bottom line

For most WordPress sites with thousands of redirects:

→ Redirection plugin

For tens of thousands or extremely high-traffic sites:

→ CDN/Nginx/Apache redirects + WordPress for exceptions

For a developer-managed/enterprise WordPress installation:

→ server/edge redirects, with redirects maintained from a version-controlled CSV/config rather than treating WordPress as the primary routing layer.

If you tell me roughly how many redirects (5k, 20k, 100k+), your hosting stack (Cloudflare/Nginx/Apache/LiteSpeed), and whether they're mostly one-to-one or pattern-based, I can recommend a specific architecture and migration strategy.

If you’re talking thousands of redirects, I’d avoid treating them like a normal WordPress plugin setting. The best architecture is to keep redirects out of the normal WordPress page-generation path whenever possible.

My recommendation

Best overall: use a dedicated redirect manager such as Redirection, but structure the rules intelligently and put repeated patterns into regex rules rather than thousands of individual entries.

Redirection plugin

Redirection currently has 2M+ active installations, supports import/export, regex, redirect groups, and 404 monitoring. Its developers specifically state that it is designed to handle redirects without noticeable slowdown, and recent versions include caching and improvements for large numbers of redirects. wordpress.org

For several thousand, though, I'd use this hierarchy:

The important trick: consolidate rules

Suppose you have:

/old-product-1/ → /products/product-1/
/old-product-2/ → /products/product-2/
/old-product-3/ → /products/product-3/
...

Don't necessarily create 5,000 independent rules.

If the URL structure allows it, one regex can potentially handle the entire family:

^/old-(.*)/$
→ /products/$1/

That can turn thousands of rules into dozens or even a handful. This is particularly important with server-level redirects: WP Engine, for example, explicitly recommends consolidating rules with regex and warns that very large rule sets can introduce overhead. wpengine.com

If you have 5,000–100,000+ truly unique redirects

Then I'd seriously consider a dedicated lookup layer rather than a giant .htaccess/Nginx file.

Conceptually:

Request
   ↓
CDN / web server
   ↓
redirect lookup
   ↓
301 if match
   ↓
WordPress only if no redirect

The key is that a request that needs a redirect shouldn't have to bootstrap all of WordPress just to discover that it needs a redirect.

For example, a custom redirect service/table can have:

source_path (indexed) → destination_url

and perform a very cheap indexed lookup.

There are also newer lightweight WordPress redirect plugins built around indexed database lookups/caching; for example, RationalRedirects advertises indexed lookups and transient caching, while Blaze Redirects uses a cache-first approach. wordpress.org

I'd still favor Redirection for a production site unless you've benchmarked one of these newer options on your actual workload.

What I'd do in your situation

If this were my WordPress site:

<1,000
→ Redirection plugin is an easy choice.

1,000–10,000
→ Redirection + aggressive consolidation with regex. Keep the rules organized into logical groups and periodically remove dead/unused redirects.

10,000–100,000+ unique URLs
→ I'd move the redirect lookup outside WordPress if the hosting/CDN supports it, or build a purpose-specific indexed redirect layer.

Migration with thousands of old URLs
→ Keep the master list in CSV/Google Sheets/Git, rather than making WordPress the canonical source of truth. Import it into the redirect system. That makes audits, deduplication, redirects-to-redirects, and future migrations much easier.

One particularly useful point: don't blindly put thousands of rules into server configuration just because it's theoretically faster. WP Engine currently recommends its Redirection plugin for >1,000 redirects because very large server rule sets can themselves become inefficient. wpengine.com

My preferred architecture

For a serious site with, say, 10,000+ redirects:

                 ┌── CDN/edge redirects
Request ─────────┤
                 └── WordPress redirect manager
                          │
                          ↓
                     WordPress

Then use regex/pattern rules for families of URLs and individual database rules only where URLs genuinely don't follow a pattern.

If you tell me roughly how many redirects you have (e.g. 3k, 20k, 100k), what hosting/CDN you're on (Cloudflare, WP Engine, Kinsta, Nginx, Apache, etc.), and whether they're mostly unique URLs or follow patterns, I can recommend the exact architecture I'd use and how I'd structure/import the rules.

If you're talking about thousands of redirects, I would not optimize primarily for the admin UI. The important question is where the redirect is executed.

My recommendation

Best overall architecture:

Put the bulk of redirects at the web-server/CDN layer, and use WordPress only for redirects that genuinely need WordPress logic.

For example:

Cloudflare/CDN → Nginx/Apache → WordPress

If you have 5,000–50,000 simple old URL → new URL mappings, handling them before PHP/WordPress is substantially preferable. A request that can be redirected without booting WordPress avoids PHP, plugins, database queries, and most of the WordPress stack entirely.

For redirects that must live inside WordPress, my first choice would be Redirection. Its documentation specifically says it's designed for sites ranging from a few redirects to thousands, and it supports regex and bulk import/export. Its current 5.9 release also improved bulk import/export and .htaccess support. redirection.mewordpress.org

Plugin comparison

One caveat with Safe Redirect Manager: its default maximum is 1,000 redirects, specifically to prevent performance problems, although that limit can be increased with a filter. It stores rules as a custom post type and caches them using the Transients API. wordpress.org

Redirection is more attractive for your use case because it has mature bulk-management functionality and is explicitly designed to scale to thousands. redirection.mewordpress.org

What I'd actually implement

If this were a site I was responsible for, I'd use a three-tier strategy:

1. Exact, permanent redirects → CDN/server
   • old-product-a → new-product-a
   • old-category/foo → new-category/foo
   • thousands of migration mappings
   • 301s that don't need WordPress/database information

2. Pattern redirects → regex/server rules
   • /old-blog/(.*) → /blog/$1
   • old directory structures
   • language/path migrations
   • anything where 1 rule replaces hundreds/thousands of individual rules

3. WordPress Redirection → exceptions and ongoing editorial redirects
   • redirects created when editors change slugs
   • occasional manual redirects
   • 404 investigation
   • redirects requiring WordPress-aware logic

That gives you a much cleaner separation between infrastructure redirects and content-management redirects.

One thing I'd avoid

I wouldn't put 10,000 individual redirect records into a plugin just because the plugin technically allows it.

Even if the redirect lookup itself is reasonably fast, you're increasing the amount of data WordPress has to manage, migrate, back up, query in admin, and potentially load into caches.

Instead, look for opportunities to turn:

/old/category/product-001 → /products/product-001
/old/category/product-002 → /products/product-002
/old/category/product-003 → /products/product-003
...
/old/category/product-5000 → /products/product-5000

into one pattern rule.

If you want everything managed from WordPress

Then I'd choose Redirection over Safe Redirect Manager for this particular requirement.

It has mature import/export, regex, 404 monitoring, and bulk management, while its own documentation explicitly positions it for sites with thousands of redirects. redirection.mewordpress.org

If you're already running Rank Math, its redirect manager is also reasonable and supports CSV import/export, so there's little reason to add another plugin just for redirects. rankmath.com

Bottom line:
Thousands of simple redirects: CDN/Nginx/Apache.
Thousands but must be WordPress-managed: Redirection.
Lots of repetitive URL migrations: use regex/patterns rather than individual rules.
Don't enable permanent 404 logging indefinitely on a high-traffic site—logs can become a much bigger database-maintenance problem than the redirects themselves.

If you tell me roughly how many redirects (5k / 50k / 500k), whether you're on Cloudflare, and whether the server is Nginx or Apache, I can recommend the exact architecture and storage format I'd use.

For thousands of redirects, I would not make WordPress/PHP the primary redirect layer if performance is the priority.

My preferred architecture

1. Put the large redirect map at the edge — Cloudflare Bulk Redirects
If you're already using Cloudflare, this is my first choice. The request can be redirected before it reaches your WordPress/PHP stack, which avoids loading WordPress just to issue a 301. Cloudflare specifically recommends Bulk Redirects for large numbers of static redirects. developers.cloudflare.com

Current quotas are quite generous: Free: 10,000, Pro: 25,000, Business: 50,000, and Enterprise: 1,000,000 redirect URLs across lists. developers.cloudflare.comdevelopers.cloudflare.com

It also supports API management, so you can maintain redirects from a CSV/database/Git repo rather than manually editing thousands of entries. developers.cloudflare.com

2. Use a WordPress redirect plugin for the WordPress-specific redirects
My default recommendation is Redirection plugin.

It's mature, widely used, supports import/export, regex, 404 monitoring, automatic redirects when permalinks change, and has caching/performance improvements. wordpress.org

I'd use it for things like:

• Redirects created as content gets renamed
• Editorial/manual redirects
• Regex rules
• 404 discovery
• Smaller sets of redirects that genuinely belong to WordPress

I wouldn't dump 50,000+ static mappings into WordPress simply because the plugin can technically manage them.

What about .htaccess / Nginx?

For a self-hosted site, this is actually an excellent performance option.

For Apache:

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

For Nginx:

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

These happen at the web-server layer, before WordPress executes.

The downside is maintenance. Thousands of individual rules become cumbersome unless you generate the configuration from a canonical redirect file. I prefer this approach when you control the server and have deployment automation.

What I would choose

The architecture I'd recommend

For a serious site, I'd actually use two layers:

                    Request
                       │
                       ▼
              ┌─────────────────┐
              │    Cloudflare   │
              │ Bulk Redirects  │
              └────────┬────────┘
                       │
              redirect match?
                 /          \
               YES           NO
                │             │
                ▼             ▼
             301/308      WordPress
                              │
                              ▼
                       Redirection plugin
                              │
                              ▼
                            301

Put your large, static migration map at Cloudflare/server level, and leave WordPress's Redirection plugin for the smaller, dynamic/editorial layer.

This also gives you a much cleaner operational model: maintain the master redirect list in CSV/Git/database → validate it → push it to Cloudflare via API, rather than having thousands of rows living inside WordPress.

One important caveat: Cloudflare Bulk Redirects are designed for static mappings and don't support regex/string replacement; for more complex redirect logic, Cloudflare points toward other mechanisms such as Snippets. developers.cloudflare.comdevelopers.cloudflare.com

If you tell me roughly how many redirects you have (e.g. 5k, 50k, 500k), whether you're on Apache or Nginx, and whether you're using Cloudflare, I can recommend the exact architecture and data format I'd use.

For thousands of WordPress redirects, I’d avoid treating the redirect plugin as the actual request-routing layer if performance is a priority.

My recommendation

Best overall architecture:

1. Put the bulk of redirects at the edge/server level
   • Cloudflare Bulk Redirects if you use Cloudflare
   • Nginx rules/maps if you control Nginx
   • Apache .htaccess if you're on Apache and don't have a better edge/server option
2. Use a WordPress plugin for redirects that need WordPress awareness
   • My first choice: Redirection plugin
3. Keep the WordPress database/plugin layer for exceptional or frequently changing redirects, rather than thousands of permanent rules.

The reason is simple: a server/edge redirect can happen before WordPress/PHP boots. WordPress's own documentation describes Nginx as the server layer and notes that WordPress itself cannot modify Nginx configuration. developer.wordpress.org

If you want a plugin-only solution

I'd choose Redirection over using a full SEO plugin purely for redirect management.

Its current documentation specifically says it's designed for sites ranging from a few redirects to thousands, and it supports importing/exporting redirects and managing 404s. en-gb.wordpress.org

That's particularly attractive for maintenance because you can keep your redirect inventory in CSV form and bulk-import/manage it rather than maintaining thousands of individual pieces of code.

Rank Math is also capable: its redirect manager supports bulk actions, CSV import/export, organization/categories, and redirect statistics. rankmath.com I'd use it if you're already heavily invested in Rank Math; I wouldn't install Rank Math solely to get redirects.

What I'd do at different scales

For thousands of static 301s, I'd particularly favor an edge/server solution. Nginx, for example, handles routing at the web-server level rather than requiring WordPress/PHP to process the request. developer.wordpress.org

One important maintenance rule

Don't create chains like:

/old-url → /old-url-2 → /new-url

Instead make every legacy URL point directly to the final URL:

/old-url → /new-url

For a large migration, I'd maintain a master CSV such as:

old_url,new_url,status
/old/product-a,/products/product-a,301
/old/product-b,/products/product-b,301

Then have one authoritative redirect inventory, rather than rules scattered across WordPress, .htaccess, Nginx, Cloudflare, and multiple plugins.

If you tell me your hosting stack (Cloudflare + Nginx, Apache, LiteSpeed, WP Engine, Kinsta, etc.) and roughly how many redirects you have (2k / 10k / 100k), I can recommend the exact architecture and where I'd store the redirect list.

For thousands of redirects, I would not make WordPress the first layer if performance is a priority.

My recommendation

Best architecture: Cloudflare Bulk Redirects → WordPress only for exceptions.

If you're already using Cloudflare, put the large static redirect map there. Cloudflare evaluates Bulk Redirects before the request reaches your origin, so redirected requests never need to execute WordPress/PHP. It is specifically designed for large numbers of redirects and currently supports up to 10,000 on Free, 25,000 on Pro/Business, and 1,000,000 on Enterprise by default. developers.cloudflare.comdevelopers.cloudflare.com

Cloudflare Bulk Redirects documentation

I'd structure it roughly like this:

                         ┌─ Cloudflare Bulk Redirects
Incoming request ────────┤   thousands of static 301s
                         │
                         └─ WordPress
                              └─ dynamic/special-case redirects

If you need a WordPress plugin

My first choice would be Redirection.

It is specifically designed for sites ranging from a handful of redirects to thousands, supports redirect groups/import/export, regex, 404 monitoring, and has been around for many years. redirection.me

Redirection plugin

For a site with 5,000–50,000+ redirects, however, I'd be more inclined to keep the bulk of them outside WordPress.

What I'd avoid

Don't put thousands of individual wp_redirect() rules into functions.php.

Likewise, I'd avoid creating a giant chain of rules that requires WordPress to bootstrap on every request. Even if the redirect lookup itself is reasonably optimized, you're still bringing PHP/WordPress into the request path.

Also avoid redirect chains:

/old-page → /older-page → /new-page

Prefer:

/old-page → /new-page

This matters for both performance and SEO.

A good maintenance model

For a large site migration, I'd maintain a canonical CSV:

source,target,status
/old-product-a,/products/product-a,301
/old-product-b,/products/product-b,301
/old-category,/categories/new-category,301

Then:

1. Keep the CSV in version control (Git).
2. Validate it for duplicate sources, loops, chains, and missing destinations.
3. Import/deploy it to Cloudflare Bulk Redirects.
4. Keep WordPress Redirection for redirects generated organically as content changes and for 404 investigation.
5. Periodically remove obsolete redirects after verifying they're no longer receiving meaningful traffic.

Cloudflare's Bulk Redirect Lists are particularly useful here because they can be managed as a distinct collection and populated from CSV/API workflows. developers.cloudflare.com

One important distinction

If your thousands of redirects are mostly pattern-based, don't create thousands of entries at all.

For example, if you have:

/old-blog/foo → /blog/foo
/old-blog/bar → /blog/bar
/old-blog/baz → /blog/baz
...

one wildcard/pattern redirect may replace thousands of individual redirects. Cloudflare's Single Redirects support wildcard-based patterns, while Bulk Redirects are intended primarily for static individual mappings. developers.cloudflare.comdevelopers.cloudflare.com

So my ranking would be:

If you tell me roughly how many redirects you have (e.g. 5k, 50k, 500k), whether you're on Cloudflare, and whether they're mostly one-to-one or pattern-based, I can recommend the exact architecture and deployment workflow.

For thousands of redirects, I’d avoid treating WordPress as the first layer if performance is the priority.

My recommendation

Best overall architecture:

1. Put simple, high-volume redirects at the web-server/CDN layer
   • Nginx return/rewrite
   • Apache .htaccess
   • Cloudflare Redirect Rules / Bulk Redirects
   • This is fastest because the request can be redirected before WordPress/PHP loads.
   • Particularly attractive if you have tens of thousands of static redirects.

2. Use a WordPress redirect manager for the exceptions
   • My first choice: Redirection
   • It explicitly supports sites ranging from a few redirects to thousands, and its documentation says it operates similarly to WordPress's permalink handling without noticeable slowdown. wordpress.org
   • It has import/export and regex functionality, making it practical for maintaining a large rule set.

3. If you're already using Rank Math, use its redirect manager instead of adding another plugin
   • Rank Math supports regex redirects and bulk management. rankmath.com
   • Rank Math Pro adds CSV import/export specifically for creating, editing, and deleting redirects at scale. rankmath.com
   • It can also import redirects from the Redirection plugin if you migrate later. rankmath.com

What I'd choose by scale

The important performance distinction

Suppose you have:

/old-product-1 → /products/product-1/
/old-product-2 → /products/product-2/
/old-product-3 → /products/product-3/
...

I'd rather have those handled by the server/CDN than have every request reach:

Web server
   ↓
PHP
   ↓
WordPress
   ↓
Redirect plugin
   ↓
Database lookup
   ↓
301 response

At scale, that PHP/database work is unnecessary.

Even better, if your migration follows a pattern, collapse thousands of rules into one:

/old-category/(.*) → /new-category/$1

rather than maintaining 5,000 individual mappings.

Maintenance matters more than the plugin

For a large migration, I'd maintain the redirects in a CSV/database as the canonical source, something like:

source,destination,type,reason
/old-page-1,/new-page-1,301,migration
/old-page-2,/new-page-2,301,migration

Then generate/deploy the server/CDN rules from that dataset.

That gives you version control, deduplication, auditing, bulk changes, and an easy rollback. The WordPress admin becomes the exception-management interface rather than your primary redirect database.

One thing I'd strongly avoid: installing multiple redirect plugins simultaneously. Having Redirection + Rank Math + another SEO plugin all independently managing redirects can make debugging chains and loops unnecessarily difficult.

If you tell me your approximate redirect count (e.g. 5k, 50k, 500k), hosting stack (Nginx/Apache/Cloudflare), and whether these are mostly one-off URLs or predictable patterns, I can recommend the exact architecture and configuration I'd use.

For thousands of WordPress redirects, I’d avoid making WordPress/PHP the first layer if performance is a priority.

My recommendation

Best overall architecture:

CDN / web server → redirect rules → WordPress only if necessary

For example:

1. Server/CDN-level redirects for your large, stable redirect set.
2. A WordPress redirect plugin for redirects editors need to create/change frequently.
3. Periodically consolidate and remove obsolete/duplicate redirects.

That keeps the bulk of requests from booting WordPress at all.

What I'd choose

The Redirection plugin is particularly attractive if you want a dedicated WordPress solution. It's mature, supports import/export, redirect logs and automatic redirects when URLs change, and its authors state that it operates similarly to WordPress's permalink handling without a noticeable slowdown. wordpress.org

Redirection plugin

If you're already running Rank Math, I wouldn't add another plugin just for redirects. Its redirect manager supports regex, bulk handling, categories, and exporting rules to .htaccess or Nginx configuration—which is useful if you eventually move the rules out of WordPress. rankmath.com

Rank Math Redirections

For 5,000–50,000+ redirects

At that scale, I'd strongly favor server/CDN-level rules.

For example, instead of:

old-url → WordPress → PHP → redirect plugin → 301

you want:

old-url → Nginx/Apache/CDN → 301

The request can terminate before WordPress/PHP is involved. WordPress officially supports Nginx deployments, including configurations where Nginx sits in front of Apache. developer.wordpress.org

If you're on Cloudflare, that's also an excellent place to put large redirect sets, particularly when you can express many redirects as patterns rather than thousands of individual rules.

The really important part: don't create 10,000 individual rules unnecessarily

If your redirects have patterns, collapse them.

For example, instead of:

/old/products/widget-a → /products/widget-a
/old/products/widget-b → /products/widget-b
/old/products/widget-c → /products/widget-c
...

use one pattern equivalent to:

/old/products/(.*) → /products/$1

Likewise, consolidate migrations such as:

/blog/2020/foo → /foo
/blog/2021/bar → /bar
/blog/2022/baz → /baz

into a pattern where the mapping is genuinely predictable.

Don't use regex just because you can, though. Explicit mappings are safer when the old → new relationship isn't deterministic.

Maintenance matters more than raw plugin speed

For a large redirect database, I'd establish these rules:

• 301 for permanent migrations.
• Avoid redirect chains: A → B → C; make it A → C.
• Avoid loops.
• Don't redirect everything to the homepage.
• Keep a canonical source of truth, preferably CSV/Git/database/config, rather than having redirects scattered across multiple plugins.
• Periodically identify redirects receiving no traffic and determine whether they're still needed.
• Test the entire redirect set after major migrations.
• Don't run two or three redirect plugins simultaneously.
• Use regex/pattern rules for genuinely systematic migrations.
• Put the highest-volume/most performance-sensitive redirects at the CDN/server layer.

There is good reason to care about chains: research analyzing millions of real-world redirects found substantial failure and multi-hop behavior, so keeping your redirect graph simple is worthwhile. arxiv.org

My preferred setup

If this were my site, I'd do:

Cloudflare/CDN
→ high-volume and permanent bulk redirects

Nginx/Apache
→ remaining infrastructure-level redirects

Redirection plugin
→ editorial/SEO team-managed exceptions and new redirects

CSV/Git
→ master migration dataset and change history

That gives you very fast requests + easy WordPress administration + an auditable source of truth.

If you tell me roughly how many redirects you have (e.g. 5k, 50k, 500k), whether you're on Apache or Nginx, and whether you use Cloudflare, I can recommend the exact architecture and storage format I'd use.

If you're talking about thousands of 301/308 redirects, I would not make WordPress/PHP the first layer that handles them. For performance and long-term maintenance, the best architecture is:

My recommendation

1. Put the redirects at the web-server/CDN layer

• Nginx: use a map/generated redirect map rather than thousands of individual rewrite rules.
• Apache: use a carefully managed redirect map or generated rules, but avoid an enormous .htaccess if you can configure the vhost/server directly.
• Cloudflare or another edge/CDN: even better if your traffic already goes through it; redirects can happen before the request reaches WordPress.

This means a request for an old URL can be redirected without booting WordPress/PHP at all, which is the biggest performance advantage.

2. Keep a WordPress redirect manager for editorial/operational work
If your team needs to add, inspect, import, or audit redirects inside WordPress, Redirection is my first choice. It supports bulk management and regex and is specifically focused on redirects rather than being bundled into a large SEO plugin. oddjar.com

Redirection — WordPress plugin

3. Don't use the WP plugin as the runtime for 10,000+ high-traffic redirects if you can avoid it.

The distinction is important:

Current comparisons also generally put Redirection among the strongest dedicated WordPress options, while Rank Math is reasonable if you're already using it for SEO. oddjar.com

The architecture I'd use for 10,000+ redirects

I'd actually separate storage/management from execution:

redirect.csv / database
        ↓
validation + deduplication
        ↓
generated redirect map
        ↓
CDN / Nginx
        ↓
301/308 response

Then WordPress can have a smaller set of redirects for things editors need to manage dynamically.

For example:

/old-product-a → /products/product-a
/old-product-b → /products/product-b
/old-category → /category/new-category

Those thousands of mappings can be generated into a server/CDN-native format rather than making every request go through WordPress.

The really important part: prevent redirect chains

With thousands of redirects, redirect quality becomes more important than the plugin choice.

You don't want:

/old-url
   ↓ 301
/middle-url
   ↓ 301
/new-url

You want:

/old-url
   ↓ 301
/new-url

Large-scale redirect datasets can accumulate chains and loops surprisingly easily; research analyzing millions of real-world redirecting URLs found substantial numbers of problematic redirect paths. arxiv.org

I'd therefore have an automated process that checks:

• duplicate source URLs
• redirect loops
• chains
• redirects pointing to 404s
• redirects pointing to another redirect
• source/target normalization
• HTTP → HTTPS duplication
• trailing-slash inconsistencies
• case sensitivity
• unnecessary redirects
• temporary vs permanent status codes

What I'd choose

If you tell me what hosting stack you're on (Cloudflare, Nginx, Apache, LiteSpeed, WP Engine, Kinsta, Cloudways, etc.) and roughly whether we're talking 5,000, 50,000, or 500,000 redirects, I can recommend the exact architecture and show you how I'd structure/import the redirect database without slowing WordPress down.

For thousands of redirects, I’d separate the question into two layers:

1. Where should the rules live?
2. How should you maintain them?

My recommendation

Best overall architecture: server-level redirects + WordPress as the management/source-of-truth layer.

If performance is the priority, you generally want redirects handled before WordPress boots. Every redirect that reaches PHP/WordPress means loading WordPress just to return a 301.

For example:

Nginx

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

Apache

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

This is the fastest approach, particularly if you have tens of thousands of rules.

The downside is maintainability: manually editing Nginx/Apache configuration isn't pleasant.

If you want a WordPress plugin: Redirection

My first choice would be Redirection.

It's specifically designed for sites ranging from a handful of redirects to thousands, and importantly it supports:

• CSV import/export
• WP-CLI automation
• regex redirects
• redirect groups
• 404 monitoring
• Apache .htaccess export
• Nginx rule export
• migration from several other redirect plugins wordpress.orgredirection.me

The particularly interesting part for your use case is that you can use Redirection as the management layer, but move the actual high-volume rules to the web server. Its documentation explicitly supports saving redirects to .htaccess for Apache and exporting Nginx rules. wordpress.orgredirection.me

I'd choose this if you want a practical, maintainable WordPress-based workflow.

What about Safe Redirect Manager?

Safe Redirect Manager is another good option, particularly for enterprise sites.

It stores redirects as custom post types and uses transient caching. However, there's an important caveat: it defaults to a maximum of 1,000 redirects specifically to avoid performance problems, although that limit can be increased with a filter. wordpress.org

So for several thousand redirects, I would favor Redirection unless you have a particular reason to use Safe Redirect Manager.

What I would avoid

I wouldn't make a giant PHP array like this your primary solution:

$redirects = [
    '/old-url-1' => '/new-url-1',
    '/old-url-2' => '/new-url-2',
    // ...
];

It can be fast enough with good implementation, but you've now created a custom redirect system that you have to maintain, deploy, test, and protect from regressions.

Likewise, I'd avoid plugins that continuously log every 404 request on a high-traffic site. The redirect matching itself may be cheap, while an enormous 404 log can become the unnecessary database workload.

The architecture I'd use

For a site with, say, 5,000–100,000 redirects:

                    Request
                       │
                       ▼
              CDN / Edge / WAF
                       │
                       ▼
              Nginx / Apache
                 │           │
            redirect       no match
                 │           │
                 ▼           ▼
              301/308     WordPress
                              │
                              ▼
                           content

Then maintain the rules from a CSV/Git-controlled source:

redirects.csv
     │
     ▼
validation / deduplication
     │
     ▼
generated Nginx/Apache rules
     │
     ▼
deploy

That gives you server-level performance + centralized maintenance + version control.

Redirection can be useful as the WordPress-facing management/import/export tool, while the production redirect path stays outside PHP. Its WP-CLI and CSV capabilities make that workflow particularly practical. wordpress.org

One important optimization: consolidate patterns

Don't create 5,000 individual rules if they can be represented by 20 patterns.

For example, instead of:

/blog/foo     → /articles/foo
/blog/bar     → /articles/bar
/blog/baz     → /articles/baz
...

use a single regex/wildcard rule where appropriate:

/blog/(.*)    → /articles/$1

That can make the rule set dramatically easier to maintain.

My ranking

If you tell me roughly whether you're on Nginx, Apache/LiteSpeed, Cloudflare, or a managed WordPress host—and whether you're talking 2k, 10k, or 100k+ redirects—I can recommend the exact architecture and rule-storage strategy.

If you’re managing thousands of redirects, I’d avoid making WordPress/PHP the first layer that handles every redirect.

My recommendation

Best for performance:
Nginx/Apache/server-level redirects, with a spreadsheet/CSV as the source of truth and automated deployment.

Best WordPress-native option:
Redirection is my first choice. It is purpose-built for redirects, supports CSV import/export, WP-CLI, and can export rules directly for Apache or Nginx. redirection.me

If you already use Rank Math:
Its built-in Redirect Manager is perfectly reasonable, and it can import/export redirects and even export them as .htaccess or Nginx configuration. s.rankmath.com

What I'd use at different scales

The key distinction is where the redirect executes.

A WordPress redirect generally means the request reaches WordPress/PHP before the redirect is generated. With Apache/Nginx, the web server can issue the redirect before WordPress/PHP needs to run. WordPress's own documentation describes Nginx as a server-level configuration approach, while Apache handles redirects through .htaccess. developer.wordpress.org

A good architecture for thousands

I'd structure it like this:

redirects.csv
     ↓
validation / deduplication
     ↓
Git repository
     ↓
deploy
     ↓
Nginx / Apache / CDN
     ↓
301 redirect

Then use WordPress/Redirection primarily as the management and discovery layer, rather than forcing every request through PHP.

For example, Redirection can take a CSV containing:

/old-product,/products/new-product
/old-category,/category/new-category
/legacy/foo,/new/foo

and it supports exporting the resulting redirects to Nginx rewrite rules or Apache .htaccess. It also supports WP-CLI, which is useful if you're automating migrations. redirection.me

One important caveat

Don't blindly put thousands of individual RewriteRules into .htaccess and assume that's optimal. At large volumes, I'd consider:

• Nginx map / generated configuration
• Apache rules if you're on Apache
• CDN/edge redirects if you're using Cloudflare or another CDN
• grouping redirects into patterns where possible
• eliminating redirect chains (A → B → C should become A → C)
• keeping a canonical CSV/database as the authoritative list
• automatically testing for loops, duplicate sources, and chains before deployment

For a large site, this is much easier to maintain than manually managing thousands of entries in wp-admin.

If you tell me your hosting stack (Nginx, Apache, LiteSpeed, Cloudflare, etc.) and roughly how many redirects you have (e.g. 5k, 50k, 200k), I can recommend the specific architecture and show you exactly how I'd implement it.

If you’re talking about thousands of redirects on a high-traffic WordPress site, I would not make WordPress the first layer that handles them.

My recommendation

Best overall architecture:

CDN / web server → WordPress only for redirects that genuinely need WordPress logic

For example:

Cloudflare / Nginx / Apache
→ handles the bulk of static 301s
→ WordPress handles editorial/content-related redirects

This is generally the best combination of performance + maintainability.

1. If you use Cloudflare: I'd strongly consider it

For thousands of simple mappings such as:

/old-page-1 → /new-page-1
/old-page-2 → /new-page-2
/old-page-3 → /new-page-3
...

putting those redirects at the edge means the request can be redirected before it reaches your WordPress/PHP stack.

That's particularly attractive if you're dealing with 10,000+ redirects or substantial traffic.

I'd keep a canonical CSV/source-of-truth like:

source,destination,status,reason,owner,created
/old-page-1,/new-page-1,301,site migration,seo,2026-08-01
/old-page-2,/new-page-2,301,slug change,seo,2026-08-01

Then deploy that data to your redirect layer rather than treating the WordPress database as the master copy.

2. If redirects must live inside WordPress: Redirection

The Redirection plugin is the option I'd investigate first if your requirement is specifically:

"I want a dedicated WordPress redirect system, not a whole SEO suite."

It's particularly nice for a large redirect inventory because you're separating redirect management from your SEO plugin.

3. If you're already using Rank Math: use its redirect manager

Rank Math Redirections is a perfectly reasonable choice. It supports bulk actions, CSV import/export, searching, categorization and different match types. Rank Math specifically positions the redirect manager as lightweight/optimized. rankmath.com

So I wouldn't install Rank Math solely because you have redirects. But if you're already using it for SEO, there's little reason to add another redirect plugin.

The important part: don't create redirect chains

At scale, redirect architecture matters more than the choice between plugins.

Bad:

/old-url
   ↓ 301
/moved-url
   ↓ 301
/new-url
   ↓ 301
/final-url

Better:

/old-url ─────────→ /final-url
/moved-url ───────→ /final-url

Large redirect inventories tend to accumulate chains and obsolete rules over years. Research examining millions of redirecting URLs found substantial problems with redirect chains and errors, so periodic cleanup is worthwhile. arxiv.org

What I'd do for a serious site

If you have 1,000–10,000 redirects:

Cloudflare/Nginx

• Permanent, static redirects
• Large migration mappings
• Domain/path migrations
• Rules that don't require WordPress

WordPress

• Redirects created when editors change URLs
• Content-specific rules
• Regex/match rules requiring WP context
• 404 monitoring and editorial maintenance

One source of truth

• Keep redirects in CSV/JSON/Git or another controlled dataset
• Import/deploy them
• Don't have three different plugins independently accumulating redirects

And I'd periodically run a crawler against the redirect inventory to detect:

• redirect chains
• redirect loops
• 404 destinations
• 200 → 301 → 200 mistakes
• duplicate source URLs
• redirects to irrelevant pages
• redirects that haven't received traffic for a long time

Bottom line:
If performance is the #1 concern, server/CDN-level redirects win. If everything needs to remain inside WordPress, Redirection is my preferred dedicated solution. If you're already running Rank Math, use Rank Math's redirect manager rather than adding another plugin. rankmath.com

If you tell me roughly how many redirects you have (e.g. 5k, 50k, 500k), whether you're on Apache/Nginx, and whether you use Cloudflare, I can recommend a specific architecture and data structure that will scale cleanly.

If you're talking thousands of redirects, I’d separate the question into where the redirects should execute and how you manage them.

My recommendation

Best overall architecture:

Web server / CDN → redirects → WordPress

rather than:

Web server → WordPress/PHP → redirect plugin → destination

For a few hundred redirects, a WordPress plugin is perfectly reasonable. For 5,000–50,000+ redirects, I would strongly prefer handling them at the server/CDN layer if your hosting stack allows it.

If you want to stay inside WordPress: Redirection

I'd pick Redirection (John Godley) for this specific use case.

urlRedirection on WordPress.orgturn0search5

The plugin explicitly says it's designed for sites ranging from a handful of redirects to thousands of redirects, and it has caching/performance improvements for large redirect sets. It also provides import/export and 404 monitoring, which makes long-term maintenance much easier. wordpress.org

I'd choose it over installing a full SEO suite just to get redirects.

If you're already using Rank Math

Then Rank Math's redirect manager is perfectly reasonable and I'd avoid adding another redirect plugin just for this.

urlRank Math Redirectionsturn0search7

Rank Math specifically describes its redirect manager as optimized for speed. rankmath.com

The important thing is don't maintain the same redirects in both Rank Math and another redirect plugin. That becomes a maintenance nightmare and can create chains/conflicts.

For truly large-scale redirects, I'd do this

If you have, say, 10,000+ old URLs from a migration, I'd use:

                    ┌── CDN / Cloudflare
                    │       ↓
Old URL ────────────┤   Redirect lookup
                    │       ↓
                    │   301 → new URL
                    │
                    └── no match → WordPress

That means a request for:

/old-product-name

can become:

HTTP/1.1 301
Location: /new-product-name

without booting WordPress/PHP at all.

That's the architecture I'd favor for maximum performance.

One important distinction

Don't worry too much about the raw number of redirects.

10,000 well-managed redirects isn't inherently a problem.

The bigger problems are:

• redirect chains: A → B → C
• redirect loops
• regex rules that are expensive or overly broad
• duplicate/conflicting rules
• redirecting thousands of unrelated 404s to the homepage
• letting redirects accumulate forever
• making WordPress execute unnecessarily for every redirect

For example, prefer:

A → C

over:

A → B → C

Research on large-scale web redirects has found substantial numbers of failed/overly long redirect paths, so periodically collapsing chains is worthwhile. arxiv.org

What I'd use at different scales

< 1,000 redirects:
→ Redirection plugin

1,000–10,000:
→ Redirection is still fine; consider server/CDN if performance is critical.

10,000–100,000+:
→ CDN/server-level redirect map, with WordPress used for management/reporting rather than executing the redirects.

Very frequently changing redirects:
→ Redirection plugin can actually be more convenient than server config because editors can manage/import/export them without touching infrastructure.

Large migration:
→ Build the redirect map in CSV/database first, clean chains/duplicates, then deploy it at the CDN/server layer.

If you tell me roughly how many redirects you have (e.g. 5k, 50k, 500k), your host (Cloudways, Kinsta, WP Engine, VPS, etc.), and whether you're on Apache or Nginx, I can recommend the exact architecture and the safest way to bulk-import/manage them.

If you're managing thousands (or tens of thousands) of redirects, the best solution depends on where you want the redirects to execute. The earlier in the request lifecycle they happen, the better the performance.

Here's how I'd rank the options.

Option 1: Cloudflare Bulk Redirects (Best overall if you use Cloudflare)

If your site is behind Cloudflare, this is usually the sweet spot.

Advantages:

• Redirects happen before WordPress loads.
• Very fast.
• Can import CSV files.
• Easy to update.
• Doesn't increase PHP or database load.
• Handles tens of thousands of redirects.

Great if you're migrating sites or changing URL structures.

Option 2: Nginx Map (Best raw performance)

For Nginx servers, use a map file.

Instead of thousands of individual rewrite rules:

map $request_uri $redirect {
    /old-page1 /new-page1;
    /old-page2 /new-page2;
}

server {
    if ($redirect) {
        return 301 https://example.com$redirect;
    }
}

Benefits:

• Extremely fast.
• Memory efficient.
• Easy to generate automatically from CSV.

Many enterprise WordPress sites use this approach.

Option 3: Apache RewriteMap (Better than massive .htaccess)

If you have access to the Apache server config (not just .htaccess), RewriteMap scales much better than thousands of rewrite rules.

Avoid putting 10,000 redirects directly into .htaccess if possible.

Option 4: WordPress Redirect Plugin (Best if non-technical users manage redirects)

The most widely used choice is:

• John Godley's Redirection plugin

It supports:

• CSV import/export
• Regex
• 404 logging
• Groups
• Redirect conditions
• Database storage

Pros:

• Excellent UI
• Easy for editors
• Mature and reliable

Cons:

• Every redirect still requires WordPress and PHP to load unless additional caching intercepts the request.

For a few thousand redirects this is generally acceptable on a well-cached site.

Option 5: Custom Redirect Table (Good for developers)

If you're building a custom solution:

Create a table like:

old_path VARCHAR(255) PRIMARY KEY
new_path VARCHAR(255)
status SMALLINT

Index:

PRIMARY KEY(old_path)

Lookup:

SELECT new_path
FROM redirects
WHERE old_path = ?
LIMIT 1;

With a proper index, even 100,000+ redirects are very fast.

You can also cache results in Redis or Memcached.

What I would recommend

Under 1,000 redirects

Use the Redirection plugin.

1,000–10,000 redirects

Still acceptable with Redirection, especially if redirects don't account for most traffic.

10,000–100,000 redirects

Move redirects out of WordPress.

Either:

• Cloudflare Bulk Redirects
• Nginx map
• Apache RewriteMap

These avoid loading WordPress entirely.

If redirects change frequently

A hybrid approach works well:

• Permanent migration redirects → Cloudflare or Nginx
• Temporary marketing redirects → WordPress plugin
• Editors manage temporary redirects; developers deploy permanent ones.

This keeps performance high while allowing non-developers to make routine changes.

For a high-traffic production WordPress site, my preferred stack is:

1. Cloudflare Bulk Redirects (edge)
2. Nginx map (server)
3. WordPress Redirection plugin only for editor-managed or temporary redirects

That minimizes PHP execution, scales cleanly to very large redirect sets, and keeps ongoing maintenance manageable.

For thousands of redirects on WordPress, the best approach is usually not a typical redirect plugin that stores every rule in WordPress tables and checks them on every request. At scale, you want redirects handled as early as possible (server/CDN layer) and maintained in a way that avoids database bloat.

Here are the best options, ranked by scalability:

1. Best overall: CDN/server-level redirects (recommended for thousands+)

Use:

• Cloudflare Redirect Rules / Bulk Redirects
• Nginx map rules
• Apache RewriteRule / .htaccess (smaller sites)

Why this is best:

• Redirect happens before WordPress loads
• No PHP execution
• No database query
• Minimal impact on TTFB
• Easy to handle 10,000–100,000+ redirects

Example flow:

Visitor
  ↓
Cloudflare / Nginx
  ↓
Redirect response (301/308)
  ↓
WordPress never runs

For a large migration (old URLs → new URLs), this is the architecture I would choose.

2. Best WordPress plugin option: Redirection

For many WordPress sites, this is the strongest free option.

Pros

• Built specifically for WordPress redirects
• Supports:
  • URL redirects
  • regex matching
  • import/export
  • redirect groups
  • 404 monitoring
  • logs
• Can handle thousands of rules if configured carefully

Cons

• Redirect checks happen inside WordPress
• Large logs can grow significantly
• Database size and query performance become concerns

For a few thousand redirects, it is usually fine. For tens of thousands, I would move redirects outside WordPress.

3. SEO-focused option: Yoast SEO Premium

Good if:

• Your redirects are mostly created when changing URLs
• Editors need a simple interface
• SEO workflow matters more than raw scale

Less ideal for:

• Bulk migrations
• Thousands of manually managed redirects
• Complex redirect logic

4. Enterprise WordPress approach

For very large sites:

Store redirects as data

Example:

redirects.csv

/old-product-a,/new-product-a
/old-category,/new-category
/old-blog-post,/new-blog-post

Then load them into:

• Cloudflare Bulk Redirects
• Nginx config
• AWS CloudFront Functions/Lambda@Edge
• Varnish
• WordPress VIP redirect system

This gives you:

• version control
• easy auditing
• rollback capability
• automated deployment

What I would avoid

❌ Thousands of individual WordPress rewrite rules

Example:

add_action('template_redirect', function() {
    if ($_SERVER['REQUEST_URI'] == '/old-url') {
        wp_redirect('/new-url',301);
        exit;
    }
});

Problems:

• slow
• hard to maintain
• requires code deployment
• easy to break

❌ Huge .htaccess files

Apache can handle many rules, but thousands of regex rules can become expensive.

If using Apache, prefer generated exact-match rules:

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

over complex regex where possible.

Recommended setup by redirect volume

My recommended architecture for a large WordPress site

**Production setup

If you're managing thousands (or tens of thousands) of redirects on WordPress, the best solution depends on where you want the redirects to execute. From a performance standpoint, the earlier in the request lifecycle, the better.

Here's how I'd rank the options.

Option 1: Cloudflare Redirects (Recommended if you use Cloudflare)

If you're already using Cloudflare, this is often the sweet spot.

Advantages:

• Redirect happens before WordPress loads.
• Nearly zero impact on PHP.
• Easy bulk import.
• API for automation.
• Can handle very large numbers using Rules or Workers.

Good if:

• You have 5,000–100,000 redirects.
• SEO migrations.
• Multiple domains.

Option 2: Nginx Map (Best Raw Performance)

Instead of thousands of individual rewrite rules, use an nginx map.

Example:

map $request_uri $redirect {
    /old-page      /new-page;
    /old-product   /products/new;
    /foo           https://example.com/bar;
}

server {
    if ($redirect) {
        return 301 $redirect;
    }
}

Benefits:

• O(1) lookup
• Extremely fast
• Handles tens of thousands of redirects easily
• No PHP

This is how many high-traffic publishers do it.

Option 3: Apache RewriteMap

If you're on Apache:

RewriteMap redirects txt:/path/redirects.txt

RewriteCond ${redirects:$1} !=""
RewriteRule ^(.*)$ ${redirects:$1} [R=301,L]

Much better than thousands of RewriteRules.

Option 4: WordPress Redirection Plugin (Best General Purpose)

John Godley's Redirection plugin is still one of the best-maintained options.

Pros:

• Bulk import/export (CSV)
• Regex support
• Logging
• 404 monitoring
• REST API
• WP-CLI support

Cons:

• Every request reaches WordPress.
• Database lookup on redirects.

For a few thousand redirects, this is usually fine if:

• Object cache (Redis/Memcached)
• Fast hosting
• Proper database indexes

For 50k+ redirects, I'd avoid running them entirely in WordPress.

Option 5: Custom Redirect Plugin (My Favorite for Large Sites)

Instead of using a general redirect plugin:

• One custom database table
• Indexed on source URL
• Load into Redis or APCu
• One hash lookup
• Return 301 immediately
• Skip loading most of WordPress

Example flow:

Incoming request

↓

Must-use plugin

↓

Hash lookup

↓

301

↓

Exit

This scales extremely well.

Avoid

I would avoid:

• Thousands of .htaccess rewrite rules
• Multiple redirect plugins
• Regex-heavy rules unless necessary
• Plugins that load the full admin framework on every request

If You Have 10,000–100,000 Redirects

A common architecture is:

Cloudflare
      ↓
Nginx map
      ↓
WordPress

or

Cloudflare Worker
      ↓
WordPress

This means WordPress only handles requests that are not redirects.

My Recommendations by Scale

• Under 2,000 redirects: The Redirection plugin is simple and sufficient.
• 2,000–20,000 redirects: A custom redirect table with caching, or server-level redirects if you have server access.
• 20,000+ redirects: Use Cloudflare Rules/Workers or Nginx map; avoid PHP-based redirects whenever possible.
• 100,000+ redirects: Store redirects at the edge (Cloudflare Workers, Fastly, Akamai) or in an optimized server-side lookup rather than in WordPress.

If you're planning a large site migration, it also helps to consider how the redirects will be updated. If they're generated from a CMS, PIM, or spreadsheet, choosing a solution with an API or automated import process can significantly reduce ongoing maintenance.

If you're managing thousands to hundreds of thousands of redirects on WordPress, the best solution depends on where you want the redirects to execute.

Here's how I'd rank the options for performance, maintainability, and scale.

If you're staying inside WordPress

I would not use a typical redirect plugin if you're talking about thousands of redirects.

Many plugins:

• load every request
• perform regex matching
• query WordPress unnecessarily
• become difficult to export/import

Some are better than others, but they all still require WordPress to bootstrap before redirecting.

Best plugin: Redirection

If you want an off-the-shelf plugin,

Redirection

is still the gold standard.

Pros:

• bulk import/export CSV
• regex support
• 301/302/307/etc.
• logging
• groups
• REST API
• maintained

Cons:

• every redirect passes through WordPress
• logging should be disabled at large scale
• regex rules can become expensive

For 5,000–20,000 redirects it generally works well if configured carefully.

Better: custom database lookup

If you have:

• 20k+
• 50k+
• 100k+
• redirects change often

I'd build a tiny custom plugin.

Example schema:

redirects

old_path      VARCHAR(255) UNIQUE
new_url       TEXT
status        SMALLINT

Then on template_redirect:

$request = trim($_SERVER['REQUEST_URI'], '/');

SELECT new_url,status
FROM redirects
WHERE old_path = ?
LIMIT 1;

With an index on old_path, MySQL returns matches in milliseconds.

Advantages:

• import millions from CSV
• easy admin page
• easy API
• no regex overhead
• maintainable

This is how many enterprise WordPress sites handle redirects.

Even better: Nginx map

If you control the server,

map $request_uri $redirect {
    /old-page      https://example.com/new-page;
    /foo           https://example.com/bar;
}

Nginx performs lookups extremely efficiently.

Even tens of thousands of entries are generally not a problem.

This avoids PHP entirely.

Cloudflare

If you're already using Cloudflare:

• Bulk Redirect Lists
• Redirect Rules

These happen before your origin server.

Benefits:

• zero PHP
• zero database
• globally cached
• very fast

Excellent if your redirects are mostly static.

Avoid

I would avoid:

• thousands of Redirect 301 lines in .htaccess
• regex-heavy redirect plugins
• plugins that log every redirect forever
• loading all redirects into PHP arrays

Those approaches tend to become harder to maintain and can noticeably impact performance.

My recommendation

Based on different scales:

• Up to ~5,000 redirects: The Redirection plugin is usually sufficient. Disable access logging unless you specifically need it.
• 5,000–50,000 redirects: A custom WordPress plugin with a dedicated indexed database table provides a good balance of performance and manageability.
• 50,000+ redirects: Move redirects to the web server (Nginx map) or to the edge (Cloudflare Bulk Redirects or a similar CDN feature). This avoids loading WordPress for redirect requests and gives the best performance.

If you can share:

• your hosting stack (Apache, Nginx, LiteSpeed, etc.),
• whether you're on a single site or multisite,
• and roughly how many redirects you expect (10k, 100k, 1M+),

I can recommend the architecture that's likely to perform best for your specific environment.

If you're managing thousands (or tens of thousands) of redirects on WordPress, the biggest performance consideration is where the redirects are processed.

In order of performance:

1. Web server level (Nginx or Apache) — fastest
2. CDN/edge (Cloudflare, Fastly, etc.) — excellent if you use one
3. WordPress plugin with optimized database lookups — good
4. Custom PHP logic — generally avoid for large redirect sets

Best options

1. Nginx or Apache config (Best performance)

If you have server access, this is the gold standard.

Pros

• No WordPress bootstrap
• Extremely fast
• Minimal server resources
• Easily handles 100k+ redirects

Cons

• Harder for non-technical editors
• Config files become cumbersome if not automated

Good if:

• Redirects change infrequently
• You can generate config files from CSV

2. Cloudflare Bulk Redirects (My favorite for large sites)

If you're using Cloudflare:

Pros

• Redirect happens before your server
• Very fast globally
• CSV import/export
• Great management interface
• Doesn't slow WordPress

Excellent for:

• Site migrations
• SEO
• Large ecommerce catalogs

This is usually the cleanest long-term solution.

3. Redirection plugin (Best WordPress plugin)

The Redirection plugin is the standard recommendation.

Pros:

• Handles tens of thousands of redirects
• CSV import/export
• Regex support
• Logging (optional)
• Groups
• 301/302/307
• Apache & Nginx export
• Active maintenance

For performance:

• Turn off logging unless you actually need it.
• Disable 404 logging if unnecessary.
• Make sure the redirect table is indexed (the plugin does this).

I've seen it work well with 20k–50k redirects, though every request still loads WordPress.

4. Rank Math

If you're already using Rank Math Pro:

• Redirect manager included
• Easy UI
• Good for hundreds or a few thousand redirects

Not my first choice if redirects are the primary workload.

5. Yoast Premium

Fine for smaller sites, but I wouldn't choose it solely for managing thousands of redirects.

If you have 10,000+ redirects

I'd avoid processing every redirect through PHP if possible.

Instead:

CSV
    ↓
Generate redirect rules
    ↓
Cloudflare Bulk Redirects
or
Nginx include file

This scales much better.

Maintenance strategy

Instead of creating thousands of one-off rules, first look for patterns.

Instead of:

/product1
/product2
/product3
/product4
...

use one regex:

^/old-products/(.*)$
→
/products/$1

A few regex rules can often replace thousands of individual entries.

For very large datasets (100k+)

Consider storing redirects in a dedicated lookup structure and generating server-native rules or edge redirects automatically. A common workflow is:

Master CSV
        ↓
Git repository
        ↓
Validation script
        ↓
Generate:
    - Nginx map
    - Apache RewriteMap
    - Cloudflare import

This makes updates repeatable, version-controlled, and easy to roll back.

My recommendation by scale

If you control the hosting environment, I would generally choose Cloudflare Bulk Redirects (if you're already using Cloudflare) or Nginx map files. If you need non-technical users to manage redirects entirely within WordPress, the Redirection plugin is the strongest balance of functionality and maintainability, though it won't match server- or edge-level performance for very large redirect sets.