Kort fortalt
Google redigerede 21. oktober 2026 afsnittet om bindestreger i sin URL-vejledning; rådet er det samme, og Gary Illyes kaldte en uge før ord i URL'en "an incredibly small signal". Samme side anbefaler at procent-kode tegn uden for ASCII, men nævner hverken ASCII-formerne for æ, ø og å eller Unicode-normalisering. I min test 25. oktober gav fem slug-funktioner i Python, Node og PHP alle arsrapport og sogeordsanalyse, ikke den danske konvention med aa og oe. WordPress gør kun det danske, når sproget er sat til da_DK. Og å kan lagres som to forskellige tegnsekvenser, hvor den ene gav 404 på begge statiske servere, jeg testede.
Bindestreg frem for underscore har været Googles råd i årevis, og redigeringen 21. oktober flytter ikke noget. Det, et dansk site bør tjekke, er om æ, ø og å bliver til den samme URL hver gang: ét ord som årsrapport kan give fire forskellige adresser, alt efter hvilken funktion der laver sluggen.
Hvad Google ændrede
Googles side om bedste praksis for URL-struktur står som opdateret 21. oktober 2026, og ændringsloggen fører den som en præcisering af ordadskillelse med bindestreg og underscore. Search Engine Roundtable sammenlignede den gamle og nye tekst: Kun afsnittet om bindestreger er redigeret, og meningen er den samme. Den nye version siger, at bindestreger tydeligt markerer en ordgrænse, og at Google "af historiske årsager" ikke anbefaler underscore.
De historiske årsager er gamle. I juli 2007 refererede Search Engine Roundtable Matt Cutts for, at underscore snart ville blive behandlet som ordadskiller. Nitten år senere, i Search Central-serien The Non-Canonical Cabinet 14. oktober 2026, sagde Gary Illyes ifølge Relevant Audiences referat, at ord forbundet med underscore læses som ét langt ord. I samme afsnit kaldte han søgeord i URL'en et meget lille signal, som kun betyder noget, når Google ikke har andet at gå efter, og som bliver stort set irrelevant, så snart indholdet kan ses.
Spørgsmålet om bindestreg eller underscore er altså afgjort, og det vejer lidt. Det interessante står længere nede på samme side.
Den del af vejledningen, danske sites bør læse
Vejledningen anbefaler ord på målgruppens eget sprog i stien og siger, at tegn uden for ASCII skal procent-kodes i links. Eksemplet er tysk: gemüse skrives gem%C3%BCse. Siden understreger også, at URL'er skelner mellem store og små bogstaver, så /APPLE og /apple er to adresser.
Det, siden ikke tager stilling til, er de to valg, et dansk site faktisk står over for: om æ, ø og å skal blive i URL'en eller oversættes til ASCII, og i givet fald til hvad. Og den nævner ikke Unicode-normalisering, som er det, der kan gøre to identisk udseende URL'er til to forskellige.
Jeg kørte tre ord gennem fem slug-funktioner
Den 25. oktober 2026 kørte jeg "søgeordsanalyse", "hjælp til SEO" og "årsrapport" gennem de funktioner, jeg oftest ser i CMS'er og importscripts: python-slugify 9.1.3 i Python 3.13, slugify 1.6.6 og @sindresorhus/slugify 1.1.2 i Node 22 samt iconv med ASCII//TRANSLIT og intl-transliteratoren Latin-ASCII i PHP 8.3. Derudover læste jeg koden for WordPress' remove_accents(), som laver permalinks.
| Funktion | søgeordsanalyse | hjælp til SEO | årsrapport |
|---|---|---|---|
| Fem slug-funktioner (Python, Node, PHP) | sogeordsanalyse | hjaelp-til-seo | arsrapport |
| WordPress, standard | sogeordsanalyse | hjaelp-til-seo | arsrapport |
| WordPress, sprog da_DK | soegeordsanalyse | hjaelp-til-seo | aarsrapport |
Alle fem funktioner gør det samme: æ bliver til to bogstaver, mens ø og å bliver til ét. Det er hverken den danske konvention, hvor æ, ø og å skrives ae, oe og aa, eller en konsekvent forenkling. WordPress har den danske tabel, men slår den kun til, når sitets sprog er sat til da_DK. Et site, der skiftede sprog efter de første indlæg, eller som fik indlæg ind via et importscript, kan derfor have begge former side om side.
Det usynlige problem: to slags å
Ø og æ findes kun som ét tegn i Unicode. Det gør å ikke. Det kan lagres som ét tegn, U+00E5 (normalform NFC), eller som et almindeligt a efterfulgt af en kombinerende ring, U+030A (NFD). På skærmen er de ens. I en URL er de ikke:
- NFC:
/%C3%A5rsrapport/ - NFD:
/a%CC%8Arsrapport/
Jeg lagde en fil med NFC-navn på to minimale statiske servere, Pythons http.server og en filserver i Node. Begge svarede 200 på NFC-stien og 404 på NFD-stien. Dansk Wikipedia svarede 200 på begge og satte canonical til den samme side, fordi MediaWiki normaliserer selv. Om dit site gør det, afhænger altså af stakken, og et statisk site gør det typisk ikke.
NFD-tekst opstår sjældent af sig selv, men den kommer ind ad omveje: tekst kopieret fra filnavne på Macs ældre filsystem HFS+, der lagrede navne i NFD, eller data fra et andet system, der ikke normaliserer. WordPress kører teksten gennem normalizer_normalize() før omskrivningen, når PHP's intl-udvidelse er installeret. Et hjemmeskrevet script gør det kun, hvis nogen har husket det.
Fire stier til samme ord. Kilde: egen test 25. oktober 2026 i Python 3.13, Node 22 og PHP 8.3 samt WordPress' remove_accents().
Hvad du skal gøre
Vælg én konvention og skriv den ned
Der er to forsvarlige valg. Behold æ, ø og å procent-kodet, som Googles eksempel viser, eller oversæt til ASCII. Vælger du ASCII, så tag stilling til ae/oe/aa eller bibliotekernes a/o. Jeg bruger ae, oe og aa, fordi det er sådan danskere skriver, når bogstaverne mangler; det står i mit eget domænenavn. Når Google selv kalder ordene i URL'en et meget lille signal, skal valget træffes for læserens og konsistensens skyld, ikke for placeringens.
Konfigurer funktionen, stol ikke på standarden
Ingen af de fem funktioner giver den danske form uden indstilling. python-slugify har et replacements-argument, og med æ, ø og å sat til ae, oe og aa gav det aarsrapport i min test. slugify i Node kan udvides med egne tegn. I WordPress skal sproget stå på dansk, før det første indlæg oprettes.
Normaliser til NFC før alt andet
Beholder du æ, ø og å i stien, skal teksten normaliseres til NFC, før sluggen dannes og kodes. Det er én linje i de fleste sprog, og det fjerner den eneste variant, du ikke kan se med det blotte øje.
Find dubletterne, og ret kun dem
Eksporter alle URL'er fra en crawl eller dit sitemap og søg efter %CC%8A, som er den kombinerende ring, og efter ord, der findes i både oe- og o-form. Peg de afvigende med en 301 til den form, du har valgt. Lad resten være: at omdøbe fungerende URL'er for at få ae i stedet for a koster mere i redirects end det signal, Google selv siger er næsten ubetydeligt.
Bindestregen var aldrig problemet
Googles redigering handler om et spørgsmål, der har været afgjort siden 2007. Det, der koster et dansk site noget, er ikke valget mellem bindestreg og underscore, men at det samme ord kan få fire adresser, fordi en funktion, et sprogvalg eller et kopieret filnavn bestemte formen. Ordene i URL'en vejer næsten intet; at hver side kun har én adresse, vejer mere.