Redirects in Joomla

1. De basis

1.1 Wat is de Redirects-component?

De Redirects-component (com_redirect) is Joomla’s ingebouwde hulpmiddel voor het beheren van HTTP-redirects en het registreren van 404-fouten (Pagina niet gevonden). Deze maakt sinds versie 1.6 deel uit van de Joomla-core.

Kort samengevat doet de component vier dingen:

• Hij bewaakt 404-fouten via de plugin System - Redirect.
• Hij registreert elke ontbrekende URL in de database, samen met de referrer en een hitteller.
• Hij laat je oude URL’s koppelen aan nieuwe URL’s met de juiste HTTP-statuscode.
• Hij ondersteunt bulkimport voor migraties, zodat je honderden redirects tegelijk kunt voorbereiden.

De workflow is eenvoudig: een oude URL geeft een 404 terug, Joomla registreert deze, een beheerder vult een nieuwe URL in en de volgende bezoeker wordt automatisch doorgestuurd.

1.2 Waar vind ik Redirects?

In de Joomla 6-backend zijn drie locaties relevant:

Componenten → Redirects                           (redirects en 404-log beheren)
Componenten → Redirects → Opties                 (componentinstellingen, ACL)
Systeem     → Beheer → Plugins → System - Redirect (verzamelaar en handler)

De component bevindt zich in administrator/components/com_redirect/. De plugin die koppelt aan het foutensysteem bevindt zich in plugins/system/redirect/.

1.3 De twee onderdelen

De Redirects-functionaliteit bestaat uit twee onderdelen die samenwerken:

Beide moeten ingeschakeld zijn. De component zonder plugin is slechts een passieve lijst. De plugin zonder component heeft niets om uit te lezen.

1.4 De plugin inschakelen

Een verse Joomla-installatie levert de plugin System - Redirect standaard uitgeschakeld mee. Totdat je deze inschakelt, werken geen redirects in de component en worden geen 404-fouten geregistreerd.

Ga naar Systeem → Beheer → Plugins, zoek op redirect en schakel de plugin in.

1.5 Je eerste redirect

Om handmatig een redirect aan te maken, open je Componenten → Redirects → Nieuw en vul je het volgende in:

Sla het formulier op en bezoek vervolgens /oud-artikel. De browser wordt doorgestuurd naar /nieuw-mooi-artikel met een 301-statuscode.

3. HTTP-statuscodes

3.1 Waarom de statuscode belangrijk is

Een redirect betekent niet alleen "ga hierheen in plaats daarvan". De HTTP-statuscode vertelt browsers, crawlers en algoritmes voor linkwaarde waarom de URL is verplaatst.

In de dagelijkse praktijk gebruik je meestal slechts twee codes: 301 voor "de pagina is definitief verhuisd" en 302 voor "slechts tijdelijk".

3.2 Aangepaste statuscodes inschakelen

Standaard dwingt de component elke redirect naar een 301-statuscode, ongeacht wat je in de regel hebt geselecteerd. Om de statuscode per regel te respecteren, moet je één instelling inschakelen:

Componenten → Redirects → Opties → Aangepaste redirect-statuscodes gebruiken = Ja

Zonder deze instelling is de keuzelijst HTTP-statuscode per regel slechts decoratief. Schakel dit in voordat je een CSV importeert die zowel 301- als 302-codes bevat, anders worden alle geïmporteerde regels stilzwijgend omgezet naar 301.

3.3 Hoe de redirect eruitziet

Wanneer de plugin een redirect uitvoert, ziet de response er zo uit:

HTTP/1.1 301 Moved Permanently
Location: https://site.tld/new-shiny-article

De oorspronkelijke querystring blijft behouden als de oude URL in je regel zelf geen querystring bevat. Als je bijvoorbeeld /search?q=foo hebt opgeslagen, maakt de query deel uit van de match en wordt deze niet toegevoegd aan de doel-URL.

5. De anatomie van een redirect

5.1 De enkele tabel

De volledige component draait op één databasetabel:

#__redirect_links     één regel per redirect of geregistreerde 404

Geen taxonomie, geen aparte metadata-tabellen en geen varianten per taal. De belangrijkste kolommen zijn:

id              auto-increment primary key
old_url         de gematchte URL (geïndexeerd)
new_url         de bestemming (NULL = onopgeloste 404)
referer         waar de bezoeker vandaan kwam
comment         vrije beheeropmerking
hits            verhoogd bij elke match
published       1=Ingeschakeld, 0=Uitgeschakeld, 2=Gearchiveerd, -2=Verwijderd
created_date    eerste keer dat deze URL werd gezien
modified_date   laatste wijziging door beheerder
header          HTTP-statuscode, standaard 301

Het veld old_url is de zoeksleutel. De index daarop houdt opzoekingen snel, zelfs met duizenden regels.

5.2 URL-normalisatie, de matchtruc

De plugin zoekt niet rechtstreeks op de ruwe URL die de bezoeker heeft opgevraagd. In plaats daarvan bouwt deze twaalf varianten op en voert één enkele WHERE old_url IN (...)-query uit:

1.  Volledige URL                  (schema + host + pad + query + fragment)
2.  Relatieve URL                  (pad + query + fragment)
3.  Root-relative                  (Uri::root() verwijderd)
4.  Root-relative met leidende "/"
5.  Zonder query                   (schema + host + pad + fragment)
6.  Relatief zonder query          (pad + fragment)
7-12. Dezelfde zes, maar in kleine letters

Wat dit in de praktijk betekent:

• Je kunt /oude-pagina of https://site.tld/oude-pagina opslaan. Beide werken.
• Hoofdletters zijn belangrijk bij opslag, maar dankzij de lowercase-varianten vindt /Old-Page alsnog /old-page.
• Een redirect voor /foo matcht zowel /foo als /foo?utm=x.
• Een redirect voor /foo?bar=1 matcht alleen /foo?bar=1. Querystrings in old_url vereisen een exacte match.

5.3 De onError-hook

De plugin abonneert zich op één event:

public static function getSubscribedEvents(): array
{
    return ['onError' => 'handleError'];
}

De handler stopt direct tenzij de foutcode exact 404 is en het verzoek niet uit het administrator-gedeelte komt. Backend-404’s worden bewust genegeerd, beheerders worden nooit doorgestuurd door hun eigen regels.

5.4 Waarom duplicaten gevaarlijk zijn

Wanneer de IN (...)-query meerdere regels retourneert, bijvoorbeeld omdat dezelfde URL zowel als volledige URL als relatieve URL is opgeslagen, kiest de plugin de eerste gepubliceerde match volgens de volgorde van de variantenlijst. De volledige URL komt eerst en wint dus van de relatieve URL.

De praktische regel: houd redirects in één consistente vorm, meestal root-relative paden. Sla dezelfde redirect niet op drie verschillende manieren op.

7. Meertalige redirects

7.1 URL’s per taal

Op een meertalige Joomla-site heeft elke vertaling zijn eigen URL, meestal voorafgegaan door een taalcode:

/en/old-article    →    /en/new-article
/nl/oude-pagina    →    /nl/nieuwe-pagina
/de/altes-zeug     →    /de/neuer-artikel

De component com_redirect is taalonafhankelijk. Er bestaat geen language-kolom in #__redirect_links. De match gebeurt puur op basis van de URL-string, dus je moet de taalprefix zelf opslaan.

7.2 De valkuil van cross-language redirects

Twee verleidelijke maar foutieve patronen komen vaak voor:

/en/old-article    →    /                  (redirect naar homepage)
/nl/oude-pagina    →    /en/new-article    (sprong naar andere taal)

Beide zorgen voor verwarring bij bezoekers en Google. Een Nederlandse bezoeker komt ineens op Engelstalige content terecht, of een Engelstalige bezoeker verliest volledig de context.

De regel is eenvoudig: redirect binnen dezelfde taal. Als een vertaling nog niet bestaat, stuur de URL dan door naar de dichtstbijzijnde equivalente pagina binnen dezelfde taal, bijvoorbeeld een categoriepagina of de homepage van die taal, niet naar de algemene site-root.

7.3 Menu-associaties versus redirects

Joomla’s meertalige menu-associaties regelen al “geef mij deze pagina in taal X” via de taalwisselaar. Dat is geen redirect maar een route.

Gebruik com_redirect alleen wanneer:

• Een artikel daadwerkelijk verhuisd is binnen één taal.
• Een volledig URL-patroon veranderde na een SEF-aanpassing in één taal.
• Een vertaling verwijderd werd en naar een logische bestemming moet verwijzen.

7.4 De valkuil van de Language Filter

De plugin System - Language Filter kan zelf redirects uitvoeren om een taalcode toe te voegen of te verwijderen. Wanneer beide plugins elkaar tegenspreken, ontstaat een redirectloop:

/article    →  /en/article   (Language Filter)
/en/article →  /article      (jouw redirectregel)
/article    →  /en/article   (weer dezelfde loop)

De oplossing is om de URL op te slaan nadat de Language Filter deze heeft verwerkt. Dat betekent dat je altijd de taalprefix opneemt in zowel old_url als new_url.

9. Veelvoorkomende valkuilen

9.1 Mijn redirect werkt niet

Doorloop deze checklist in deze volgorde:

1. Is plg_system_redirect ingeschakeld?
2. Staat de redirectregel op Ingeschakeld?
3. Is de Nieuwe URL ingevuld (niet NULL)?
4. Geeft de oude URL echt een 404 terug? Als de pagina nog bestaat, wordt geen redirect uitgevoerd, com_redirect reageert alleen op 404-fouten.
5. Is de oude URL opgeslagen in een vorm die de matcher herkent? Root-relative is de veiligste keuze.

9.2 Mijn statuscode blijft altijd 301

De componentoptie Aangepaste redirect-statuscodes gebruiken staat standaard op Nee. Totdat je deze op Ja zet, wordt elke redirect als 301 verstuurd, ongeacht de instelling per regel.

9.3 Redirects werken niet in de backend

Dat is bewust zo ontworpen. De plugin stopt direct wanneer $app->isClient('administrator') waar is. De component werkt alleen aan de frontend.

9.4 De database blijft groeien

Dat komt door registratie, niet door redirects. Zet URL’s verzamelen = Nee om nieuwe registraties te stoppen. Bestaande gepubliceerde redirects blijven gewoon werken. Dit is handig voor websites die constant scannerverkeer ontvangen.

9.5 Redirectloops

De component voert geen loopdetectie uit. Als je /a → /b en /b → /a instelt, blijft de browser rondsturen totdat deze opgeeft. Gebruik de SQL-query uit sectie 8.3 na elke bulkimport om loops op te sporen.

9.6 Redirectketens

Een keten zoals /a → /b → /c → /d werkt omdat elke stap een apart verzoek is, maar elke extra stap kost een roundtrip en vermindert SEO-waarde. Maak ketens vlak met de SQL uit sectie 8.3.

9.7 Querystrings en fragmenten

• Querystring in old_url: exacte match vereist.
• Geen querystring in old_url: matcht zowel met als zonder query.
• Fragmenten (#section): de browser verwijdert deze voordat het verzoek wordt verstuurd, dus je kunt niet redirecten op een fragment. Sla ze niet op.

9.8 SEF versus ruwe URL’s

Met SEF ingeschakeld is de zichtbare URL /old-article. Met SEF uitgeschakeld bevindt dezelfde content zich op /index.php?option=com_content&view=article&id=42. Dit zijn twee verschillende sleutels in de redirecttabel. Controleer je redirects opnieuw nadat je SEF hebt in- of uitgeschakeld.

9.9 Open-redirect beveiliging

De component laat je een oude URL doorsturen naar elke bestemming, inclusief externe domeinen. Dat is soms handig, maar het vormt ook een phishingrisico:

• Een gecompromitteerd beheerdersaccount kan redirects aanmaken naar een phishingwebsite die een bekend merk nabootst.
• Een vanuit zoekmachines geïndexeerde 404-URL kan worden doorgestuurd naar een schadelijke bestemming.
• Een oude redirect verwijst naar een domein dat verkocht werd en nu malware host.

De verdediging is eenvoudig: beperk de rechten Aanmaken en Bewerken op com_redirect tot een kleine, vertrouwde groep en controleer externe bestemmingen elk kwartaal:

SELECT id, old_url, new_url
FROM jos_redirect_links
WHERE published = 1
  AND new_url LIKE 'http%'
  AND new_url NOT LIKE 'https://site.tld/%';

9.10 Een redirect controleren met curl

Browsers cachen agressief en volgen redirects stilzwijgend. Gebruik voor debugging liever curl:

curl -I https://site.tld/old-article

Je wilt exact dit zien:

HTTP/2 301
location: https://site.tld/new-article
content-type: text/html; charset=utf-8

Een 200-response betekent dat de pagina geen 404 gaf en dus geen redirect werd uitgevoerd. Een 301 terwijl je een 302 verwachtte, betekent dat aangepaste statuscodes niet zijn ingeschakeld (zie sectie 3.2).

Gebruik -L en -v om een volledige redirectketen te volgen:

curl -I -L https://site.tld/old-article

Elke stap verschijnt in volgorde, ideaal om te controleren of een redirectketen correct is afgevlakt.

9.11 Redirect versus canonical

Een redirect en een canonical lijken op elkaar, maar lossen verschillende problemen op:

Beide combineren, een redirect plus een canonical op de doelpagina, is prima. Een canonical die verwijst naar een URL die zelf redirect, zorgt voor verwarring bij crawlers.

11. Component versus webserver-redirects

Je kunt redirects ook configureren in Apache’s .htaccess of in een NGINX-configuratie. Elke laag heeft zijn eigen rol:

Gebruik com_redirect voor redactionele redirects, zoals hernoemde artikelen en migraties. Gebruik de webserver voor infrastructuurregels, zoals HTTPS forceren, www naar hoofddomein omleiden en scanners blokkeren. Lagen combineren is prima, lagen willekeurig combineren maakt alles juist kwetsbaar.

13. Samenvatting

De Redirects-component is misschien het kleinste onderdeel van Joomla, maar vaak ook het onderdeel dat zichzelf het snelst terugverdient. Eén plugin, één component en één instelling zorgen ervoor dat hernoemde artikelen hun inkomende links en zoekmachineranking behouden.

Met minimale configuratie krijg je:

• 404-registratie: elke kapotte link wordt opgeslagen met hits en referrer.
• Gebruiksvriendelijk beheer: geen .htaccess-aanpassingen en geen devops-tickets nodig.
• SEO-correcte statuscodes: 301-redirects behouden de opgebouwde linkwaarde.
• Bulkimport voor migraties: pipe-gescheiden lijsten voor grote migraties.
• Eenvoud van één tabel: makkelijk te back-uppen, te controleren en uit te breiden.

Een nette redirecttabel is een teken van een goed onderhouden Joomla-site. Als je een migratie plant, URL-structuren wijzigt of vermoedt dat kapotte links zoekverkeer kosten, loont het om eerst naar com_redirect te kijken. Het zit al in je Joomla-installatie en wacht alleen nog om ingeschakeld te worden.