Därför kan AI inte läsa dina datablad

Det korta svaret

Ett datablad blir osynligt för AI på ett av fyra sätt, och alla är banala. Filen blockeras innan den ens hämtas, av en botregel, en inloggning eller en mellansida. Filen är en inskannad bild utan textlager, så en extraherare får ut noll tecken. Dokumentet går bara att nå via ett JavaScript-baserat visningsprogram utan direkt URL. Eller så ligger PDF-filen på en separat dokumentvärd — docs., media., ett DAM, ett CDN — vars egen robots.txt eller WAF säger nej, oavsett hur tillåtande din huvudsajt är.

Inget av detta är exotiskt. Alla fyra är vanliga, och ett enda av dem räcker. Konsekvensen är värd att säga rakt ut:

Databladet är den specifikation som gäller. Produktsidan är en sammanfattning av den. När AI kan läsa sammanfattningen men inte källan besvaras tekniska frågor utifrån sammanfattningen — och svaren blir fel.

Varför datablad väger tyngre än webbsidor här

En produktsida bär kanske åtta till tjugo attribut: kapsel, huvudsaklig märkdata, en livscykelflagga, pris, lagersaldo. Ett datablad bär hundratals: absoluta gränsvärden, elektriska egenskaper över temperatur, tidsdiagram, pinnbeskrivningar, termiska resistanser, rekommenderade fotavtryck, fuktkänslighetsklass, avkodare för beställningsnummer. Nästan varje fråga en ingenjör faktiskt ställer till en assistent — kan jag köra den här på 5,5 V, hur stor är viloströmmen vid 85 grader, är pinnkonfigurationen kompatibel med komponenten jag byter ut — besvaras i databladet och ingen annanstans.

Det väger tyngre nu än tidigare, eftersom frågorna ställs till assistenter i stället för att skrivas in i din sökruta. Forrester fann i januari 2026 att 94 % av företagsköparna nu använder AI under sin inköpsprocess. Och de sidor som bär störst tekniskt djup är de som presterar sämst: Adobes analys av maskinläsbarhet inom detaljhandeln i april 2026 gav produktsidorna 66 %, lägst av alla sidtyper, under startsidor på 75 % och FAQ-sidor på 80 %.

När underliggande data inte går att nå är felet inte tystnad — det är tvärsäkra felaktigheter. OpenAI avvecklade Instant Checkout i ChatGPT i mars 2026 med ungefär 30 handlare i drift, och felaktiga produktdata var en central orsak: OpenAI hade skrapat handelssajter efter produktinformation, och uppgifter om lager, frakt och pris var ofta fel. Det är samma feltyp som ett felaktigt gränsvärde, fast med lägre insatser.

De fem sätten ett datablad blir oläsbart på

Den femte är den mest självförvållade. Kortlivade signerade URL-adresser, spärrar av typen ”registrera dig för att ladda ner” och engångstoken är alla osynliga murar: en crawler har ingen session, inga kakor och inget beteende för att fylla i formulär. Och eftersom AI-crawlers inte kör JavaScript existerar en nedladdningslänk som skrivs in i DOM av ett skript helt enkelt inte sett från deras sida av ledningen.

Hur kontrollerar jag om mina datablad går att läsa?

Tre kommandon avgör saken. Kör dem mot dina egna dokument.

1. 01Kontrollera hämtningen. Returnerar URL-adressen en PDF till en vanlig klient utan webbläsare?

curl -sSIL "https://example.com/datasheets/part-12345.pdf" | grep -iE "^HTTP|content-type|content-length"

Du vill se ett avslutande 200 och content-type: application/pdf. Ett content-type: text/html betyder att du fick en utmaningssida eller en inloggningssida förklädd till nedladdning.

1. 01Ladda ner filen och bekräfta att det verkligen är en PDF.

curl -sSL -o ds.pdf "https://example.com/datasheets/part-12345.pdf" -w "status=%{http_code} type=%{content_type} bytes=%{size_download}"
head -c 5 ds.pdf

De första fem bytena måste vara %PDF-. Om de är <!DOC har du laddat ner en felsida.

1. 01Testa textlagret. Det här är kontrollen ingen kör.

pdftotext -q ds.pdf - | tr -d '[:space:]' | wc -c
pdffonts ds.pdf

Hur vet jag om en PDF har ett textlager?

Två siffror, och skillnaden mellan dem är omisskännlig. Vi körde båda testerna mot ett verkligt, aktuellt tillverkardatablad — Texas Instruments LM358, en PDF på 4,15 MB — och mot en rastrerad kopia av samma dokument, vilket är exakt så ett inskannat äldre datablad ser ut för en maskin.

Det är hela diagnostiken. Noll extraherbara tecken och noll inbäddade teckensnitt betyder att det inte finns någon text i filen — bara en bild av text. Dokumentet renderas perfekt för en människa och bidrar bokstavligen med ingenting till en modell. Ett inskannat datablad från 1990-talet för en komponent som fortfarande tillverkas är, för varje AI-system på internet, en tom sida.

Två förtydliganden är värda att känna till. Ett lågt men inte nollställt teckenantal — säg några hundra tecken i ett fyrtiosidigt dokument — betyder oftast en inskannad brödtext med ett textbaserat sidhuvud, vilket är precis lika oanvändbart. Och i utdata från pdffonts spelar kolumnen uni roll: teckensnitt som bäddats in som delmängd utan ToUnicode-mappning kan extraheras som obegripligt teckenmos trots att tecknen tekniskt sett finns där. Stickprovskontrollera de första 200 tecknen i den extraherade texten i stället för att lita på antalet ensamt.

För att svepa igenom ett helt bibliotek, loopa det:

while read -r url; do
  code=$(curl -sSL -o /tmp/d.pdf -w "%{http_code}" --max-time 30 "$url")
  chars=$(pdftotext -q /tmp/d.pdf - 2>/dev/null | tr -d '[:space:]' | wc -c)
  echo "$code $chars $url"
done < datasheet-urls.txt

Sortera utdata stigande efter teckenantal. Allt högst upp i den listan är ett hål i dina produktdata.

Fällan med separata värdar

Den här fångar stora organisationer nästan undantagslöst, eftersom den är en följd av att göra saker ordentligt. Dokument flyttas till ett DAM, en dokumentationssubdomän eller ett CDN, som var och en är ett eget origin med egen konfiguration — och ofta med en egen ägare.

Enligt RFC 9309 gäller robots.txt för ett enda origin: protokoll, värd och port. https://www.example.com/robots.txt styr ingenting på https://docs.example.com/ och ingenting på https://cdn.example-media.net/. Om din huvudsajt välkomnar AI-crawlers medan din dokumentvärd sattes upp från en standardmall med ett generellt Disallow: /, eller ligger bakom en bothanterare som är inställd på att utmana allt som inte är mänskligt, då är hela ditt tekniska bibliotek mörklagt medan din marknadssajt står vidöppen.

Kontrollera varje origin som serverar ett dokument:

for h in www.example.com docs.example.com cdn.example-media.net; do
  echo "--- $h"
  curl -sS --max-time 15 "https://$h/robots.txt" | head -30
done

Så ser det ut när det är rätt gjort

Ett korrekt publicerat datablad är föga anmärkningsvärt, och det är just poängen. Texas Instruments serverar databladet för LM358 på en stabil och gissningsbar URL under /lit/ds/; deras robots.txt lägger ingen begränsning på den sökvägen; filen returnerar 200 med content-type: application/pdf till en klient utan webbläsare som identifierar sig som GPTBot; och PDF-filen bär ett fullständigt textlager med inbäddade, Unicode-mappade teckensnitt. Ingen inloggning, inget visningsprogram, ingen signerad URL, ingen mellansida. Vilken extraheringspipeline som helst i världen kan läsa den.

Utvecklingen i komponentbranschen går mot att göra detta ännu enklare. Microchip publicerade i november 2025 en kostnadsfri MCP-server utan autentisering för sina produktdata — specifikationer, datablad, lagersaldo, priser och ledtider — och ECIA:s TrustedParts lanserade i juni 2026 en AI-agenttjänst för lagersaldo som exponerar tillgänglighet hos auktoriserade distributörer för Copilot, ChatGPT och Claude. Båda vilar på samma insikt: ett dokument som en maskin måste slåss för är ett dokument som förlorar.

Hur åtgärdar man det?

I ordning efter avkastning på insatsen:

1. 01Öppna upp dokumentsökvägarna. Tillåt AI-crawlers på /datasheets/*, /lit/*, /documents/* och motsvarande, i WAF såväl som i robots.txt. Det är två separata reglage och båda måste vara satta.
2. 02Ta bort nedladdningsspärrar från publika tekniska dokument. Om ett datablad ligger på din publika webbplats är det redan publikt. Ett registreringsformulär stoppar bara de maskiner som skulle ha rekommenderat dig.
3. 03OCR-behandla varje PDF som bara är bild och publicera om den med textlager. Prioritera efter komponentens omsättning, inte efter dokumentets ålder. Modern OCR på en ren skanning i 300 dpi är nära förlustfri på brödtext; kontrollera parametertabellerna för hand.
4. 04Ge varje dokument en stabil, direkt och länkbar URL. Inga blobbar, inga visningsprogram, inga token som går ut, inga ?token=-frågesträngar.
5. 05Publicera en tvilling i HTML eller markdown av varje datablad. Specifikationstabeller som riktiga tabeller. Det här är den enskilt mest verkningsfulla förändringen, eftersom den tar bort allt beroende av heuristik för PDF-layout och ger dig en sida som du dessutom kan övervaka för träffsäkerhet.
6. 06Korslänka dokumentet från produktsidan i serverrenderad HTML, så att en crawler som når sidan kan nå dokumentet utan att köra någonting.
7. 07Exponera de extraherade parametrarna som strukturerad data — JSON-LD på sidan, och helst en frågebar endpoint — så att en agent kan filtrera på dem i stället för att tolka om en PDF varje gång.

I augusti 2026 granskade Partsgraph 984 distributörs- och tillverkardomäner världen över, i Nordamerika, Europa och Asien. Medianpoängen för AI-synlighet var 50 av 100, och 70 % av gruppen fick betyget D eller F. Dokumentlagret var genomgående den svagaste delen av poängen: 38 % kunde inte leverera en enda läsbar katalogsida till en vanlig klient utan webbläsare, och dokumentåtkomsten fallerade oftare än sidåtkomsten.

Det obehagliga är att inget av detta syns i din analysdata. En blockerad crawler skriver ingen buggrapport, en dålig OCR kastar inget undantag, och en modell som inte kan läsa ditt datablad talar inte om för köparen att den inte kunde läsa ditt datablad. Den rekommenderar bara en konkurrent vars PDF gick att öppna.

Du kan testa ditt eget dokumentbibliotek mot de här kontrollerna med den kostnadsfria AI-synlighetsbedömningen från Partsgraph på [/audit](/audit).