Moet ik de oude redirects na een jaar verwijderen?

Veel migratieteams houden ze minstens een jaar aan. Daarna, houd ze zolang oude URL's nog externe links of verkeer krijgen. Redirects kosten bijna niets om te serveren, dus er is zelden een goede reden om ze vroeg te verwijderen.

Is het oké om alleen de geïndexeerde pagina's te redirecten?

Niet als de niet-geïndexeerde pagina's links bevatten. Index status zegt weinig over externe waarde. Redirect elke URL die een linking domain heeft, en beslis daarna over de rest op basis van verkeer.

Wat met 302 of 307 voor een permanente verplaatsing?

Gebruik 301 of 308 voor permanente verplaatsingen. Een 302 die jarenlang blijft staan, kan als permanent worden behandeld, maar dat resultaat is aan het toeval overgelaten, en andere clients van de redirect kunnen het anders raden.

Kan ik 404s van de oude site naar de nieuwe redirecten?

Alleen als er een goede match bestaat. Een redirect naar een ongerelateerde pagina is in de ogen van Google een soft 404. Retourneer een echte 404 of 410 als de inhoud weg is.

Recipe voor een redirectmap: rank oude URL's op basis van de links die ze bevatten

Een redirectmap is een prioriteitenlijst, geen spreadsheet met elke URL. Begin met de pagina's waarnaar andere sites linken, en de rest van de map wordt makkelijker.

ArchiLinks onderzoeksteam · Bijgewerkt 2026-10-29

Werk die waardevolle gouden bakstenen sorteert van grijze stenen op een werkbank

Waarom ranken op basis van links

Teams bouwen mappen vanuit de crawl. Die is compleet. Maar hij behandelt ook een vergeten perspagina uit 2014 hetzelfde als de homepage.

Wanneer je backlinks naar mijn site controleert en de pagina's sorteert op aantal linking domains, zie je een patroon bij de meeste migraties: een paar tientallen URL's dragen de meeste externe waarde. Die URL's worden handmatig gekoppeld, tweemaal gecontroleerd en als eerste getest.

Alles anders volgt regels. Mappen worden gekoppeld op patroon, parameters worden verwijderd, en orphan URLs zonder links en zonder verkeer kunnen een 410 retourneren als je dat besluit. Koppel de output aan de migratie checklist zodat de map voor de lancering wordt getest en op dag 45 opnieuw wordt gecontroleerd, en aan de API scripts voor het plannen van de maandelijkse pull.

Stap 1: de gelinkte pagina's ophalen

Eén call retourneert maximaal 1.000 rijen en kost 2 credits, ongeacht het aantal rijen. De veldnamen hieronder zijn een voorbeeld; bekijk een echte response en pas de keys aan.

python

import csv, requests

BASE = "https://archilinks.com/api.php"
KEY = "sk_live_..."

def call(action, **params):
    r = requests.get(BASE, params={"action": action, "key": KEY, **params}, timeout=30)
    r.raise_for_status()
    return r.json()

data = call("toppages", q="old-shop.com", per=1000)
rows = next(v for v in data.values() if isinstance(v, list))

with open("linked-pages.csv", "w", newline="") as f:
    w = csv.writer(f)
    w.writerow(["old_url", "links", "new_url"])
    for row in rows:
        w.writerow([row.get("url"), row.get("backlinks"), ""])

Stap 2: de derde kolom invullen

Koppelen op betekenis

Een productpagina gaat naar hetzelfde product, of naar de categorie als het product weg is. Niet naar de homepage, tenzij de pagina de homepage was.

Laat een tweede persoon de top 50 controleren

Een vermoeide persoon om 18.00 uur koppelt een gids over canonicals aan een blogindex. Een reviewer vangt dit op.

Regels voor de long tail

Schrijf patronen voor mappen en verwijder trackingparameters. Houd elke regel in versiebeheer met een commentaar dat uitlegt waarom.

Stap 3: serverregels genereren

nginx leest een mapbestand goed, en het schaleert tot tienduizenden regels.

nginx

# /etc/nginx/redirects.map  (generated from the csv)
/old/guide-canonicals    /guides/canonical-tags;
/products/blue-widget    /shop/widgets/blue;

# in nginx.conf, http context
map $request_uri $new_uri {
    default "";
    include /etc/nginx/redirects.map;
}

# in the server block of the old host
if ($new_uri) {
    return 301 https://new-shop.com$new_uri;
}

Metalen hendel die een stenen blok in een brugstructuur vergrendelt

Stap 4: elke hop testen

Laat de pipeline falen op alles wat geen enkele 301 is naar een 200.

bash

while IFS=, read -r old new; do
  out=$(curl -s -o /dev/null -w "%{http_code} %{num_redirects} %{url_effective}" -L "https://old-shop.com$old")
  echo "$old -> $out"
done < redirect-pairs.csv | grep -v "^.* -> 200 1 " && echo "FIX ABOVE"

Fouten die we eerst zouden controleren

Symptoom	Waarschijnlijke oorzaak	Oplossing
Ketens van twee of drie hops	Oude regels gestapeld op nieuwe	Wijs de oude regel rechtstreeks naar de definitieve URL
Alles landt op de homepage	Luie catch-all regel	Koppel op onderwerp; Google kan massale redirects naar de homepage behandelen als soft 404s
Query strings verloren	Regel laat de argumenten vallen	Neem de parameters mee die de inhoud wijzigen; verwijder de rest
Top URL retourneert 404 na lancering	Niet opgenomen in de CSV	Voer de pull opnieuw uit en diff het tegen de live map

Tuinman snoeit een complexe struik terwijl een slang een eenvoudig veld besproeit

Welke URL's verdienen een handmatig gekoppelde rij

Niet elke URL verdient een persoon. Een nuttige verdeling is op basis van linking domains: elke URL met meerdere externe sites die er naar linken, wordt handmatig gekoppeld, en de rest volgt een regelset. Stel je hebt 4.000 oude URL's en 60 van hen bevatten de meeste externe links. Die zestig nemen een middag review in beslag, terwijl de andere 3.940 een patroon en een test nodig hebben.

Houd de drempelwaarde in het script, niet in iemands hoofd. Vijf linking domains is een verstandig startpunt voor een middelgrote site. Begin daar. Verlaag het aantal als de hele site weinig links heeft, en verhoog het als de handmatige lijst te lang wordt voor één reviewer.

Handmatig en regel-gekoppelde rijen gescheiden houden

Handmatig gekoppelde rijen krijgen een benoemde reviewer en een notitie waarom het doel is gekozen. Regel-gekoppelde rijen krijgen een patroon getest tegen de hele map, zodat een uitzondering zichtbaar wordt in het testrapport voor de lancering, in plaats van in een verkeersgrafiek achteraf.

Gemengde gevallen veroorzaken de meeste verwarring. Een product dat is stopgezet en vervangen door een opvolger, wordt gekoppeld aan de opvolger. Eén gestopt product zonder opvolger hoort bij de categorie, nooit bij de homepage.

Een tweede pull gebruiken om te zien wat is verplaatst

Voer refdomains uit voor de oude host voordat de map definitief is, en opnieuw na de lancering, en koppel de twee lijsten per domain. Een linking domain die ontbreekt in de tweede pull is een vraag voor de link-eigenaar, geen reden tot alarm, omdat een verwijderde link even kan duren voordat deze in de index verschijnt.

Bewaar beide bestanden naast elkaar in de migratiemap, met de datum in elke naam. De diff vertelt je waar je moet kijken, en de map vertelt je wat je er aan hebt gedaan.

Bepalen wat te doen met URL's zonder links

Orphan URL's zonder links en zonder verkeer zijn het makkelijke deel. Retourneer een duidelijke 404 of een 410 als de inhoud voor altijd weg is, en redirect alleen als er een goede vervanging bestaat, zodat bezoekers en crawlers ergens nuttigs landen.

Als je twijfelt, laat een korte notitie in de map achter en kom terug na de eerste week logs. Je serverlog toont welke oude adressen nog steeds requests krijgen, wat het beste bewijs is dat je zult hebben.

Hoe de map past in een release

Een redirectmap verandert met de site. Houd dat in gedachten. Nieuwe pagina's verschijnen, oude worden hernoemd, en een sjabloonwijziging kan een regel breken die vorige maand veilig leek. Behandel de map als code, met één bestand in versiebeheer, een review voor elke deploy en een testrun bij elke wijziging.

Houd de map in één laag waar mogelijk. Redirects verspreid over de applicatie, de CDN en de CMS zijn hoe ketens ontstaan, en ketens zijn moeilijk te sporen zonder een volledige crawl.

Waar de regels moeten leven

Een servermap is snel en eenvoudig te testen. Een CMS-plugin is handig voor een handvol pagina's, maar moeilijk te auditen op schaal. Wat je ook kiest, de one-hop test moet vanuit dezelfde plek lezen.

Als twee lagen dezelfde URL redirecten, rapporteert de test een keten. Verwijder de duplicaat uit de laag die je van plan bent af te bouwen.

Testen op de echte host na elke wijziging

Voer de hop test uit op staging, en daarna op productie, na elke wijziging in het regelbestand. Een regel die slaagt op staging, kan nog steeds falen zodra een cache een oude response vasthoudt, dus de tweede run is belangrijk.

Sla de output op met de datum. Als een top URL maanden later kapot gaat, toont het oude resultaat of de regel is veranderd of de site. De migratie checklist vermeldt wanneer die test hoort, en het eerst uitvoeren houdt de volgende controle vergelijkbaar met deze.

Een wijziging in het regelbestand reviewen

Benoem één reviewer voor wijzigingen in de map, en vraag die persoon drie dingen te controleren: of elk doel nog steeds bij het onderwerp past, hoeveel hops de regel creëert, en of het patroon smal genoeg is om alleen de URL's aan te spreken waarvoor het is geschreven. Een wijziging die niemand heeft gecontroleerd, is de meest waarschijnlijke oorzaak van een keten.

Vraag dezelfde review wanneer de site zelf verandert. Een nieuwe categorie die een oude map absorbeert, kan een correcte regel naar de verkeerde plaats laten wijzen zonder dat iemand de map bewerkt.

Bewaar de notitie van de reviewer naast de wijziging. Zes maanden later verklaart de notitie een regel die er anders willekeurig uitziet, en het bespaart een tweede onderzoek van dezelfde vraag.

Een sample testen voordat de volledige run

Voordat je de hele lijst uitvoert, kies een sample van vijftig rijen dat de top gelinkte pagina's mengt met een paar gewone. Voer de hop test eerst op dat sample uit. Het sample is snel te lezen, en een regel fout verschijnt erin lang voordat het in het volledige bestand verschijnt.

Neem ten minste één rij van elk regel patroon, en één uit elke handmatig gekoppelde groep. Een patroon dat een map van twee honderd URL's dekt, wordt alleen getest door de rijen die toevallig in het sample zitten, dus kies ze met opzet.

Regelbestanden klein houden

Een regelbestand dat groter wordt dan een paar honderd patronen, wordt moeilijk te reviewen. Splits het per sectie van de site, en houd elk bestand kort genoeg zodat een reviewer het in één keer kan lezen.

Verwijder een regel op de dag dat de map weg is. Oude regels die achterblijven, zijn degene die later verkeer in een keten sturen.

Voordat de map live gaat

Elke rij heeft een nieuwe URL, of een bewuste 404 of 410.
Geen doel is zelf een redirect.
De 50 URL's met de meeste linking domains zijn gecontroleerd door een tweede persoon.
Query parameters die de inhoud wijzigen, worden meegenomen.
Het regelbestand staat in versiebeheer, met een commentaar op elk patroon.
Een referring-domain baseline wordt opgeslagen voor de post-launch diff.

Redirect vragen die steeds terugkomen

Moet ik de oude redirects na een jaar verwijderen?: Veel migratieteams houden ze minstens een jaar aan. Daarna, houd ze zolang oude URL's nog externe links of verkeer krijgen. Redirects kosten bijna niets om te serveren, dus er is zelden een goede reden om ze vroeg te verwijderen.
Is het oké om alleen de geïndexeerde pagina's te redirecten?: Niet als de niet-geïndexeerde pagina's links bevatten. Index status zegt weinig over externe waarde. Redirect elke URL die een linking domain heeft, en beslis daarna over de rest op basis van verkeer.
Wat met 302 of 307 voor een permanente verplaatsing?: Gebruik 301 of 308 voor permanente verplaatsingen. Een 302 die jarenlang blijft staan, kan als permanent worden behandeld, maar dat resultaat is aan het toeval overgelaten, en andere clients van de redirect kunnen het anders raden.
Kan ik 404s van de oude site naar de nieuwe redirecten?: Alleen als er een goede match bestaat. Een redirect naar een ongerelateerde pagina is in de ogen van Google een soft 404. Retourneer een echte 404 of 410 als de inhoud weg is.