URL-structuur voor SEO: 10 regels en migratiechecklist

Een URL is het saaiste onderdeel van je website en tegelijk het onderdeel dat je het moeilijkst nog kunt wijzigen. Zodra een adres eenmaal gedeeld, gelinkt en geïndexeerd is, kost elke wijziging redirects, tijd en aandacht. Daarom loont het om de opbouw in één keer goed te doen. Deze gids legt eerst uit waaruit een URL technisch bestaat volgens RFC 3986 en MDN, geeft daarna tien regels waarvan er zeven onderbouwd zijn door de documentatie van Google en de IETF en drie onze eigen aanbeveling zijn, en sluit af met een checklist voor het geval je toch moet migreren. Alle feitelijke claims zijn gecontroleerd op 25 augustus 2026; waar wij een mening geven, staat dat er expliciet bij.

Waaruit bestaat een URL?

De generieke URI-syntaxis van RFC 3986 beschrijft een URL als "a hierarchical sequence of components referred to as the scheme, authority, path, query, and fragment": vijf onderdelen, waarvan er in de praktijk vaak maar drie zichtbaar zijn. De specificatie zelf gebruikt dit voorbeeld om de grenzen te tonen: foo://example.com:8042/over/there?name=ferret#nose.

Dat laatste punt heeft een direct gevolg voor SEO: als de inhoud van je pagina verandert op basis van wat er achter het hekje staat, ziet de server dat verschil nooit. Google zegt daar in de eigen URL-documentatie over dat het "generally doesn't support URL fragments" van het type example.com/#/potatoes.

Hoe vaak wordt hier in Nederland op gezocht?

De term url structuur werd in Nederland de afgelopen twaalf maanden gemiddeld 70 keer per maand gezocht, maar de vraag naar de onderliggende uitleg is veel groter: wat is een url staat op 1.000 zoekopdrachten per maand. Wij maten dit op 25 augustus 2026 via Google Ads-zoekvolumedata (DataForSEO, taak 08251948-2030-0367-0000-47ef49d21d73).

Interessanter dan de volumes is wat er in de zoekresultaten gebeurt. Bij onze SERP-meting op 25 augustus 2026 (DataForSEO, taak 08251948-2030-0139-0000-37b304be1997) opende de Nederlandse resultatenpagina voor url structuur met een zelfstandige AI Overview die precies de vijf onderdelen hierboven opsomt en drie Nederlandstalige bronnen citeert. Het hoogste organische resultaat stond daaronder. Van de tien organische resultaten in die meting dateerden er meerdere uit 2020 tot en met 2024 en waren het overwegend begrippenlijsten zonder uitvoeringsstappen. Dat is de opening voor dit artikel: de definitie is een ingang, de uitvoering is de reden om te blijven lezen.

Wat een URL wel en niet voor je posities doet

Googles eigen documentatie belooft nergens dat een zoekwoord in de URL op zichzelf hogere posities oplevert. Wat er wel staat, gaat over begrijpelijkheid en over crawlen: gebruik "readable words rather than long ID numbers in your URLs" en gebruik "words in your audience's language". Het rendement van een goede URL-structuur zit dus niet in een zoekwoordbonus, maar op drie andere plekken.

1. Crawlen. Googles documentatie over faceted navigation beschrijft hoe crawlers bij filter-URL's "typically access a very large number of faceted navigation URLs", waardoor nieuwe content trager wordt ontdekt. Je URL-ontwerp bepaalt dus mede hoeveel aandacht je belangrijke pagina's krijgen.
2. Canonicalisatie. Elke variant van hetzelfde adres is voor Google een aparte URL waarover een keuze gemaakt moet worden. Hoe consistenter je adressen, hoe minder die keuze aan het toeval wordt overgelaten.
3. Vertrouwen bij de bezoeker. Een adres dat vertelt waar je bent, is prettiger dan een reeks cijfers. Dat is ons oordeel, geen meting: wij hebben geen eigen cijfer over het effect van URL-tekst op klikgedrag, en we nemen liever geen getal over dat we niet zelf kunnen herleiden.

Tien regels voor een SEO-vriendelijke URL

Zeven van de tien regels hieronder zijn onderbouwd door primaire documentatie van Google of de IETF; sommige staan er letterlijk, andere zijn er de praktische vertaling van. De overige drie zijn onze aanbeveling, en die staan als zodanig gemarkeerd. Zo weet je precies welke regel je kunt verdedigen tegenover een ontwikkelaar en welke een keuze is.

Drie regels verdienen toelichting, omdat ze in de praktijk het vaakst misgaan.

Regel 8 is onze aanbeveling, maar hij rust op een harde eigenschap van de specificatie. RFC 3986 bepaalt dat scheme en host hoofdletterongevoelig zijn en "should be normalized to lowercase", terwijl de overige onderdelen "are assumed to be case-sensitive unless specifically defined otherwise by the scheme". Over het pad staat er dus geen voorschrift dat het kleine letters moet zijn; er staat dat hoofdletters een verschil maken. Technisch zijn /Diensten en /diensten daardoor twee verschillende adressen die allebei kunnen bestaan en allebei geïndexeerd kunnen raken. Consequent kleine letters is de eenvoudigste manier om dat te voorkomen: kies er één en dwing de andere af met een redirect.

Regel 3 speelt zodra je iets anders dan het Engelse alfabet gebruikt. Google noemt in de URL-documentatie expliciet dat niet-ASCII-tekens percent-encoded horen te worden en geeft gem%C3%BCse als voorbeeld voor gemüse. In het Nederlands raakt dit vooral trema's en accenten; de eenvoudigste route is die tekens gewoon niet in je pad opnemen.

Regel 10 kent geen documenteerde bovengrens. Google noemt in de doorgenomen documentatie geen maximumdiepte en geen maximale URL-lengte. Wij houden bij klanten drie tot vier padniveaus aan omdat diepere structuren in de praktijk vooral extra onderhoud en meer redirectrisico opleveren, maar dat is een werkafspraak en geen regel van Google. Wie een grondiger doorlichting van zijn sitestructuur wil, vindt de aanpak in onze handleiding voor een technische SEO-audit.

Canonicals: kies zelf welke versie de officiële is

Google beschrijft rel="canonical" als "a strong signal that the specified URL should become canonical", niet als een opdracht. Geef je geen voorkeur op, dan geldt: "Google will identify which version of the URL is objectively the best version to show to users in Search". Je kiest dus niet of Google canonicaliseert, alleen of jij daar invloed op uitoefent.

De documentatie zet de methoden op volgorde van kracht en merkt op dat ze stapelbaar zijn: "these methods can stack and thus become more effective when combined".

Twee concrete punten uit dezelfde documentatie. Ten eerste: "Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals". Staat je site nog deels op HTTP, dan is een redirect of een canonical van HTTP naar HTTPS de manier om die uitzondering te voorkomen. Ten tweede: "When linking within your site, link to the canonical URL rather than a duplicate URL". Interne links zijn dus geen neutraal detail maar onderdeel van je canonicalisatiestrategie. Vind je het lastig te controleren welke versie Google daadwerkelijk gekozen heeft, dan geeft de URL-inspectie in Search Console het antwoord; hoe je die leest, staat in onze Google Search Console-handleiding.

Filters en faceted navigation

Filters op een webshop of overzichtspagina kunnen een zeer groot aantal URL's opleveren. Google beschrijft het mechanisme zo: omdat filter-URL's nieuw lijken en crawlers pas na het crawlen kunnen vaststellen of ze nuttig zijn, benaderen ze er "a very large number" van. Het risico dat Google daarbij noemt is tweeledig: het crawlen van die URL's verbruikt resources, en doordat er crawltijd naar nutteloze URL's gaat, blijft er minder over voor nieuwe en nuttige URL's. In Googles eigen woorden: "if crawling is spent on useless URLs, the crawlers have less time to spend on new, useful URLs".

De aanbevelingen uit diezelfde documentatie zijn ongewoon concreet:

• Gebruik de standaard scheidingstekens. Google adviseert "the industry standard URL parameter separator" en waarschuwt dat komma, puntkomma en blokhaken "hard for crawlers to detect as parameter separators" zijn.
• Houd de volgorde vast. Zet je filters in het pad, dan moet de volgorde logisch en consistent zijn en mag een filter niet dubbel voorkomen. Anders maakt elke volgorde een nieuwe URL van dezelfde pagina.
• Blokkeer met robots.txt wat je niet nodig hebt. Dat spaart servercapaciteit uit.
• Wees voorzichtig met nofollow. Google noemt rel="nofollow" op filterlinks mogelijk nuttig, maar met een harde voorwaarde: "every anchor pointing to a specific URL must have the rel="nofollow" attribute in order for it to be effective". Een enkele vergeten link maakt de maatregel ongedaan.
• Reken niet op canonicals alleen. Volgens Google kunnen die op termijn het crawlvolume van niet-canonieke varianten verlagen, maar zijn ze "generally less effective in the long term".

Voor webshops komt hier de vraag bovenop welke filtercombinaties eigen zoekvraag hebben en dus juist wel een vindbare pagina verdienen. Die afweging behandelen we in onze gids voor webshop-SEO.

Redirects: wat Google herkent en in welke volgorde

Google maakt onderscheid tussen permanent en tijdelijk: permanente redirects "show the new redirect target in search results", tijdelijke redirects "show the source page in search results". Bij een permanente redirect gebruikt de indexeringspijplijn de redirect als signaal dat het doel canoniek hoort te zijn.

Over ketens is Google eveneens expliciet: "Avoid chaining redirects. While Googlebot can follow up to 10 hops in a 'chain' of multiple redirects, we advise redirecting to the final destination directly". Bij een migratie betekent dat: verwijs oude URL's rechtstreeks naar hun eindbestemming, ook als de site in de tussentijd al eens eerder verhuisd is.

Migratiechecklist: URL's wijzigen zonder onnodig verlies

Google zet een verhuizing met URL-wijzigingen in vier hoofdstappen: bereid de nieuwe site voor en test die grondig, maak een mapping van oude naar nieuwe URL's, start de verhuizing door de server te laten redirecten, en bewaak daarna het verkeer op oude en nieuwe URL's. Hieronder de checklist zoals wij die bij klanten aflopen, met per stap de bijbehorende documentatie.

1. Maak de mapping compleet. Verzamel bestaande URL's uit sitemaps, serverlogs en analytics en bepaal per adres de nieuwe bestemming. Zonder deze lijst is de rest gokwerk.
2. Zet op elke nieuwe pagina een self-referencing canonical. Google: "Each new URL should have a self-referencing rel="canonical" link tag".
3. Werk hreflang-annotaties bij als je meertalige of internationale pagina's hebt, zodat ze naar de nieuwe URL's wijzen.
4. Controleer robots.txt en noindex op de nieuwe omgeving. Wie tijdens de bouw alles blokkeerde, moet dat expliciet terugdraaien. Dit is de klassieke manier om een verhuizing stil te laten mislukken.
5. Zet server-side permanente redirects. Google adviseert 301 of 308 waar dat technisch kan, rechtstreeks naar de eindbestemming.
6. Update je interne links. Google: "Change the internal links on the new site from the old URLs to the new URLs", op basis van diezelfde mapping. Redirects zijn een vangnet, geen navigatie.
7. Test de redirects. Voor losse adressen met de URL-inspectie in Search Console, voor grote aantallen met een script of commandoregeltool.
8. Dien de nieuwe sitemap in. Google: "Submit the new sitemap in Search Console. This will help Google learn about the new URLs. At this point you can remove your old sitemap, since Google will use the new sitemap going forward." De oude sitemap hoeft dus niet aangehouden te worden.
9. Dien alleen een Change of Address in bij een domeinwissel. Google beperkt die tool tot verhuizingen tussen domeinen of subdomeinen en noemt hem expliciet niet nodig voor HTTP naar HTTPS of voor wisselen tussen www en non-www op hetzelfde domein.
10. Knip grote verhuizingen op. Google: "Split your move into smaller steps, if that makes sense for your site", zodat je het effect op verkeer en indexering eerst op een deel kunt zien.

Wat je qua doorlooptijd mag verwachten, zegt Google zelf: "Expect temporary fluctuation in site ranking during the move", en als vuistregel duurt het "for medium-sized websites, it can take a few weeks or more" voordat Google de nieuwe URL's toont in plaats van de oude, bij grotere sites nog langer. Percentages voor verwacht verlies staan er niet bij, en wij noemen ze daarom ook niet: het tempo hangt volgens dezelfde documentatie vooral af van het aantal URL's en de snelheid van je server.

Structuur per paginatype: ons advies

Voor de indeling per paginatype bestaat geen Google-voorschrift. Wat hieronder staat is onze werkafspraak, gebaseerd op wat in klantprojecten het minste onderhoud oplevert, niet op documentatie. Behandel het als een startpunt dat je aan je eigen navigatie toetst.

De vraag of een blog op een subdomein of in een submap hoort, laten we bewust open. In de vijf Google-documenten die we voor dit artikel hebben doorgenomen staat geen voorkeur voor een van beide. Wel is duidelijk dat wisselen tussen die twee volgens Google als siteverhuizing telt, inclusief Change of Address bij een subdomeinwissel. Maak de keuze daarom op de afwegingen die je zelf kunt beoordelen: hoe je de site wilt beheren, wat je techniek en hosting toelaten, en wie binnen de organisatie eigenaar is van het platform. Dat een latere wissel werk en kosten meebrengt, is een reden om de keuze bewust te maken, niet om te veronderstellen dat een van beide varianten beter scoort. Die vergelijking maken wij hier niet, omdat de doorgenomen documentatie er geen uitspraak over doet.

Vijf fouten die we in audits blijven zien

Deze vijf komen uit ons eigen auditwerk. We noemen er bewust geen frequenties bij, omdat we die niet systematisch loggen.

1. Beide hoofdlettervarianten leven. /Diensten en /diensten geven allebei een 200 en niemand merkt het, tot Google de verkeerde kiest.
2. Redirectketens na een tweede verbouwing. Oud naar minder oud naar nieuw. Volgens Googles eigen advies hoort de eerste stap rechtstreeks naar de eindbestemming te wijzen.
3. Interne links die nog naar de oude URL wijzen. De redirect vangt het op, maar je eigen navigatie vertelt Google dan iets anders dan je canonical.
4. Filterparameters zonder plan. Elke combinatie is een URL, elke volgorde een nieuwe combinatie.
5. Een noindex of robots.txt-blokkade uit de bouwfase die nooit is teruggedraaid. Google waarschuwt hier in de verhuisdocumentatie expliciet voor, en het blijft de stilste manier om een lancering te laten mislukken.

Veelgestelde vragen over URL-structuur

Wat is een URL?

Een URL is het adres waarmee een bron op het web wordt aangewezen. RFC 3986 beschrijft de opbouw als een hiërarchische reeks van vijf onderdelen: scheme, authority, pad, query en fragment. In een alledaags adres als https://www.picoyellow.nl/kennisbank/url-structuur-best-practices zie je daarvan het scheme (https), de authority (www.picoyellow.nl) en het pad.

Hoe ziet een URL eruit?

RFC 3986 gebruikt zelf dit voorbeeld: foo://example.com:8042/over/there?name=ferret#nose. Daarin is foo het scheme, example.com:8042 de authority met poortnummer, /over/there het pad, name=ferret de query achter het vraagteken en nose het fragment achter het hekje.

Hoe maak je een URL voor een nieuwe pagina?

Neem het pad van de bovenliggende pagina over en voeg een korte, beschrijvende naam toe in kleine letters, met koppeltekens tussen de woorden. Google adviseert leesbare woorden in plaats van ID-nummers en koppeltekens in plaats van underscores. Vermijd accenten en trema's, of encodeer ze percent-gewijs. Publiceer daarna niet nog een tweede variant van hetzelfde adres.

Waar vind ik de URL van een pagina?

In de adresbalk van je browser. Kopieer die volledig, inclusief het https://-deel, als je hem ergens moet invullen. Let op wat er achter een vraagteken staat, want niet elke queryparameter doet hetzelfde. Trackingparameters zoals utm_source of gclid horen bij de meting en niet bij de pagina; die kun je bij het delen weglaten. Parameters die de inhoud bepalen, bijvoorbeeld een filter of een paginanummer, horen wel bij het adres: haal je die weg, dan kom je op een andere pagina uit.

Mag ik de URL van een pagina wijzigen nadat hij online staat?

Het mag, maar het kost werk. Google adviseert een server-side permanente redirect van oud naar nieuw, rechtstreeks naar de eindbestemming, plus bijgewerkte interne links en een nieuwe sitemap. Reken op tijdelijke schommelingen: Google noemt "temporary fluctuation in site ranking during the move" en voor middelgrote sites een doorlooptijd van enkele weken of langer.

Maakt het uit of ik hoofdletters in een URL gebruik?

Ja. Volgens RFC 3986 zijn alleen scheme en host hoofdletterongevoelig; de overige onderdelen gelden als hoofdlettergevoelig, tenzij het scheme iets anders bepaalt. /Diensten en /diensten zijn dus twee verschillende adressen. Consequent kleine letters aanhouden en de andere variant laten redirecten is onze aanbeveling om te voorkomen dat beide varianten naast elkaar gaan leven.

Hoe lang mag een URL zijn?

Google noemt in zijn URL-documentatie geen maximumlengte en geen maximale padopbouw. De praktische grens is leesbaarheid: een adres dat je in een gesprek kunt uitspreken, is meestal ook goed genoeg voor een zoekresultaat. Wij houden bij klanten drie tot vier padniveaus aan, maar dat is onze werkafspraak en geen regel van Google.

Wat doe ik met filter-URL's op een webshop?

Gebruik de standaard ampersand als scheidingsteken en vermijd komma's, puntkomma's en blokhaken, die volgens Google lastig als scheidingsteken te herkennen zijn. Houd de volgorde van filters consistent en voorkom dubbele filters. Blokkeer met robots.txt wat je niet gecrawld wilt hebben. Reken niet op canonicals alleen: die zijn volgens Google op lange termijn minder effectief voor dit doel.

Bronnen en meetmoment

• Google Search Central: URL Structure Best Practices for Google Search, gecontroleerd 25 augustus 2026.
• Google Search Central: How to Specify a Canonical with rel="canonical" and Other Methods, gecontroleerd 25 augustus 2026.
• Google Search Central: Redirects and Google Search, gecontroleerd 25 augustus 2026.
• Google Search Central: Site Moves and Migrations, gecontroleerd 25 augustus 2026.
• Google Crawling Infrastructure: Managing crawling of faceted navigation URLs, gecontroleerd 25 augustus 2026.
• IETF RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, gecontroleerd 25 augustus 2026.
• MDN Web Docs: What is a URL?, gecontroleerd 25 augustus 2026.
• Google Ads-zoekvolumedata Nederland via DataForSEO, taak 08251948-2030-0367-0000-47ef49d21d73, gemeten 25 augustus 2026.
• Google Nederland SERP via DataForSEO (AI Overview-waarneming, PAA-vragen als FAQ-basis, ouderdom van de top-10), taak 08251948-2030-0139-0000-37b304be1997, gemeten 25 augustus 2026.
• DataForSEO-zoekvolumemeting voor url structuur, seo url, seo vriendelijke url, url opbouw en url structuur seo, taak 08251939-2030-0607-0000-95e8fd6ac8bf; SERP-meting voor url structuur, taak 08251944-2030-0139-0000-caee277f9a34, 25 augustus 2026.