Få appen att synas på Google: steg för steg utan kod

Varför en AI-byggd app kan vara osynlig

Många appar som byggs med AI-verktyg är så kallade ensidesappar. Webbläsaren laddar en nästan tom sida och ett program i JavaScript, som sedan ritar upp innehållet och byter vy när du klickar. För en människa ser det ut som flera sidor. För en sökmotor är det inte lika självklart.

Google beskriver att JavaScript-appar hanteras i tre faser: genomsökning, rendering och indexering. En sida som svarar med statuskod 200 ställs i kö för rendering, och kön kan ta några sekunder men enligt Google också längre. När resurserna räcker kör Google sidan i en webbläsare utan skärm och läser det som ritats upp. Samtidigt skriver Google att server- eller för-rendering fortfarande är en bra idé, eftersom alla robotar inte kör JavaScript.

Därför finns fyra fallgropar i en ensidesapp, och alla fyra finns beskrivna i Googles dokumentation om JavaScript och sök:

• Adresser med #. Byter appen vy med adresser som /#/priser kan Google enligt dokumentationen inte tillförlitligt följa dem. Google rekommenderar riktiga adresser via webbläsarens History API, alltså /priser, och vanliga länkar med href.
• Samma titel överallt. Unika, beskrivande titlar och metabeskrivningar hjälper den som söker att välja rätt träff. En app som visar appens namn som titel på varje vy ger Google flera likadana träffar att välja mellan.
• Mjuka 404-fel. En adress som inte finns ska ge ett tydligt nej. En ensidesapp svarar ofta ”allt väl” (status 200) och visar sedan en tom yta eller ett felmeddelande. Search Console kallar det en mjuk 404.
• En kvarglömd noindex. Står det noindex i sidans ursprungliga kod kan Google hoppa över renderingen, och att ta bort taggen med JavaScript efteråt fungerar då kanske inte.

Vad Google säger och vad verktyget gör – håll isär dem

Det Google dokumenterar gäller alla sajter, oavsett vilket verktyg som byggt dem. Det ditt byggverktyg gör är en produktfunktion som kan se olika ut mellan verktyg och ändras utan förvarning. Blanda inte ihop dem när du felsöker.

Lovable som exempel. Enligt Lovables dokumentation använder nya appar skapade från 13 maj 2026 TanStack Start med serverrendering, medan äldre React + Vite-appar får för-rendering på publicerade publika adresser – men bara för verifierade sök- och AI-robotar som Google och Bing. SEO-skannrar från andra företag ser då det vanliga, nästan tomma skalet. Lovable hänvisar själva till Googles URL-inspektion för att se den för-renderade versionen. Det är en bra anledning att göra provet i Googles eget verktyg och inte lita på en extern skanner.

Lovable har också en granskning under More → SEO & AI search, som du startar med Scan project. Den flaggar bland annat dubblerade titlar mellan sidor, canonical-adresser som pekar på startsidan och en sitemap som inte stämmer med sidorna. Att köra granskningen kostar inget enligt Lovable, medan rättningar med Try to fix drar vanliga meddelandekrediter. Enligt Lovable kan bara publikt publicerade appar indexeras. Granskningen är en bra kontroll, men den ersätter inte proven nedan: den säger vad verktyget tror, URL-inspektionen visar vad Google hämtade.

Förbered: en egendom i Search Console

Proven görs i Google Search Console, Googles verktyg för dig som äger en webbplats. Lägg till sajten som egendom och verifiera att du äger den. Två detaljer ur Googles hjälpsidor spelar roll här. Adressen du inspekterar måste höra till den egendom som är öppen, så en app på en egen domän och samma app på verktygets underdomän är två olika saker. Och för att skicka en sitemap i Sitemaps-rapporten krävs ägarbehörighet; saknar du den kan sitemapen anges i robots.txt i stället.

Knapparna heter i den här guiden som i Googles engelska hjälp, till exempel Test live URL. Är ditt gränssnitt på svenska har de översatta namn på samma plats. Har ditt verktyg en inbyggd koppling till Search Console, som Lovable, kan verktyget sköta verifieringen åt dig. Lovable påpekar då att du ska publicera först, eftersom Google hämtar sitemapen från den publicerade sajten.

Beställningen till byggverktyget

Texten nedan beställer de tre saker Google beskriver: riktiga adresser, en titel och beskrivning per sida och ett tydligt besked för sidor som inte finns. Byt det som står i hakparenteser mot dina egna sidor. Den sista delen gör resten kontrollerbart, eftersom den ber verktyget skriva ut listan du sedan provar mot.

Jag vill att appen ska kunna hittas av sökmotorer. Ändra inget
i appens funktioner, bara det här:

1. Adresser: Varje sida som ska kunna hittas får en egen riktig
   adress utan #, till exempel [/priser] och [/om-oss]. Länkar
   mellan sidorna ska vara vanliga länkar med href. Om appen i dag
   använder adresser med #/, byt till riktiga adresser och se till
   att de gamla fortfarande leder rätt.

2. Titel och beskrivning: Varje sida får en egen titel och en egen
   metabeskrivning som beskriver just den sidan. Ingen sida får ha
   samma titel som en annan.
   [/] – titel: [Appens namn – vad den gör]
   [/priser] – titel: [Priser – Appens namn]
   [/om-oss] – titel: [Om oss – Appens namn]

3. Sidor som inte finns: En adress som inte finns, till exempel
   /finns-inte-123, ska antingen skickas vidare till en sida som
   servern svarar 404 på, eller få <meta name="robots"
   content="noindex">. Den får inte se ut som en vanlig sida.
   Ingen riktig sida får ha noindex.

4. Sitemap: Skapa /sitemap.xml med fullständiga adresser
   (https://[min-domän]/...) till varje sida i punkt 2 och inga
   andra. Lägg in raden Sitemap: https://[min-domän]/sitemap.xml
   i robots.txt.

När du är klar: skriv ut en tabell med varje adress, dess titel
och beskrivning, och tala om vilket av de två sätten i punkt 3
du valde. Publicera inte förrän jag godkänt tabellen.

Tabellen i slutet är ditt facit för prov 3 och 4. Står samma titel på två rader är det fel redan där, innan du öppnat Search Console. Publicera sedan och gör proven på den publicerade adressen, inte i förhandsvisningen – Googles livetest kräver att sidan går att nå från internet utan inloggning.

Fyra prov med facit

Gör proven i ordning. Prov 1 säger om Google kan se innehållet alls; utan det är de andra meningslösa. Varje prov tar några minuter, och du behöver bara Search Console och en webbläsare.

Prov 1 – URL-inspektion av en undersida
Gör: Klistra in hela adressen till [/priser] i sökfältet högst
upp i Search Console. Klicka Test live URL, sedan View tested
page. Titta på fliken Screenshot och på HTML.
Facit: Skärmbilden visar samma rubrik och text som du ser i
webbläsaren, och texten finns i HTML-fliken. Page fetch är
lyckad och Indexing allowed? är Yes.
Fel om: skärmbilden är tom eller bara visar en laddningssymbol,
eller texten saknas i HTML.

Prov 2 – Sitemap
Gör: Öppna https://[min-domän]/sitemap.xml i webbläsaren. Gör
sedan ett livetest på samma adress. Klistra in adressen under
Add a new sitemap i Sitemaps-rapporten och klicka Submit.
Facit: Filen visar lika många adresser som tabellen från
beställningen, alla börjar med https://[min-domän]/. Status i
rapporten blir Success, och Discovered pages är samma antal.
Fel om: Couldn't fetch, fel antal eller adresser till en annan
domän eller till förhandsvisningen.

Prov 3 – Titel per sida
Gör: Inspektera tre undersidor med livetest och leta upp
<title> i HTML-fliken för var och en.
Facit: Tre olika titlar, samma som i tabellen.
Fel om: två sidor har samma titel, eller alla visar appens namn.

Prov 4 – En sida som inte finns
Gör: Livetesta https://[min-domän]/finns-inte-123.
Facit: Tabellen från beställningen säger vilket sätt som valdes.
Noindex: livetestet visar Indexing allowed? No, med noindex
som skäl. Omdirigering: webbläsaren hamnar på sidan för
saknade sidor, och ett livetest av just den adressen blir inte
godkänt utan visar att sidan inte hittades (404).
Fel om: sidan ser ut som en vanlig sida som går att indexera –
då är det en mjuk 404.

Läs av i ordning och stanna vid första avvikelsen. Är skärmbilden i prov 1 tom kan det bero på att sidan inte renderas, att viktiga filer är blockerade i robots.txt – Google renderar inte JavaScript från blockerade filer – eller att en noindex ligger kvar. Skicka skärmbilden och HTML-utdraget till verktyget och fråga vilket av de tre det är, i stället för att be det ”fixa SEO”.

Visar prov 2 adresser till fel domän har verktyget byggt sitemapen mot förhandsvisningen eller mot en gammal adress. Det kan hända efter ett domänbyte, och Lovable skriver till exempel att en ny egen domän kräver ny verifiering i Search Console. Ger prov 3 samma titel på alla sidor sätts titeln bara en gång när appen startar; beställ punkt 2 igen och be verktyget visa var titeln byts. Ger prov 4 en vanlig sida gäller punkt 3 i beställningen, och det räcker att välja ett av Googles två sätt.

Begära indexering – och vänta utan att stressa

När prov 1 går igenom kan du klicka Request indexing för de viktigaste sidorna. Google anger att det finns en daglig gräns för hur många sådana begäranden du kan göra, och att en begäran inte garanterar att sidan kommer med i indexet. Har du många sidor är sitemapen rätt väg; Google hänvisar själv dit.

Ingen kan säga hur lång tid det tar. Följ i stället sidorna i Search Console: kör URL-inspektionen på samma undersida igen om en vecka och se om statusen ändrats från ”URL is not on Google”. Standardvyn visar den senast indexerade versionen, inte den du just publicerade, så jämför med ett nytt livetest innan du drar slutsatser.

Spara de fyra proven i din provlista och kör om prov 1 och 3 efter varje ändring av sidornas struktur. En ny sida eller en omskriven meny är exakt den sortens ändring som kan ge alla sidor samma titel igen. Titel och beskrivning syns också när länken delas, vilket nyheten om Lovables publiceringsdialog går igenom.

Vad guiden inte täcker

Guiden handlar om att Google ska kunna se appen, inte om att den ska ranka högt. Lovable skriver själva att placering beror på sådant utanför verktygets kontroll: innehållets kvalitet, sökintention, länkar från andra sajter, konkurrens och prestanda. Det gäller oavsett verktyg. Sidor bakom inloggning ska inte synas på Google alls, och de hör till guiden om säkerhet och personuppgifter. Hur du publicerar och kopplar en egen domän står i guiden om att publicera appen.

Klart när fyra prov ger facit

Arbetet är klart när livetestet i prov 1 visar samma innehåll som du ser, sitemapen i prov 2 har status Success och rätt antal adresser, tre undersidor har tre olika titlar och en påhittad adress ger antingen 404 eller noindex. Du behöver inte förstå hur verktyget byggde det. Du behöver kunna visa att Google får se det du vill att det ska se.