Fel som SaaS- och IT-bolag gör med AI-synlighet

Endast 1 av 37 studerade SaaS- och IT-bolag använder schema markup effektivt för att öka chansen att synas för AI-sök och i Google. Här är några av de vanligaste misstagen – och hur ni kan göra för att komma före era konkurrenter.

För att förstå hur företag i Sverige idag använder schema markup för att potentiellt öka besök och synlighet av sin hemsida, genomförde vi en studie av Gasellbolag från 2025, dvs landets snabbast växande företag.

I studien kunde vi se ett särskilt resultat för just SaaS- och IT-bolag. Av 37 svenska IT- och kommunikationsbolag, en delmängd av de 281 Gasellbolag vi undersökt, har en SoftwareApplication-markering på sin sajt. Det är typen som beskriver en mjukvaruprodukt: vad den gör, vilken kategori den tillhör, vad den kostar, vilken plattform den körs på.

Service, den grundläggande typen för att beskriva en tjänst, fanns hos två bolag. ProfessionalService och ITService fanns inte alls.

25 av de 37 bolagen hade strukturerad data i någon form. 16 av dessa 25 hade bara den mest grundläggande mallen: som i stora drag säger att sajten är en sajt och att den har en organisation bakom sig. Ingenting om vad bolaget levererar. Det fanns med andra ord en hel del jobb att göra för SaaS- och IT-bolag i Sverige som vill ligga i framkant för synlighet och AI-sök.

Varför just IT-branschen ligger efter

Det här är branschen som bygger AI-produkter, integrationer och sökfunktioner. Flera av bolagen i gruppen säljer tjänster där maskinläsbarhet är en del av leveransen.

Vi tror inte att förklaringen är okunskap. En rimligare läsning är att sajten inte är där affären sker. Ett konsultbolag får kunder via nätverk och upphandlingar. Ett SaaS-bolag driver trafik via annonser och produktledd tillväxt. I båda fallen blir hemsidan en broschyr som ingen mäter, och då prioriteras den bort.

Problemet med det resonemanget är att det inte håller lika bra idag som för fem år sedan. När en köpare exempelvis frågar en AI-assistent vilka svenska leverantörer som kan automatisera fakturaflöden, eller vilka som erbjuder molnmigrering för mindre bolag, är sajten det enda underlaget. Den kan inte kompletteras av ett säljsamtal, för samtalet har inte hänt än.

Vad är schema markup?

Schema markup är därmed väldigt viktigt för att en hemsida ska kunna synas och att er information når intresserade leads. Schema markup är metadata i sidans kod, i formatet JSON-LD, som anger vad innehållet betyder snarare än hur det ser ut. Skillnaden är att en maskin inte behöver tolka innehållet. Det står redan angivet i koden vad varje del betyder.

En sida som säger "vår plattform automatiserar orderhantering för grossister" kräver att mottagaren tolkar meningen. Samma information som SoftwareApplication med applicationCategory: BusinessApplication och en featureList kräver ingen tolkning alls. Den kan läsas, filtreras och jämföras.

För IT-bolag är det värt att notera att markeringen inte påverkar rendering, bundlestorlek eller något annat i frontend. Den ligger i head som ett script-block med typen application/ld+json och exekveras aldrig.

‍

Vilken schema markup ska ett IT-bolag ha?

Gruppen rymmer två ganska olika affärsmodeller, och de behöver olika typer:

Säljer ni en produkt är SoftwareApplication rätt. Då är det fyra fält täcker det viktigaste.

• applicationCategory placerar produkten i en kategori en maskin kan matcha mot en fråga. Värden som BusinessApplication, DeveloperApplication eller FinanceApplication är standardiserade och därför jämförbara.
• featureList räknar upp funktionerna. Den listan finns oftast redan på sajten i punktform, så arbetet är att flytta den till strukturerad form.
• operatingSystem anger plattform, exempelvis Web-based för en molntjänst.
• offers med UnitPriceSpecification beskriver prismodellen. Har ni publicerad prissättning hör den hit. Har ni det inte, utelämna hela fältet hellre än att gissa.

Säljer ni tjänster är Service rätt, och den läggs på respektive tjänstesida snarare än på startsidan. Här är serviceType det viktigaste fältet, alltså den korta beteckningen på vad tjänsten är, formulerad som en kund skulle söka på den. audience med BusinessAudience avgör om ni matchas mot frågor som specificerar bolagsstorlek eller bransch, och areaServed kopplar er till geografi även när tjänsten inte är platsbunden.

Kärnan för en produkt ser ut så här:

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "SoftwareApplication", "name": "Exempel Flow", "applicationCategory": "BusinessApplication", "operatingSystem": "Web-based", "featureList": [ "Automatisk orderregistrering", "Lagersaldo i realtid" ] } </script>

Till det lägger ni description, publisher och eventuellt offers. För ett konsultbolag byter ni @type till Service och lägger serviceType, provider och audience i stället.

‍

Tre vanliga fel i schema markup

• Markering bara på startsidan. Startsidan beskriver bolaget. Tjänste- och produktsidorna beskriver det ni säljer, och det är dem en köpare landar på.
• Interna produktnamn i serviceType. Har ni döpt ert erbjudande till "Molnresan" hör det hemma i name. serviceType ska säga "molnmigrering", alltså det kunden söker på.
• Markup som JavaScript lägger till efter rendering. Det fungerar för Google men inte tillförlitligt för alla AI-crawlers, som ofta läser rå HTML. Serverrendera markeringen om ni kan.

Vanliga frågor om schema markup för IT-bolag

Ska vi använda SoftwareApplication eller Service?
Säljer ni en produkt kunden loggar in i, SoftwareApplication. Säljer ni timmar eller uppdrag, Service. Erbjuder ni både tjänster och produkter, använd båda på respektive sidtyp. De utesluter inte varandra.

Vår sajt är en React-app. Fungerar strukturerad data ändå?
Ja, men var noga med var den läggs. Markup som injiceras av JavaScript efter att sidan laddats syns för Google, som renderar sidor, men missas ofta av AI-crawlers som bara läser rå HTML. I vår studie var JS-rendering en av de vanligaste orsakerna till att markup inte gick att läsa vid en första hämtning. Serverrendera eller lägg markeringen statiskt i dokumentet.

Måste vi publicera priser för att använda offers?
Nej. Utelämna offers helt om ni inte har publik prissättning. En markering med ett påhittat eller inaktuellt pris är sämre än ingen markering alls.

Räcker det med markup på startsidan?
Nej, och det är det vanligaste felet. Startsidan får en Organization-markering, medan produkt- och tjänstesidorna får de typer som beskriver erbjudandet. Det är där sökningarna landar.

Ger schema markup högre placering i Google?
Inte direkt. Google har varit tydliga med att strukturerad data inte är en rankingfaktor i sig. Den påverkar hur ni visas och gör innehållet lättare att tolka korrekt. Effekten kommer via rätt matchning och högre klickfrekvens, inte via en direkt puff uppåt.

Vem bör äga det här internt?
I de flesta bolag vi granskat ligger sajten hos marknad och den tekniska implementationen hos utveckling – och markup-frågan hamnar mitt emellan, där ingen tar ansvar för den. Uppgiften är liten men behöver en tydlig ägare. Enklast är att lägga den där sajtens innehåll redan underhålls.

Behöver vi en llms.txt?
Ja – och för er grupp är den mer värd än för de flesta andra branscherna. Cursor och GitHub Copilot är beroende av filen, och Perplexity och Claude hämtar den. Google använder den inte, så den ger ingen synlighet i vanlig sökning. Sex av 37 IT-bolag hade redan en, den näst högsta andelen i studien – men det betyder också att de flesta ännu inte hängt med. Säljer ni till utvecklare eller har API-dokumentation, prioritera filen högre än vår generella rekommendation. Fortfarande efter markup som beskriver produkten eller tjänsten, men tidigare än för andra branscher.

Börja här: rätt typ på rätt sida

• Har ni en produkt: lägg SoftwareApplication på produktsidan, med applicationCategory och featureList. Endast 1 bolag av 37 hade det, och det gör stor skillnad.
• Säljer ni tjänster: lägg Service på varje tjänstesida, med serviceType. 2 bolag av 37 hade det. Sidorna finns redan och texten är skriven, så arbetet är att strukturera det som står där.

Om undersökningen

Underlaget är 37 IT- och kommunikationsbolag från DI Gasell 2025, en av flera grupper i ett totalurval på 281 bolag. Gruppen fanns som färdig kategori i källdatan, vilket gör den mer tillförlitlig än de branschgrupper vi själva satt ihop.

Sajterna lästes 23 och 28 juli 2026, med en kompletterande genomgång av undersidor 3 augusti. Per bolag granskade vi startsidan och upp till fyra produkt- eller tjänstesidor, så talen anger en lägsta nivå. Tre bolag gick inte att granska på undersidenivå.

Vid den här gruppstorleken säger antal mer än procent, och därför anger vi antal. Metod och statistiska förbehåll redovisas i huvudrapporten.

Vad betyder det här för er egen sajt?

Vill ni komma igång mer schema markup men är osäkra på hur er sida kan förbättras idag? Boka ett möte med vår Performance Marketing Specialist, Oscar Aston Brovall. Vi förklarar vad er sajt har, vad som saknas och varför.