Redirect API en regels als code: CI/CD voor veiligere URL-wijzigingen

Redirects beginnen vaak als kleine fixes. Een product-URL verandert. Een helpartikel verhuist. Een campagnepagina krijgt een nieuwe slug. Iemand voegt een regel toe in next.config.js, Cloudflare, een CMS-plugin of Nginx.

Dat werkt zolang het klein blijft. Bij een migratie, domeinwissel, webshop-replatforming of campagne met partners wordt dezelfde aanpak broos.

Een redirectregel bepaalt dan waar oude links, betaalde clicks, QR-codes, affiliate-links, supportartikelen en geindexeerde pagina's terechtkomen. Dat is geen losse technische regel meer. Het is productieconfiguratie voor verkeer.

Een betere aanpak behandelt redirects als deploybare configuratie: regels in een gestructureerd formaat, CI-validatie, staging met echt gedrag, een versioned snapshot in productie en rollback voordat verkeer verschuift.

Waarom redirects in de releaseflow horen

Teams reviewen al database migrations, feature flags, middleware en infrastructuur. Redirects die SEO, campagnes of omzet raken, verdienen hetzelfde proces.

De zwakke workflow ziet er vaak zo uit:

• SEO beheert een spreadsheet
• engineering kopieert regels naar appconfiguratie
• marketing past campagnedoelen aan in een aparte tool
• een CMS-plugin maakt onzichtbare redirects
• het CDN normaliseert hosts
• bij fouten weet niemand welke laag reageerde

Regels als code maken van de redirect map een reviewbaar artefact. Dat kan YAML, JSON, Terraform, CSV of een API-payload zijn. Belangrijker dan het formaat: eigenaarschap, tests en rollback.

Een regel heeft meer nodig dan bron en doel

old_url en new_url zijn genoeg om te redirecten. Ze zijn niet genoeg om veilig te beheren.

Gebruik een contract dat de intentie vastlegt:

{
  "source": "/oude-prijzen",
  "destination": "/prijzen",
  "status": 301,
  "match": "exact",
  "queryPolicy": "preserve_allowlist",
  "preserveQuery": ["utm_source", "utm_medium", "utm_campaign", "gclid"],
  "owner": "growth",
  "reason": "prijzenpagina samengevoegd",
  "expiresAt": null
}

Voor migraties en ecommerce voeg je priority, locale, land, device, batch, review status en fallback toe.

Google koppelt redirectkeuze aan intentie: hoe permanent is de wijziging, en welke URL moet in Search verschijnen? CI kan die keuze niet maken, maar kan wel verkeerde combinaties blokkeren.

API-sync voorkomt handmatig overtypen

Redirects ontstaan op meerdere plekken. Een CMS wijzigt slugs. Een Shopify-, WooCommerce- of headless catalogus verwijdert producten. Een docs-team publiceert een nieuwe versie. Een SEO-bureau levert een migratiemap. Een partner heeft branded links nodig.

Als elke bron handmatig wordt overgenomen, loopt de operatie uit elkaar.

Een Redirect API geeft een duidelijk contract:

Cloudflare biedt redirectregels via de Rulesets API. Next.js en Vercel ondersteunen redirects in configuratie. Dat zijn uitvoeringslagen. De moeilijkere vraag is governance: validatie, owner, staging, analytics en rollback.

Wat CI moet controleren

Een CI-job voor redirects moet gedrag testen, niet alleen syntaxis.

Zinvolle checks:

• dubbele source paths
• ongeldige destinations
• ontbrekende owner, reason of status
• wildcard of regex die exact rules overschaduwt
• permanente status op tijdelijke campagnes
• bestemming met 404, 410, 5xx of onverwachte redirect
• te lange redirect chains
• loops
• verlies van UTM, click ID, coupon of partner ID
• land-, device-, header- of queryconditions zonder fallback
• overlap met een andere batch

Voor risicovolle URL's gebruik je een requestmatrix:

source=/oude-prijzen
country=NL
device=desktop
query=?utm_source=google&gclid=test
expectedStatus=301
expectedDestination=/prijzen?utm_source=google&gclid=test

Dan is redirectwerk onderdeel van release engineering, niet van spreadsheetonderhoud.

Staging moet de uiteindelijke route tonen

Een redirect-stagingomgeving moet een simpele vraag beantwoorden: wat gebeurt er in productie met deze URL en deze context?

Toon:

• gematchte regel
• status code
• final destination
• query handling
• condition results
• concurrerende regels
• chain length
• owner en batch
• diff met het gepubliceerde snapshot

GitHub Actions environments kunnen reviewers vereisen voordat deployment doorgaat. Hetzelfde patroon past bij redirects: CI valideert, staging levert bewijs en productie wacht op de juiste approval.

Rollback hoort bij de feature

Een redirect terugdraaien mag niet betekenen dat de origin-app opnieuw moet worden gedeployed.

Bewaar gepubliceerde snapshots. Tag imports. Scheid tijdelijke campagne-redirects van permanente migratieregels. Maak emergency overrides zichtbaar.

Als een redirect invloed heeft op search, paid traffic, support of omzet, is rollback een vereiste.

Waar UrlEdge past

UrlEdge helpt teams die redirects willen automatiseren zonder elke URL-wijziging aan een appdeploy te koppelen.

• API voor domeinen, regels, publishing en automation
• Redirect Management voor ownership, analytics, snapshots en rollback
• Bulk URL Management voor migratiemappen en grote imports
• Advanced Redirect Rules voor wildcard, regex, query en conditions
• Redirect Checker voor route- en status-QA
• Collaboration voor approvals tussen SEO, marketing, platform en agencies

Laat kleine app-eigen redirects in de applicatie. Laat simpele hostnormalisatie bij het CDN. Gebruik een API en regels als code wanneer review, bewijs, automatisering en snelle recovery belangrijk zijn.

FAQ

Wat betekent redirect rules as code?

Redirectregels staan in een gestructureerd, reviewbaar formaat en gaan door validatie, staging, publishing en rollback.

Moeten alle redirects in Git?

Nee. Git werkt goed voor stabiele regels en migraties. API-sync werkt beter voor regels uit CMS, ecommerce, partners of interne tools.

Kan CI/CD redirects direct publiceren?

Ja, mits validatie, staging, permissies, approval voor risicovolle wijzigingen en rollback aanwezig zijn.

Bronnen

• Google Search Central: Redirects and Google Search
• Cloudflare Rules docs: Create a redirect rule via API
• Next.js docs: next.config.js redirects
• GitHub Docs: Managing environments for deployment