Hvornår søgning hører til på sitet — og hvornår en sitemap rækker

Et søgefelt er et løfte: det I skriver, kan findes. Løftet holder, når der er et indeks over de ting, I faktisk vil have fundet, og en side der siger ærligt når de ikke er der. Det rådner, når feltet søger i blogposts fordi I mente kataloget, når det 200'er et tomt layout uden at sige 'ingen', eller når det er et ikon der åbner den samme menu, I allerede har. I tror I har site search. I har et input, der skuffer.

Teams arver ordet søgning fra et andet produkt. I en webshop er det find-varen. I et docs-site er det find-siden. I en portal er det find-ordren. På et marketing-site med tolv sider er det oftest 'nogen vil have et felt, fordi headeren ligner de andres'. Det sidste er dekoration. Det koster crawl, det koster origin hvis pluginet scanner, og det koster tillid første gang nogen slår 'pris' op og får tre gamle indlæg og ingen side, der svarer.

Det er også et SEO- og et produkt-spørgsmål. Interne søgeresultater, I lader indeksere, er tynde sider I donerer til crawlen. En søgning, der ikke noindex'es, er hvordan I får 'site:jer' til at ligne et hul. En søgning, der kun lever bag login, er et andet job — portal, ikke marketing-header. Hvis ingen ejer den tomme tilstand, er feltet krom. Det er ikke findbarhed.

Vi skriver det, fordi 'vi skal have søgning' er blevet et køb, I tager før I har talt om hvad der skal kunne findes. Et ærligt setup er kedeligt: navigation og sitemap, indtil inventaret er for stort; så et indeks I ejer, en tom-side I har skrevet, og en log I læser. Uden den sætning har I Algolia på et site, en menu ville have klaret. I har ikke site search.

Site search er et navngivet indeks over et navngivet inventar: varer, artikler, tickets, dokumenter — og en query der returnerer det inventar, ikke hele sitet fordi I glemte at afgrænse. Den er et produktvalg, fordi den siger hvad I tror folk kommer for at finde. Den er ikke et ikon. De fleste marketing-sites skal have en sitemap og en menu. De skal ikke have et felt.

Det er ikke 'sæt et input i headeren'. Et felt uden indeks er en GET mod en side, der scanner eller rammer databasen på hvert tastetryk. Et WordPress-plugin der LIKE'er wp_posts, er det mønster. Det virker på et site med lidt indhold. Det bliver det dyre kald, rate-limit-indlægget handler om, den dag nogen scraper `?s=`. Et ærligt indeks er bygget: I ved hvad der er i det, I ved hvad der ikke er, og I ved hvad der sker ved nul hits.

Det er heller ikke 'køb Algolia, Typesense eller et shop-søgningstillæg, så er vi færdige'. Et vendor-indeks kan være rigtigt, når inventaret er stort, og I vil have tasteforslag og relevans, I ikke selv vil eje. Det er et andet system: synk, nøgler, et preview der ikke må lække det, I ikke har publiceret. Hvis I ikke har et query-log og en tom-tilstand, har I købt relevans til et felt, I ikke har et produkt for. Start med at tælle hvad folk ville slå op. Køb indekset bagefter, hvis tællingen kræver det.

Og det er ikke en sitemap. Sitemap'et er for crawlen og for jer: her er siderne, vi mener. Navigationen er for mennesket, der vil bladre. Søgning er for mennesket, der vil slå op, fordi bladre ikke rækker. Hvis I kan stå inde for at alle vigtige ting ligger i menuen eller på en filter-side med ærlig facets, rækker sitemap og nav. Feltet kommer, når I ærligt kan sige: 'det her inventar kan I ikke overskue uden at spørge'.

Den første fejl er at søge i det forkerte inventar. I ville have varer. Feltet søger i bloggen, cases og den gamle privacypolitik, fordi pluginet indekserede 'alle indlæg'. Brugeren slår et produktnavn op og får et indlæg om et overstået webinar. Afgræns indekset. Hvis jobbet er kataloget, er marketing-siderne ikke hits. Hvis jobbet er docs, er shoppen ikke hits. Et fælles felt over alt er hvordan I får relevans, I ikke kan forklare.

Den anden fejl er den tomme tilstand, I ikke skrev. Nul hits er 200 med et hvidt hul, eller '0 resultater' uden et næste skridt. Den tomme side skal sige at I forstod queryen, at den ikke ramte, og hvad I kan gøre: se kataloget, skriv til os, prøv et andet ord I faktisk har. En tom side uden ejer er et brudt løfte. Fejlsider-indlægget er 404-chrome. Her er at lade 'ingen hit' være et produkt, ikke en fejl I skammer jer over.

Den tredje fejl er at indeksere søgeresultatet. `/search?q=` som en crawler-venlig side er tyndt indhold, I har bedt Google om at rangere. Noindex på søgning, der er et værktøj. Index på de ting, søgningen peger på. Hvis I er stolte af en søgeside som landingside, har I et andet problem: så er queryen et emne, I skylder en rigtig side — ikke et resultat-layout med tre hits.

Den fjerde fejl er at købe vendor før I har en log. I synker 'hele sitet', I tænder tasteforslag, I får en regning den dag preview-miljøet også synker. I ved stadig ikke om folk slår produktnumre, synonymer eller 'kontakt' op. Log queryen. Læs den i en måned. Så ved I om I skal have synonymer, om I skal have et indeks overhovedet, eller om I skal have en side der hedder det, folk slår op. Et klogt indeks uden en log er et slide.

Marketing-sitet er det job, der oftest ikke skal have søgning. Tolv sider, fem ydelser, en kontakt. Sitemap og nav er findbarheden. Et felt her er et løfte, I ikke har et inventar til: folk slår 'pris' og 'next.js' op og får det, pluginet tilfældigvis indekserede. Byg de sider, I skylder. Lad menuen pege på dem. Next.js-bureau-landingen er det, I linker til, når jobbet er sitet. Feltet kommer ikke, fordi headeren ligner en shop.

Kataloget og webshoppen er det job, der oftest er rigtigt som søgning — og oftest forkert som 'søg i hele sitet'. Find varen. Afgræns indekset til det, der kan købes eller vælges. En filter-side med ærlig facets rækker længe, hvis listen stadig kan ses. Vendor rækker, når tasteforslag og stavning er jobbet, og I har læst loggen. B2B-webshop-indlægget er forskellen på B2B og B2C. Her er at lade find være et produkt i kataloget, ikke et felt der også rammer bloggen.

Docs og hjælpecenter er det job, der oftest ligner søgning og oftest dør som en sidebar, I har glemt. Hvis artiklerne ikke kan overskues, skylder I et indeks over docs — ikke over marketing. Tom-tilstanden skal pege på en kontakt eller en artikel, I faktisk har. RAG-indlægget er når svaret skal genereres. Den her er når svaret allerede er en side, I har skrevet, og mennesket skal finde den. Bland ikke de to: et chatfelt er ikke site search, og site search er ikke en model I ikke har afgrænset.

Portalen er det job, der oftest er rigtigt som søgning og forkert som et offentligt felt. Find ordren, sagen, filen — bag login. Det er ikke headeren på www. Det er et indeks, I ikke må lække, og en query I rate-limiter. Portal-indlægget og form-til-portal-indlægget er adgangen. Her er findbarheden indenfor. Et fælles vendor-indeks over public og private er hvordan I får et preview eller et script til at vise det, I lovede var inde bag cifferkoden.