How to Manage Redirects in TYPO3 Without Losing SEO Value

Why redirect management is not optional

Every TYPO3 site eventually changes its URLs. Pages move, slugs get renamed, site structures are reorganized, an old campaign path has to keep resolving because it was printed on flyers three years ago. Each of those changes silently breaks the URL that Google indexed, that other sites linked to, and that visitors bookmarked. A visitor who lands on a 404 page does not usually retry — they leave.

Since TYPO3 v9, the core ships a system extension called redirects that handles this problem in the backend instead of the webserver configuration. It lets you create manual redirects, list the existing ones, and automatically generate redirects whenever a page slug changes, as the official extension manual puts it. This guide walks through how the module works on a TYPO3 v13 site, which decisions actually matter for SEO, and how to keep the redirect table from slowly turning into a liability.

If you are coming to this topic because of a larger reorganization, the planning discipline in our TYPO3 v12 to v13 upgrade guide applies to URL restructures as well: rehearse on staging, define what “done” means before you start, and never change two variables at once.

Where redirects live

The module sits at Sites > Link Management > Redirects in the backend. Each redirect is a record in the sys_redirect table, which has a few consequences worth understanding before you create your first one:

• Redirects are database records, so they travel with the database when you copy an environment, and they are searchable and countable from the backend.
• Redirects are resolved in PHP on every unmatched request, not by the webserver. That is convenient and flexible, but it also means redirect matching costs application time — a point the official best practices are explicit about, which we return to below.
• Records can be disabled, scheduled with start and stop times, and individually protected from automated cleanup.

The backend list shows all redirects across the installation, with filters for domain, path and status code. When the hit counter is switched on (more on that later), the list also shows how often each redirect fired and when it was last hit, including a filter for redirects that were never hit at all — which is one of the more useful views you will find once the table grows.

Creating a redirect record

Click the + icon in the module to open the edit form. Four decisions matter most.

Source domain. Each redirect is bound to a host: either one of the domains configured in your site configuration, or the wildcard *, which makes the redirect apply to all sites in the installation. On a single-site setup the wildcard is often fine. On a multisite installation, resist the temptation to wildcard everything — a path like /imprint probably means different targets on different sites.

Source path. The path to match, such as /about-us. Use the full path including any language prefix, for example /en/about-us, for language-specific entry points. Two checkboxes change how matching works:

• Respect GET parameters makes the query string part of the match instead of ignoring it.
• Is regular expression treats the source path as a regex, which must be wrapped in delimiters, for example #^/old-path/([a-zA-Z0-9_-]+)#. Capturing groups can then be reused in the target as $1, which is the standard way to move a whole URL pattern in one record instead of writing forty separate redirects.

The documentation is blunt about regex redirects: TYPO3 does not syntax-check them, so test the pattern before you save it. A malformed pattern does not fail loudly; it just never matches, and you find out weeks later in the 404 statistics.

Target. The target can be a plain path (/features/), a full URL, or a TYPO3 link syntax such as t3://page?uid=42. Prefer the page-ID form for anything permanent. A redirect that points at a page ID keeps working when that page’s slug changes again later, whereas a redirect pointing at a fixed path quietly becomes a second hop in a chain. The Force SSL checkbox rebuilds the target URL with HTTPS even if the site entry point or a hardcoded target says otherwise, and Keep GET parameters appends the original query string to the target instead of dropping it.

Status code. The record’s default is 307, a temporary redirect. For permanent moves — a renamed page, a retired URL pattern, a domain consolidation — change it to 301. Search engines treat 301 as a signal to consolidate ranking signals at the target; a 307 tells them the old URL may come back, so they keep it indexed. Most redirects on a mature site should be 301s. Reach for 307 or 302 only for genuinely temporary situations, such as a maintenance window or a seasonal campaign swap.

The automatic redirect feature

The part of the extension that most sites benefit from immediately is also the part most integrators forget to configure: automatic redirect creation on slug changes.

When an editor renames a page slug, TYPO3 can create a redirect from the old URL to the new one without anyone opening the Redirects module. Since v12.1, those automatic records are stored on the site’s root page, which keeps them organized per site. The behavior is controlled per site in the site settings — through the site management backend or, in v13 site sets, in settings.yaml:

• autoCreateRedirects — create a redirect whenever a slug changes in the LIVE workspace. Default: enabled.
• autoUpdateSlugs — also update the slugs of all subpages when a parent slug changes. Default: enabled. This is what produces the whole-tree redirects people expect after reorganizing a section.
• redirectTTL — how many days an automatically created redirect stays valid. 0 means no expiration. Default: 0.
• httpStatusCode — the status code used for automatic redirects. Default: 307.

Two of those defaults deserve attention. First, if your automatic redirects default to 307 while your manual ones are 301, search engines receive mixed signals about the same reorganization. Set the automatic status to 301 for permanent structures. Second, an unlimited TTL means every slug an editor ever renamed leaves a permanent record behind. That sounds safe until the table accumulates thousands of entries, most pointing at URLs nobody has requested in years. A TTL of a year or two, combined with the cleanup command below, keeps the table honest.

The best-practice chapter adds the most important non-technical measure: minimize slug changes in the first place. Automatic redirects are a safety net, not a license to restructure URLs casually.

Measuring what actually happens

By default, TYPO3 does not count redirect hits. The hit counter lives behind a feature toggle, redirects.hitCount, in Settings > Feature Toggles or system/settings.php, and it is disabled by default because every hit triggers an additional SQL UPDATE — a real cost on high-traffic sites.

When you enable it, each record gains a hit count, a last-hit timestamp and a creation date, and an individual redirect can opt out via its Hit Counter checkbox. The value is in the decision it enables: after some months, redirects that were never hit, or last hit long ago, become cleanup candidates rather than guesses.

Keeping the table healthy

Two console commands do the housekeeping, and both belong in the scheduler or cron on any site that takes redirects seriously.

vendor/bin/typo3 redirects:checkintegrity looks for conflicts and loops — the classic case being /a => /b combined with /b => /a. Run it for all sites or pass a site identifier. Results are stored in the system registry and surface in Reports > Status Report, and the extension can flag a notice if the check has not run within the last 24 hours, which is a gentle way of making sure it actually runs. Be aware that additional routing enhancers or decorators can produce false positives, so read conflicts before deleting records over them.

vendor/bin/typo3 redirects:cleanup removes records matching your constraints: a minimum hit count (-c), a minimum age in days (-a), and optional filters for domain, source path and status code. For example, redirects:cleanup -c 50 -a 30 deletes redirects with fewer than 50 hits that are older than 30 days — the documented shape of a conservative policy. The hit-count option only works with the hit counter enabled. Two cautions from the documentation are worth repeating: cleanup deletes redirects permanently, and a redirect marked Protected is excluded from automated deletion. Protect the handful of redirects that must never disappear — the printed-campaign URL, the partner link — and let the rest follow the policy.

Chains are the other quiet failure mode. If /old redirects to /2019/old which redirects to /about, every request pays two hops and search engines dilute the signal across them. The documented advice is to merge chains into a single redirect from the original source to the final target. Pointing targets at page IDs (t3://page?uid=42) instead of paths prevents most chains from forming in the first place.

Knowing the limits

The best-practices chapter contains a warning that deserves more attention than it usually gets: handling redirects through PHP has technical limitations. Every 404 request has to boot the application far enough to match against the redirect table, and regex redirects are the expensive end of that. The extension is designed for installations with a limited number of redirects.

If a migration or consolidation leaves you with thousands of permanent rules, the documented recommendation is to move the stable bulk of them out of the database and into your webserver configuration or load balancer, keeping the TYPO3 module for the dynamic, editor-managed portion. Apache Redirect directives or an nginx map block handle tens of thousands of patterns without touching PHP at all.

For debugging, remember that redirects resolve in the browser, which hides the intermediate steps. curl -I -L https://example.com/old-path/ shows each hop with its status code and target, and quickly reveals loops, chains and unexpected http-to-https behavior. Run it with the exact URL a visitor reported, query string included, because parameter handling is the most common source of “it works for me” disagreements.

Who should have access

The Redirects module can affect the entire installation — one careless wildcard redirect can send every URL on the site somewhere else. The documentation’s advice is to grant module access only to editors who understand how redirects work and will not create loops. Non-admin editors see just the three core fields (source domain, source path, target) by default; everything else, including the ability to revert deleted redirects, must be added explicitly through the group’s access lists. Start restrictive, and widen access only when someone actually needs it.

A routine that works

Pulling the pieces together, a TYPO3 site that manages redirects well does roughly the following:

1. Enable autoCreateRedirects with a 301 status and a finite TTL per site.
2. Create manual redirects as page-ID targets, protecting only the ones that must never expire.
3. Enable the hit counter if traffic allows, and review the never-hit list quarterly.
4. Run redirects:checkintegrity daily via the scheduler, and act on the status report.
5. Run redirects:cleanup on a schedule with an agreed hit-and-age policy.
6. After any large reorganization, verify the important URLs with curl -I -L and merge chains.
7. When the permanent rule count grows into the thousands, move the stable portion to the webserver.

None of this is complicated individually. The value is in doing it routinely, because redirect rot is gradual: every missing 301 costs a little traffic and a little ranking, and nothing on the site breaks loudly enough to tell you.

If your team is reorganizing a TYPO3 site and would rather not own this discipline internally, our TYPO3 development service covers URL migrations, redirect audits and post-reorganization SEO verification, and the SEO/GEO service handles the search-side follow-up once the new structure is live. An overview of what we build and maintain on that platform is on the TYPO3 platform page.