Here are some general tips for managing redirects:
Check for conflicts regularly with redirects:checkintegrity. This is no longer as much an issue as with previous versions, because it was resolved with patch 68202. Since this patch, a path is no longer used for the target. A redirect is constructed using the page ID, e.g.
t3://page?uid=1as target. This means the redirect will still work, even if the slug changes again. This way, it is less likely that redirect loops and redirect chains are created because the redirect always redirects directly to the target page.
Check number of redirects and regularly clean out unnecessary redirects, e.g. with redirects:cleanup. If you use the hit counter, be aware that it comes with a small performance impact.
"Redirect chains" are not as much a problem, but can become inefficient. A "redirect chain" are several redirects which must be followed until the destination is reached. Ideally, these should be merged.
Well curated content and editors which have a good understanding of SEO and possible problems with redirects are a good idea in any case. TYPO3 comes with extensive permission and workspaces management - which gives you the possibility to only grant advanced editor groups access to parts of the content (e.g. pages, redirect module) which they are well equipped to handle.
If you give editors access to the redirects module, make sure that they understand the usage and for example do not create redirect loops.
Often changing slugs comes with a cost. Redirects are a counter measure so that pages with changing slugs are still accessible but a better strategy is to only change slugs when absolutely necessary.
With a certain number of redirects and depending on your setup, performance problems may occur through technical limitations.
The following rules of thumb should be followed:
Restrict time-to-live [
ttl] of redirects - manual and automatically created.
Cleanup regularly and remove outdated redirects.
Recheck redirects and aggregate them on a manual basis to lower the number.
Keep the number of redirects for the whole instance in a certain range.
Instruct editors to be careful with slug changes and thus creating redirects automatically, which may be unnecessary.
Handling redirects through PHP applications has technical limitations, even more if complex redirects like regexp-style redirects should be supported. Thus, handling redirects with EXT:redirects is only suitable for installations with a certain number of redirects.
It is recommended to monitor performance and - if necessary - export redirects to your webserver configuration or load balancer.
Since redirects are resolved in the web browser, it may be difficult to
troubleshoot. There are many tools available, for example you can
use a command line tool like
curl to follow and show redirects or use the
online tool Redirect detective.
Redirect detective also detects redirect loops.
Example: Resolve redirects with curl (
-L follows redirects):
curl -I -L -s -X GET http://example.org
HTTP/1.1 301 Moved Permanently ... Location: http://example.com .... HTTP/1.1 301 Moved Permanently ... Location: https://example.com .... HTTP/1.1 200 OK ...
As you can see,
http://example.org is redirected twice, first to
http://example.com and then to the HTTPS variant.
These are just two simple tools of many you can use.