Will over 1000 301 redirects slow down my site? – Apache

1218 redirect directives in .htaccess shouldn’t cause a noticeable/significant delay, however there are other issues with your suggestion and this can be greatly optimised to avoid any additional overhead…

…having to query each of these on every page load?

It’s not just "every page load", but potentially every request. All static resources (CSS, JS, images, etc.) will trigger the same set of directives (unless they are hosted away from the application server).

RewriteEngine on
Redirect 301 https://digimoncard.io/deck/?deckid=1241 https://digimoncard.io/deck/green-otk-1241

This won’t work. The mod_alias Redirect directive matches the URL-path only, it does not match the query string (or scheme+hostname), so the above directive will simply fail to match and do nothing. (RewriteEngine is also part of mod_rewrite, not mod_alias.)

In order to match the query string you need to use mod_rewrite with an additional condition to check against the QUERY_STRING server variable. For example:

RewriteCond %{QUERY_STRING} ^deckid=(1241)$
RewriteRule ^deck/$ /green-otk-%1 [R=301,L]

The %1 backreference contains 1241 (captured from the preceding CondPattern) – this simply saves repetition (that could potentially introduce bugs). Unless of course you are generating these directives automatically.

Don’t use .htaccess – use your application logic instead

However, ideally, you would not be doing these redirects in .htaccess to begin with. It would be far more optimal to do these in your application logic (ideally when your site determines that the result would trigger a 404 – although that does not happen in your case). By placing these directives in .htaccess you are prioritising the "redirects" at the expense of normal site traffic. By implementing these redirects later (in your application) you prioritise normal site traffic.

Since I assume you are using a front-controller to route your URLs this should be relatively trivial to implement. (You only process the redirect logic when a request comes in that matches the old URL format.)

Optimised .htaccess version

However, you could greatly optimise this if deciding to go the .htaccess route if all your old URLs follow the same format… you could internally rewrite any request that uses the format /deck/?deckid=<number> to a subdirectory (assuming all your old URLs use this format). You then have another .htaccess file in the subdirectory that processes all the 1218 redirects. This way, you only have a single directive in your main .htaccess file, that is processed on every request and the redirect logic (in the subdirectory .htaccess file) is only processed when it needs to be.

This avoids the overhead of having 1000+ redirect directives in the main .htaccess file.

The directives in the subdirectory .htaccess file can also be simplified since we can rewrite the request to move the query string to the URL-path to avoid the additional condition later.

For example, at the top of your root .htaccess file:

RewriteEngine On

# Internally rewrite the request for (what looks like) an old URL
# ...to the "/redirect-old" subdirectory
RewriteCond %{QUERY_STRING} ^deckid=(d+)$
RewriteRule ^deck/$ redirect-old/%1 [L]

All URLs of the form /deck/?deckid=<number> are internally rewritten to /redirect-old/<number>…

Then, in /redirect-old/.htaccess you have simplified "redirect" directives like the following that match against the rewritten URL:

# /redirect-old/.htaccess

RewriteEngine On

# Redirect old URLs
RewriteRule ^1241$ /deck/green-otk-$0 [R=301,L]
RewriteRule ^1234$ /deck/foo-$0 [R=301,L]
RewriteRule ^4321$ /deck/bar-$0 [R=301,L]
:

These directives match the rewritten URL, ie. /redirect-old/<number> and redirect accordingly.

The $0 backreference in each case is simply the URL-path (ie. number) that is matched by the RewriteRule pattern. (Saves repetition – as mentioned above.)