Redirect

The Redirect component does two unrelated jobs. It keeps the hub's list of managed redirects — the addresses that used to work and where they go now — and it collects the 404s the site serves so you can see which broken addresses people are actually asking for. Separately, it provides the interstitial page that warns a member before an external link takes them off the hub.

The two halves have nothing to do with each other. The redirect list is about addresses on the hub that no longer resolve; the interstitial is about addresses on other people's sites. They share a component and an Options screen and nothing else, and this chapter keeps them apart: the list first, the interstitial at the end.

The redirect list is the part a manager works in. Every hub earns one eventually. A paper is published citing /resources/dataset-3; six months later the group reorganises its resources and that address returns a 404 to everyone who follows the citation. You cannot edit the paper. You can make the old address work again, and this is where.

URLs covers it in the context of how the hub addresses a page; this chapter is the component's own reference and goes further into the screens, the collection mechanism, and the options.

What it is not

This is not the hub's URL routing, and it is not the place to decide what a page's address should be in the first place. Each component builds its own addresses, and a menu item can change one; see URLs. A managed redirect is for an address that used to work and no longer does. Nor is it a link checker: it records the broken addresses people actually request, not every broken link on the hub.

Where it lives

Site → Maintenance → Routes. It is deliberately not in the Components menu — the admin menu excludes it.

Opening the component needs core.manage on com_redirect.

The two lists

The screen has two sub-navigation entries over the same table:

• Redirects — links that have a destination.
• 404s — links that do not. These are the recorded misses.

Search matches the source URL, the destination, the comment, and the referring page. The status filter offers All, Enabled, Disabled, Archived, and Trashed. Every column heading sorts.

The list shows the Expired URL, then either the New URL (on Redirects) or the Referring Page (on 404s), followed by the Created Date, the status, the 404 Hits count, and the ID. Source and destination are shown relative to the hub root, with a (site) prefix standing in for it.

At the foot of the table the component reports whether the plugin it depends on is running: The Redirect Plug-in is enabled. or The Redirect Plug-in is disabled. Enable it in the Plug-in Manager.

How 404s are collected

They are collected by the System - Redirect plugin, not by the component. The plugin installs itself as the site's exception handler; when the hub raises a 404 it:

1. Looks for an enabled link whose Source URL matches the full request URL. Failing that, it tries the server-relative path, with and without a leading slash.
2. If it finds one, it sends the redirect and stops.
3. Otherwise it records the address — creating a link with an empty destination, the referring page, and one hit, or incrementing the hit count on the one that already exists.

So the 404s list fills itself, and nothing at all is recorded while the plugin is disabled. Two kinds of request are skipped on purpose: URLs containing mosConfig_ or =http://, which are probe traffic.

A fresh install ships the plugin enabled, so a hub has been collecting 404s since the day it was built, and the 404s list on a hub that has been running a while is usually long. If the foot of the screen says the plugin is disabled, someone turned it off; re-enable it under Extensions → Plugins, filtering on system. See Plugins.

Nothing trims the list. Rows accumulate until somebody trashes them, and the component has no scheduled task and no bulk purge beyond Empty trash. On a public hub most of what accumulates is probe traffic for software the hub does not run, which is why the hit count matters more than the row count: an address asked for once is noise, and an address asked for four hundred times is a link somebody published.

Editing a link

New, or select one and Edit.

Field	Meaning
Source URL	The address to catch. Required, and must be unique across the whole list. A value that does not start with http is stored as a root-relative path.
Destination URL	Where to send the visitor. Also normalised to a root-relative path unless it starts with http.
Response Code	404 Not Found, 301 Moved Permanently, or 302 Found.
Comment	A free-text note. Worth using: it is the only place to record why a redirect exists.
Status	Enabled, Disabled, Archived, or Trashed. Only an enabled link redirects.

The right-hand panel shows the ID, created and last-updated dates, and the hit count; none of them are editable.

Working through the 404 list

Below the list, once it has rows, is Update selected links to the following new URL. Tick several recorded 404s, type one Destination URL and optionally a Comment, and press Update Links: all of them get that destination, the same comment, and are enabled in one go. This is the fast way to retire a whole directory of moved pages. Links updated this way are stored as 301 Moved Permanently, because the batch sets no response code and the correction described above supplies one.

Repointing the cited address

Following the example above — the dataset moved and a published paper still cites the old address:

1. Go to Site → Maintenance → Routes and open 404s.
2. Sort on 404 Hits, descending. The address people are actually asking for is at the top; if it is not there, nobody has followed the citation yet, and you can add the redirect by hand with New instead.
3. Confirm it is the address you think it is. The Referring Page column often names where the traffic comes from.
4. Tick the row, and any other addresses that should go to the same place.
5. In Update selected links to the following new URL, type the new address and a Comment saying why — dataset moved, cited in the 2025 paper. Six months from now the comment is the only record of why the redirect exists.
6. Press Update Links. The rows move to the Redirects list, enabled, as 301 Moved Permanently.
7. Open the old address in a browser and check where you land.

The rest of the toolbar is Enable, Disable, Archive, and Trash. Permanent deletion appears as Empty trash only when the status filter is set to Trashed. Options appears for core.admin.

Archiving is the way to retire a recorded 404 you have decided not to redirect, without losing the record that it was asked for.

The external-link interstitial

The second half of the component is unrelated to the redirect list, and nothing you do in one affects the other. Its job is to tell a member that they are about to leave the hub — the case it exists for is a hub whose members post links into questions and project descriptions, where an unannounced jump to somewhere else looks like the hub sent them there. It ships switched off, and switched off is the right setting unless somebody has asked for the warning.

It rewrites links that point off the hub so that they go through /redirect/{base64 of the target} instead, and that address optionally shows a countdown page — Redirecting Soon… — before forwarding.

Four places pass member-supplied text through the rewriter: the body of an Answers question and of its comments, the About text on a project's public page and in the project info panel, and the handoff when a tool session opens at an external proxy URL.

The rewrite happens whether or not the delay is switched on; what the options control is what the /redirect/ address then does. In every case the rewritten link also gains rel="noreferrer nofollow noopener", so the external site is not told where the visitor came from.

Setting	What it does
Delay is enabled	DISABLED — the default — forwards immediately. ENABLED shows the countdown page for external destinations.
Delay in seconds	How long the countdown runs. Default 10.
Whitelisted hosts	Comma-separated hostnames that are never delayed and never rewritten.
Blacklisted hosts	Comma-separated hostnames that are not followed at all: the link is rewritten to the hub's front page.

Links to the hub's own host are left alone, as are anchors and javascript: URLs. Hostnames containing proxy are always treated as external.

The parameters are in the generated reference.

See also

• URLs — how the hub decides an address in the first place, and why a redirect is a better answer than a menu item.