Filtre og facetteret navigation: hvilke filter-URL'er skal indekseres?

Filtrene på en kategoriside er lavet til kunderne, og det er de gode til. Problemet er, at den mest almindelige måde at bygge dem på giver en ny URL for hver eneste kombination, og en crawler kan ikke vide om en URL er værd at hente, før den har hentet den.

Google beskriver selv to konsekvenser i dokumentationen om facetteret navigation fra december 2024. Den første er overcrawling: Googlebot henter et meget stort antal filter-URL'er, før systemet finder ud af, at de er ubrugelige. Den anden er langsommere opdagelse: den tid der bruges på filter-URL'er, bruges ikke på nye produkter og kategorier.

Gary Illyes skrev samtidig på Search Central-bloggen, at facetteret navigation er langt den mest almindelige kilde til overcrawling, som sideejere rapporterer til Google.

Oveni kommer indekseringsproblemet: filtersider har samme title og tekst som kategorien og en delmængde af produkterne. Hundredvis af dem i indekset er hundredvis af næsten-dubletter.

Målet er at bestemme præcis hvilke kombinationer der skal være søgbare sider, og sørge for at resten hverken bliver crawlet eller indekseret.

Tag en almindelig kategori i en sko-shop med seks filtre:

Hvis hvert filter kun kan have én værdi ad gangen, kan det enten være slået fra eller stå på én af sine værdier. Det giver 13 × 16 × 21 × 6 × 9 × 5 = 1.179.360 tilstande, og fratrukket den ufiltrerede side er det 1.179.359 filter-URL'er. For én kategori.

Det er det pæne scenarie. Tillader filtrene flere værdier ad gangen, fx sort og hvid, kan hvert filter stå i alle delmængder af sine værdier, og antallet bliver 2 i 64, omkring 18 trillioner. Rummet er i praksis uendeligt.

Og der er flere multiplikatorer, som de fleste glemmer:

• Rækkefølge. Hvis URL'en skriver filtrene i den rækkefølge kunden klikker, kan seks aktive filtre stå i 6! = 720 forskellige rækkefølger, der viser præcis det samme.
• Sortering. Fire sorteringsmuligheder plus standarden ganger alt med fem.
• Sidetal. Hver kombination kan have side 2, 3 og 4. Det håndterer vi i artiklen om paginering, så vi lader det ligge her.
• Antal kategorier. 40 kategorier med samme filteropsætning giver over 47 millioner URL'er i det pæne scenarie.

Pointen er ikke at alt bliver crawlet. Pointen er, at Googlebot aldrig løber tør for nye filter-URL'er, så længe de ligger som links på siden.

Crawl budget bliver brugt som forklaring på næsten alt, og for de fleste webshops er det ikke den rigtige forklaring.

Googles egen vejledning om crawl budget siger, at den primært er skrevet til tre typer sites:

• Store sites med over 1 million unikke sider, hvor indholdet ændrer sig cirka ugentligt.
• Mellemstore og større sites med over 10.000 unikke sider, hvor indholdet ændrer sig dagligt.
• Sites hvor en stor del af URL'erne står som Fundet, ikke indekseret i øjeblikket (Discovered, currently not indexed) i Search Console.

Google skriver også, at tallene er et groft skøn og ikke præcise tærskler, og at hvis jeres sider bliver crawlet samme dag som de udgives, behøver I ikke læse vejledningen.

For webshops er pointen, at det er antallet af URL'er Google kan finde, der tæller, ikke de 3.000 produkter I selv tænker på. Facetter kan sende en lille shop over grænsen, og det tredje kriterium kan I tjekke med det samme.

Vores beslutningsregel er derfor:

1. Åbn sideindekseringsrapporten i Search Console. Står der mange filter-URL'er under Fundet, ikke indekseret i øjeblikket eller Crawlet, ikke indekseret i øjeblikket, bruger Google tid på dem.
2. Åbn crawlstatistik-rapporten under Indstillinger. Se hvor stor en del af forespørgslerne der går til URL'er med filterparametre, og om der er mange forespørgsler af typen Opdagelse til URL'er I ikke vil have.
3. Tjek hvor hurtigt nye produkter bliver crawlet. Går der uger, er der et problem.

Er alle tre i orden, er filtrene et indekseringsproblem og ikke et crawlproblem, og det ændrer hvilke værktøjer I skal bruge.

Her er det vigtigste skift i tankegangen: der findes ikke en indstilling for "filtre indekseres". Der findes en liste over konkrete sider, I har valgt.

Et godt eksempel er forskellen på /sneakers?farve=sort og en side der hedder "Sorte sneakers". Den første er en tilstand i en brugerflade. Den anden er et svar på en søgning, folk faktisk laver. Og "sorte sneakers str 42" er næsten aldrig en side værd, selv om kombinationen giver mening for kunden, fordi efterspørgslen er spredt ud over 15 størrelser, og fordi lageret i den konkrete størrelse skifter hver uge.

Vi vurderer hver kandidat på fem kriterier. Tallene er vores arbejdsregler og ikke noget Google har udmeldt:

I praksis kan brand, type og materiale ofte være indekserbare, farve sommetider, og størrelse, pris, lagerstatus, rabat og sortering næsten aldrig. Det gør listen kort: typisk et par hundrede sider for en mellemstor shop, ikke tusinder.

Udvælgelsen er en søgeordsanalyse med en anden indgang. Metoden står i artiklen om søgeordsanalyse.

De fleste fejl med filtre kommer af at blande to ting sammen: at forhindre crawling og at forhindre indeksering. Det er to forskellige mekanismer, og flere af værktøjerne gør kun den ene.

Tre ting fra tabellen er værd at slå fast.

robots.txt og noindex udelukker hinanden på samme URL. Står begge dele på samme URL, vinder robots.txt, Google ser aldrig noindex, og URL'er der allerede er indekseret kan blive liggende. Det er den mest almindelige fejl vi finder.

Canonical er ikke en oprydningsmetode for en million URL'er. Det konsoliderer signaler fra næsten-dubletter, men Google skal stadig crawle siden for at se det, og Google kan vælge en anden kanonisk URL end den I angiver. En side filtreret på ét brand med 8 produkter ligner ikke kategorien med 300 produkter, og så risikerer I, at jeres canonical bliver ignoreret.

noindex er ikke et crawl budget-værktøj. Googles vejledning om crawl budget siger direkte, at man ikke skal bruge noindex til at spare crawl, fordi siden stadig bliver hentet. noindex er et indekseringsværktøj, og det er derfor det skal bruges først i oprydningen og ikke til sidst.

Skal filter-URL'erne ikke indekseres, anbefaler Google robots.txt eller fragmenter. Eksemplet fra dokumentationen:

user-agent: Googlebot
disallow: /*?*products=
disallow: /*?*color=
disallow: /*?*size=
allow: /*?products=all$

Når to regler matcher, bruger Google den mest specifikke målt på stiens længde, og ved konflikt den mindst restriktive. Sådan kan allow-reglen åbne for udvalgte URL'er. Det sikreste er dog at give de udvalgte sider en ren URL uden parametre, så robots.txt kan blokere alle parametre uden undtagelser.

Skal nogle filter-URL'er kunne crawles, er der fire regler fra Googles dokumentation, og vi lægger et par oveni.

• Brug & som separator. Google skriver, at komma, semikolon og firkantede parenteser er svære for crawlere at genkende som separatorer, fordi de oftest ikke er det.
• Fast rækkefølge. Ligger filtrene i stien, fx /sneakers/sort/laeder, skal rækkefølgen altid være den samme, og det samme filter må ikke kunne stå to gange.
• 404 for tomme resultater. Mere om det i næste afsnit.
• Ingen omdirigering til en fælles fejlside. En kombination uden resultater skal give 404 på sin egen URL.

Vores egne regler oveni:

1. Sortér parametrene efter en fast nøgle, alfabetisk eller efter en defineret rækkefølge, og sortér værdierne inden for hvert filter.
2. Brug små bogstaver og én stavemåde. farve=Sort og farve=sort er to URL'er.
3. Fjern tomme parametre og standardværdier, fx sortering=standard eller side=1.
4. Send en 301 fra enhver ikke-normaliseret variant til den normaliserede. Så kan der højst findes én URL pr. kombination, uanset hvordan kunden klikker.

Normalisering løser ikke eksplosionen, men fjerner rækkefølge-faktoren, som med seks aktive filtre er 720.

Tomme resultater. Når en kombination ikke giver produkter, vil Google have en 404 på URL'en, også ved dubletfiltre og meningsløse kombinationer. De fleste platforme svarer i stedet med 200 og teksten "Ingen produkter fundet". Det bliver typisk klassificeret som soft 404, og ifølge vejledningen om crawl budget bliver soft 404-sider ved med at blive crawlet. Kan platformen ikke sende 404, er noindex næstbedst.

Det gælder filterkombinationer. En udvalgt landingsside må ikke skifte til 404, fordi alt er udsolgt en uge.

Interne links. Det er links, der skaber eksplosionen, så det er links, der skal styres:

• De udvalgte facetsider skal linkes som almindelige a-elementer med href, fra hovedkategorien og gerne fra relaterede kategorier og guides. Placér dem som et synligt modul, fx "Populære under sneakers", og ikke kun inde i filtermenuen.
• Alle andre filterkontroller skal ikke være crawlbare links. Brug knapper eller formularfelter, og opdatér URL'en med JavaScript bagefter, hvis kunden skal kunne dele resultatet.
• Når kunden vælger et filter, der har en udvalgt landingsside, kan filteret linke til den statiske URL i stedet for parameter-varianten. Så samler alle signaler sig ét sted.

Strukturen er lige så meget et designvalg som et SEO-valg, se kategoristruktur og navigation.

Sitemap. Kun de URL'er I vil have indekseret, med selvrefererende canonical og 200 som svar. Ingen parameter-URL'er med noindex, ingen URL'er der er blokeret i robots.txt. Google bruger lastmod, hvis den er konsekvent og korrekt, og ignorerer priority og changefreq. Læg de udvalgte facetsider i et sitemap for sig. Så kan I følge deres indeksering særskilt i Search Console.

Search Console viser et udsnit. Serverlogs viser hver eneste forespørgsel, og det er dér I ser, om filtrene æder crawlet.

Verificér først at trafikken er Googlebot. User-agent kan forfalskes, så slå IP-adressen op med reverse DNS. Ægte Googlebot ender på googlebot.com eller google.com, og et efterfølgende forward-opslag skal give samme IP. Google udgiver også IP-intervallerne som JSON-filer.

Derefter kan I tælle hvilke parametre Googlebot bruger tid på:

grep "Googlebot" access.log \
  | awk '{print $7}' \
  | grep -oE "[?&][A-Za-z0-9._-]+=" \
  | sort | uniq -c | sort -rn | head -20

Kig efter:

• Andelen af crawl på parameter-URL'er. Hvis halvdelen af Googlebots forespørgsler går til filtre, mens produkterne bliver crawlet sjældent, er det et crawlproblem.
• Hvilke parametre der dominerer. Det er sjældent alle. Ofte er det pris, størrelse og sortering, fordi de har flest værdier.
• Statuskoder på filter-URL'er. Mange 200-svar på tomme kombinationer er soft 404-kandidater.
• Om blokerede mønstre stadig bliver hentet. Gør de, er robots.txt-reglen forkert skrevet. Husk at Google cacher robots.txt i op til 24 timer.

Kør samme udtræk før og efter hver ændring, så I ikke skal vente på Search Console for at se effekten.

Shopify har to filtersystemer, og de giver to slags URL'er.

Tag-filtrering er den gamle metode. URL'en er /collections/sneakers/sort, og flere tags kombineres med plus: /collections/sneakers/sort+laeder. Shopify anbefaler selv at bruge storefront-filtrering i stedet.

Storefront-filtrering bruger parametre: filter.v.option.farve=sort for varianter, filter.p.vendor=nike for brand, filter.p.product_type=sneakers, filter.p.m.custom.materiale=laeder for metafelter og filter.v.price.gte og filter.v.price.lte for pris. Flere værdier i samme filter adskilles med komma, flere filtre med &.

Shopifys standard-robots.txt indeholder blandt andet disse regler, som vi kan se på butikker, der kører med standardfilen:

Disallow: /collections/*sort_by*
Disallow: /collections/*+*
Disallow: /collections/*%2B*
Disallow: /collections/*filter*&*filter*

Læs dem præcist, for hullerne er vigtigere end reglerne:

• Et enkelt tag, /collections/sneakers/sort, er ikke blokeret. Det er kun kombinationer med plus.
• Et enkelt filter, ?filter.v.option.farve=sort, er ikke blokeret. Det er kun to eller flere filterparametre.
• Flere værdier i samme filter, ?filter.v.option.farve=sort,hvid, er heller ikke blokeret, fordi der ikke er noget & i.

Én-filter-varianter kan altså crawles på alle collections. Det kan være fint, men det er sjældent et valg nogen har truffet.

Ændringer laves i robots.txt.liquid, hvor Shopify anbefaler kun at tilføje eller fjerne regler, så standarden stadig opdateres. Shopify advarer selv om, at fejl her kan koste al trafik.

Canonical på filtrerede collections afhænger af temaet, så tjek hvad jeres tema skriver ud på en filter-URL og en tag-URL, før I antager noget. Vil I sætte noindex på filtrerede collections, kan det gøres i theme.liquid ud fra de aktive filtre:

{%- liquid
  assign aktive = 0
  for f in collection.filters
    assign aktive = aktive | plus: f.active_values.size
  endfor
-%}
{%- if aktive > 0 or current_tags -%}
  <meta name="robots" content="noindex">
{%- endif -%}

Prisfiltre bruger min_value og max_value i stedet for active_values, så de skal tjekkes for sig. Og Shopify-butikker har normalt ikke adgang til rå serverlogs, så her er crawlstatistik-rapporten i Search Console jeres bedste kilde.

Skal en filterkombination være en side, er den bedste løsning på Shopify oftest en selvstændig collection, fx en automatisk collection med betingelser på type og farve. Den får sin egen handle, title og tekst. De typiske Shopify-fund har vi samlet på siden om SEO til Shopify.

I PrestaShop styres filtrene af modulet Faceted search (ps_facetedsearch). Alle aktive filtre ligger i én parameter, q, hvor filternavn og værdier er adskilt af bindestreg, og filtrene er adskilt af skråstreg:

/12-sneakers?q=Farve-Sort-Hvid/Størrelse-42

Navnene kommer fra filtrenes etiketter eller URL-navn. Omdøber I et filter, ændrer alle URL'erne sig. Og fordi alt ligger i én parameter, kan robots.txt ikke åbne for brand og lukke for størrelse. Det er alt eller intet.

PrestaShop 9.0 ændrede standarden. Ændringen (pull request 37066 i PrestaShops kode, fusioneret i oktober 2024) gør to ting:

• Kategorisider får noindex, når q eller order er i URL'en.
• Den genererede robots.txt får to nye regler:

Disallow: /*?q=
Disallow: /*&q=

Begge dele giver mening for en ny shop. For en shop der opgraderer med tusindvis af q-URL'er i indekset, er det præcis den kombination, der låser problemet fast: Google kan ikke se noindex på URL'er, den ikke må hente. Har I indekserede q-URL'er, så vent med at regenerere robots.txt, til de er ude af indekset. Tjek også at temaet skriver robots-metatagget ud i head.tpl, ellers sker der intet.

På PrestaShop 8 og ældre er filter-URL'er indekserbare, medmindre temaet eller et modul gør noget ved det.

Skal en filterkombination være en side i PrestaShop, så lav den som en underkategori med egen URL, title og tekst. De andre ting vi typisk finder i PrestaShop-shops, står på siden om SEO til PrestaShop.

Det er her rækkefølgen betyder mest. Den naturlige reaktion er at blokere filtrene i robots.txt med det samme. Det låser URL'erne fast i indekset, fordi Google ikke længere kan se jeres noindex.

1. Kortlæg. Eksportér sideindekseringsrapporten, crawl sitet og træk mindst fire ugers serverlogs. Grupper URL'erne efter parametermønster.
2. Find dem der har værdi. Træk Search Console-data på sideniveau for de sidste 12 måneder. Filter-URL'er med klik, visninger eller eksterne links er kandidater til jeres udvalgte liste.
3. Byg de udvalgte sider. Lav dem som statiske sider med ren URL, egen title, H1 og tekst, selvrefererende canonical og plads i sitemappet. Send en 301 fra de gamle filter-URL'er med trafik til den nye side.
4. Sæt noindex på resten. Brug meta-tagget eller X-Robots-Tag-headeren, og lad URL'erne være crawlbare. Tomme kombinationer skal have 404.
5. Hold links og robots.txt urørt i mellemtiden. Google skal kunne hente URL'erne for at se noindex. Fjerner I linkene nu, bliver de crawlet sjældnere, og oprydningen tager længere tid.
6. Følg udviklingen. I sideindekseringsrapporten skal filter-URL'erne flytte over i Udelukket af tagget noindex (Excluded by noindex tag). Det tager uger og for store shops måneder, fordi Google først skal crawle hver URL igen. Fjernelsesværktøjet i Search Console kan skjule URL'er i cirka seks måneder, men det fjerner dem ikke og er ikke en løsning alene.
7. Fjern crawlbarheden. Når langt de fleste er ude, så gør de ikke-udvalgte filterkontroller til knapper eller fragmenter, så de ikke længere er links.
8. Bloker i robots.txt. Først nu. Bloker de parametermønstre der ikke skal crawles, og tjek at de udvalgte sider ikke rammes. Test reglerne mod rigtige URL'er, før de går live.
9. Mål igen. Kør logudtrækket fra før og sammenlign andelen af crawl på parameter-URL'er og hvor tit produkter og kategorier bliver crawlet.

To undtagelser: Er serveren ved at gå ned af crawl, så bloker de værste mønstre med det samme, for driften går forud. Og URL'er der allerede er blokeret og stadig står i indekset, skal have blokeringen fjernet midlertidigt, så Google kan se noindex.

Search Consoles værktøj til URL-parametre blev lukket i 2022. Google skrev, at kun omkring 1 procent af de opsatte konfigurationer var nyttige for crawling, og henviser i stedet til robots.txt. Oprydningen skal altså ske på sitet.

Til en gennemgang af en shop med filtre:

• Står der filter-URL'er i sideindekseringsrapporten under Fundet eller Crawlet, ikke indekseret i øjeblikket?
• Hvor stor en del af Googlebots forespørgsler går til parameter-URL'er i logs eller crawlstatistik?
• Findes der en skriftlig liste over de filterkombinationer der skal kunne indekseres?
• Har de udvalgte sider ren URL, egen title og tekst, og bliver de linket fra hovedkategorien?
• Er alle andre filterkontroller knapper eller fragmenter frem for links?
• Er parametre og værdier normaliseret, med 301 fra varianter?
• Giver tomme kombinationer 404 eller i det mindste noindex?
• Står robots.txt-blokering og noindex nogensinde på samme URL?
• Indeholder sitemappet kun indekserbare URL'er med 200 som svar?
• På Shopify: er hullerne i standard-robots.txt et valg eller et tilfælde?
• På PrestaShop 9: er robots.txt regenereret før de gamle q-URL'er var ude af indekset?

Vi tager filtrene med i vores tekniske SEO-audit, og arbejdet med de udvalgte sider er en fast del af SEO til webshops.

• Google Search Central: Managing crawling of faceted navigation URLs
• Google Search Central Blog: Crawling December, Faceted navigation (17. december 2024)
• Google Search Central: Optimize your crawl budget
• Google Search Central: How Google interprets the robots.txt specification
• Google Search Central: Introduction to robots.txt
• Google Search Central: Block Search indexing with noindex
• Google Search Central: How to specify a canonical URL
• Google Search Central: Link best practices
• Google Search Central: Build and submit a sitemap
• Google Search Central: Verifying Googlebot and other Google crawlers
• Google Search Central Blog: Spring cleaning, the URL Parameters tool (28. marts 2022)
• Google Search Central Blog: Evolving nofollow (10. september 2019)
• Search Console Help: Crawl Stats report
• Search Console Help: Removals tool
• Shopify Help Center: Editing robots.txt.liquid
• Shopify.dev: Storefront filtering
• Shopify.dev: Tag filtering
• Shopify.dev: Liquid filter object
• PrestaShop på GitHub: Do not index filtered pages (PR 37066)
• PrestaShop ps_facetedsearch: URLSerializer

Kilderne er tjekket 1. oktober 2026. Google flytter jævnligt dokumentation om crawling til nye adresser, så følg linket, hvis en side har skiftet sted.