SEO-lektioner fra at rette vores egen side

Vi brugte nogle dage på at læse vores egen side, sådan som en søgemaskine gør, og fandt seks ting, det var værd at rette. Hver side erklærede to FAQ-blokke, Google brugte en dekorativ baggrundsglød som vores miniaturebillede, en række skabelonsider rangerede på søgninger, de ikke besvarede, og en ny del af siden var blokeret af vores egen edge på staging. Intet af det var dramatisk. Alt sammen kostede os stille synlighed.

Siden i ét afsnit

mythex.ai er en single-page app, som vi prerenderer under build: et script går igennem alle ruter, skriver en statisk HTML-fil for hver og indsætter sidens titel, beskrivelse og strukturerede data (JSON-LD-blokken, der fortæller søgemaskiner, hvad en side er — se hvad er strukturerede data). Det meste af det følgende ligger i prerender-trinnet, fordi det er den HTML, en crawler faktisk læser.

1. Alle sider påstod at være FAQ-siden

Symptom. Vores HTML-skabelon indeholdt en site-dækkende FAQPage-blok i de strukturerede data, med URL'en peget på /faq. Prerender tilføjede så hver sides egen FAQPage oven på. Så hver side på sitet leverede to — og vores privatlivspolitik fortalte Google, at det var FAQ-siden.

Hvorfor det betyder noget. Google forventer højst én FAQPage pr. side. En ekstra, der peger et andet sted, er den slags, der får en sides markup nedvurderet, ikke bare ignoreret.

Rettelse. Den globale blok er væk. Hver sides FAQ-markup kommer nu fra ét sted, også /faq selv, som bygger den ud fra den fulde liste af spørgsmål. Sider uden FAQ'er erklærer nu ingen, hvilket er det ærlige svar. Og prerender fejler build'et, hvis en side nogensinde igen har mere end én FAQPage. En regel, der kun lever i nogens hukommelse, bliver brudt; en regel, build'et håndhæver, bliver ikke.

2. Google brugte det forkerte billede for os

Symptom. I søgeresultaterne var Mythex-miniaturen den bløde pulserende glød bag vores forside-hero — et dekorativt baggrundsbillede — i stedet for vores delekort.

Hvorfor det skete. Vi havde aldrig fortalt Google, hvilket billede der repræsenterede en side, så den valgte et, den fandt.

Rettelse. To sider af samme problem:

• Sig, hvilket billede der er sidens. Forsiden har nu en WebPage-node med en primaryImageOfPage, der peger på delekortet, og hver prerenderet side har sit eget billede i de strukturerede data (sidens delebillede eller standardbilledet).
• Skjul dekorationen. Baggrundsbillederne er nu tilladt i robots.txt og serveres med en noindex, noimageindex-header, så de holdes ude af billedsøgning og miniaturer.

3. Søgemaskinerne kendte kun vores logo

Vores Organization-markup havde et navn, et logo og nogle sociale links — branding og intet andet. Søgemaskiner bygger en virksomheds vidensboks ud fra registerlignende fakta, så vi tilføjede dem fra vores erhvervstilladelse: juridisk navn, stiftelsesdato, grundlægger og registreret adresse. Telefonnummeret har vi bevidst udeladt.

4. Skabelonsider besvarede det forkerte spørgsmål

Symptom. Search Console viste tre skabelonsider, der fik visninger og ingen klik. En rangerede på "content strategist portfolio" og varianter af det, en anden på "best italian restaurant website design", og en tredje på en klynge omkring "agile board" — halvdelen af de søgninger indeholdt ordet "free". Positionerne lå fra midten af 20'erne til 50'erne.

Hvorfor. Hver side besvarede et andet spørgsmål end det, der blev stillet. Nogen, der ville se, hvordan god italiensk restaurantdesign ser ud, landede på en side, der solgte dem en builder.

Rettelse. Hver af de tre har nu et afsnit skrevet til søgningen i stedet for til produktet, en titel og beskrivelse med de ord folk faktisk skriver, og FAQ'er, der er værd den markup, de allerede udsendte.

Samme commit rettede et mere stille problem. Blokken "relaterede skabeloner" tog de første fire skabeloner i en kategori, så hver portfolio-skabelon pegede på de samme fire portfolioer, og resten af kategorien havde slet ingen interne links. Vi erstattede den med en ring sorteret efter underkategori: hver skabelonside får nu præcis fire links ind og fire ud. Den prerenderede HTML udskriver nu også disse links — før eksisterede de kun, efter JavaScript var kørt, hvilket en crawler måske aldrig gør.

5. Fortæl Bing om nye sider, så snart de er udrullet

Google ignorerer IndexNow, en protokol til at pinge søgemaskiner, når en URL ændrer sig. Bing, Yandex og Seznam bruger den — og Bings indeks er det, ChatGPT-søgning læser. En AI-app-builder, som AI-assistenter ikke kan finde, er en særlig slags fejl.

Den oplagte løsning, at indsende hele sitemappet ved hver udrulning, er sådan man får en nøgle drosselet, og de fleste udrulninger ændrer ingenting, en søgemaskine bryder sig om. Så et script sammenligner det sitemap, siden serverer lige nu, med det, der lige er bygget, og indsender kun forskellen.

To detaljer fik det til at virke:

• Tag et øjebliksbillede, før du udruller. Udgangspunktet skal fanges, før det nye build går live. Bagefter er det "live" sitemap allerede det nye, og alle forskelle bliver tomme.
• Kun nye sider, for nu. Vores sitemap har ingen lastmod-datoer, så scriptet annoncerer nye sider, men ikke omskrivninger. At stemple hver URL med build-datoen ville markere hele sitet som ændret ved hver udrulning — præcis den spam, vi undgik.

Det kører kun ved produktionsudrulninger og fejler aldrig build'et: når scriptet kører, er siden allerede live, og en søgemaskineping er ikke en rød udrulning værd.

6. Vores egen edge sagde "ikke fundet"

Da vi lancerede /ai-siderne (mere om dem i en landingsside til enhver slags virksomhed), viste staging "Not found" for alle dem, mens den statiske host serverede dem fint.

Tjenesten foran vores marketing-hosts videresender kun en tilladelsesliste af stier; alt andet får en hård 404. /ai var ny og stod ikke på listen. Vi tilføjede /ai og /ai/* med en test, der bekræfter, at de går igennem. En lille fejl, men præcis den slags, der gør en ny sektion usynlig for crawlere, uden at nogen opdager det.

Det vi tog med

• Læs den HTML, en crawler læser. De fleste af disse var usynlige i en browser og åbenlyse i den prerenderede fil.
• Lav SEO-regler til build-tjek. "Én FAQPage pr. side" håndhæves nu, den huskes ikke bare.
• Fortæl søgemaskiner, hvad du mener. Hvis du ikke siger, hvilket billede eller hvilke fakta der repræsenterer dig, vil de gætte.
• Search Console fortæller dig, hvilket spørgsmål folk stillede. Visninger uden klik betyder typisk, at siden besvarede et andet spørgsmål.
• Indsend forskelle, ikke alt. At pinge kun det, der ændrede sig, holder dig på rette side af rate limits.

Hvis du gør det samme for et site, du har bygget, dækker vores guider om SEO for AI-byggede websites og opsætning af Google Search Console det grundlæggende.