Så skapar du en optimerad, konverterande webbplats för ett lokalt företag med AI

Det har hänt oss alla som bygger webbplatser.

Vi pratar med en potentiell kund som driver ett lokalt företag – ett sådant där kunderna besöker kontoret eller där tjänsterna erbjuds inom ett begränsat geografiskt område – och får höra: ”Bara en enkel liten webbplats, så att folk kan ringa mig eller skriva på WhatsApp.”

Enkel liten. Javisst.

Visst är en e-handelsbutik med tusentals produkter eller en SaaS betydligt mer komplicerad. Men om ett företag vill få kunder via webben (och oftast lägga lite eller inga pengar alls på annonser) kan jag lova att det inte är så enkelt som det låter.

För innan man ens börjar måste man förstå vad företaget erbjuder, ta reda på hur kunder söker efter det, bestämma vilka sidor som behövs, skriva texter, välja bilder, bygga formulär, mäta leads och kontrollera att allt fungerar i mobilen.

Vill man dessutom publicera på flera språk blir besluten ännu fler.

Jag har byggt en hel del sådana webbplatser. Och alla, alla, precis varenda en har överträffat målen och genererat fler leads än vi satte upp från början. Därför vet jag vad jag pratar om.

Hittills har jag haft ett system, inklusive den marknadsföring som krävs, som nästan alltid byggts i WordPress, av uppenbara skäl.

Men nu finns AI. Den förenklar sådant som förr tog massor av tid, var direkt ohanterligt eller helt enkelt inte lönade sig. Nu gör det det. Därför har jag byggt min senaste webbplats, åt transportföretaget Rondabus, utan något CMS, med utvecklingsramverket Astro, som jag inte kände till förrän ChatGPT rekommenderade det när jag beskrev vad jag ville åstadkomma.

Och jag tycker att det var helt rätt val. Det utgår från något jag länge har tänkt: för företagswebbplatser som knappt ändras på flera månader och inte används för att skapa nytt innehåll har statisk HTML tre tydliga fördelar:

1. Snabbare.
2. Säkrare.
3. De kräver inget betalt webbhotell.

Jag går in på detaljer när jag kommer till teknikstacken, ifall den tredje punkten förvånade dig.

En företagswebbplats med allt som behövs för att skapa leads (formulär, mejl, telefon och WhatsApp), där den enda årliga kostnaden är domänen på ungefär 3–10 euro, låter ju fantastiskt.

Och det är det också.

I den här guiden går jag igenom allt steg för steg så att du kan göra likadant. Utöver domänen behöver du bara ett betalt ChatGPT-konto för analys, struktur, skrivande, översättning och granskning, medan Codex arbetar med koden..

Du kan förstås byta ut verktygen. Jag säger det särskilt om du också betalar för Claude, eftersom kombinationen ChatGPT som analytiker och Claude som utvecklare faktiskt är ännu bättre.

Nu när behoven är klara går vi igenom processen steg för steg.

1. Förstå projektet och definiera allt innan du börjar

Börja med att låta kunden förklara:

1. Vad företaget sysslar med.
2. Vilka tjänster det erbjuder.
3. Vilka kunder det riktar sig till.
4. Vilka områden det faktiskt betjänar.
5. Vilka konkurrenterna är.
6. Vad som skiljer företaget från dem.
7. Vilka bevis det kan visa upp.
8. Vad du vill att besökaren ska göra på webbplatsen. Alltså hur den digitala kanalen ska bidra till företagets affärer.

Utifrån detta behöver ni också bestämma (du, kunden eller båda):

• Domänen.
• Kontaktkanaler (telefon, WhatsApp, mejl, formulär …)
• Planerade språk.
• Vem som skriver texterna.
• Fotografier eller bilder.
• Om återkommande innehåll ska publiceras eller inte.

Både du och AI:n behöver allt detta.

Här skiljer vi på tre typer av beslut:

1. Beslut om verksamheten avgör vad som säljs och till vem.
2. Beslut om innehåll och design avgör vad som ska berättas och hur det presenteras.
3. De tekniska besluten avgör hur webbplatsen byggs, publiceras och underhålls.

När allt detta är definierat sparar du besluten i en kort projektbrief och ett kravdokument (PRD) innan du börjar bygga sidorna. Om du ger ChatGPT dokumenten slipper du förklara i varenda konversation vilken domän som gäller, vilka sidor som är godkända eller varifrån telefonnumret och mejladressen kommer.

Teknikvalet spelar ingen roll just nu. Metoden fungerar med WordPress, Astro eller vilket annat system som helst: ha ett tydligt ställe för besluten och en separat källa för företagets uppgifter.

Leverans

En kort brief och ett komplett PRD, med godkännanden, öppna beslut, konverteringsmål, tillgängligt material och ansvariga.

Om ett beslut ändras uppdaterar du själv PRD-dokumentet eller ber Codex göra det åt dig.

2. Skapa mockuper för att bestämma designen

Innan du ber Codex programmera något är det bättre att ta fram två eller tre förslag så att olika angreppssätt kan jämföras. Det behöver inte vara tre färdiga webbplatser. Oftast räcker startsidan eller en tjänstesida för varje förslag för att få en känsla för projektets övergripande utseende.

Men glöm inte att visa även mobilversionen så att det inte blir några överraskningar.

Det är det första vi ska be Codex göra.

Till att börja med utforskar vi tre koncept för en tjänstesida. De kan vara ljusa eller mörka, med olika färger och stilar. Välj vad du tror passar projektet, men be om tre. Två är för få och fyra eller fem börjar bli för många.

När du har alternativen framför dig kontrollerar du att förslaget innehåller de nödvändiga modulerna, att texterna är korrekta (dina egna eller skapade av ChatGPT), att telefon och WhatsApp visas som de ska, att formuläret bara efterfrågar det nödvändiga, att bilderna representerar tjänsten väl och så vidare. Kort sagt: att det uppfyller de viktigaste kraven för CRO..

Efter att du gjort de ändringar som behövs kan du visa förslagen för kunden, få återkoppling och förklara vilket av de tre du själv tycker är bäst. Men se till att det du visar ligger så nära den slutliga designen som möjligt, och inte bara är en ungefärlig skiss. Kunden är inte nödvändigtvis van vid samma abstraktionsnivå när man bygger webbplatser som du.

Leverans

En mockup med godkänd visuell inriktning, versioner för dator och mobil, en lista över gemensamma mönster (sidhuvud, sidfot, ikoner, hero med formulär …) och detaljer som måste respekteras under utvecklingen.

3. Gör en snabb och praktisk marknadsanalys

Du behöver ingen hundrasidig studie för att bestämma strukturen på en lokal webbplats. Du behöver tillräckligt med data för att slippa välja sidor på känsla. Varken din egen eller, ännu värre, kundens. Analysen har två delar: efterfrågan och konkurrens..

Efterfrågeanalys: vad, hur mycket och var användarna söker

Först måste du ta reda på om det kunden erbjuder redan efterfrågas eller om efterfrågan behöver skapas. Och särskilt för lokala företag, hur stor efterfrågan är inom företagets upptagningsområde..

Här finns en fullständig steg-för-steg-artikel om efterfrågeanalys för e-handel, men nedan sammanfattar och anpassar jag den till en lokal företagswebbplats.

Gör en första lista över tjänster med de ord en kund skulle använda. Lägg till varianter, behov och geografiska tillägg. Exempel från mitt fall:

• Hyra buss.
• Hyra buss i Ronda.
• Transport till bröllop.
• Bröllopsbuss Ronda.
• …

Du fattar, eller hur?

Kontrollera sedan vilka sökningar som visar köpavsikt, vilka som gäller information och vilka som rör tjänster som bör dela sida. Exempelvis uttrycker ”hyra buss till bröllop”, ”buss för bröllopsgäster” och ”transport till en fest” liknande behov. Det behövs inte tre sidor bara för att samma sak formuleras på tre sätt. Däremot innebär ”skoltransport” och ”transfer till flygplats” så olika målgrupper, villkor och frågor att de förtjänar egna sidor.

I det här första skedet, när webbplatsens struktur ska skapas, behåller du bara sökningar med kommersiell avsikt. Resten kan användas för bloggen, om det någonsin blir någon.

Använd Google Ads sökordsplanerare för uppskattningarna och avgränsa det geografiska området. Då får vi en uppfattning om vilken trafikvolym vi kan nå. Kom ihåg att ett uppskattat intervall för sökvolymen inte motsvarar antalet organiska besök: bara en del av sökningarna leder till besök. Kombinerar vi det med en uppskattad konverteringsgrad kan vi uppskatta antalet leads per månad.

Konkurrens: vilka du slåss om kunderna med

Även här finns en artikel där jag utförligt förklarar hur man gör en konkurrentanalys inom e-handel. Den har några år på nacken och vissa saker har förändrats, men grunderna är desamma.

För ett lokalt företag ska du söka som en kund skulle göra från relevanta områden och anteckna vilka företag som visas i de organiska och lokala resultaten. Granska följande:

• Tjänster.
• Texter, CTA:er och innehåll.
• Webbplatsens struktur.
• Geografisk täckning.
• Uppmaningar till handling.
• Kontaktmetoder.
• Rykte på nätet (betyg i kataloger som Google Maps eller Trustpilot).
• Lead magnet, om de har någon (oftast inte, eftersom de inte arbetar med e-postmarknadsföring).
• Priser.

Det handlar inte om att kopiera den som ligger först i sökresultaten. Jämförelsen ska hjälpa dig att hitta obesvarade frågor i ditt innehåll, förtydliga dina värdeerbjudanden och upptäcka möjligheter som ditt företag faktiskt kan ta vara på.

Om du inte har tillgång till ekonomiska uppgifter om en konkurrent ska du inte hitta på dem. Fråga ChatGPT, kanske med hjälp av Deep research..

Leverans

Två delar:

En tabell med sökorden, grupperade efter tänkt måladress (oftast startsida och tjänstesidor), geografiskt område där det är relevant, kommersiell prioritet, synliga konkurrenter och slutsatser. Syftet är att fatta beslut om webbplatsen, dess struktur och det innehåll (framför allt rubriker) som ska finnas på varje sida.

Dessutom lägger vi till ett dokument med alla bra idéer från konkurrenterna som går att använda i mitt företag och på webbplatsen.

4. Bestäm webbplatsens struktur och varje URL utifrån efterfrågan

Omvandla nu de preliminära sökordsgrupperna till en faktisk sidkarta. Anteckna för varje föreslagen URL:

• Vilket behov sidan löser, vem den riktar sig till och vilken tjänst den representerar.
• Vilken åtgärd den ska leda till (formulär, klick på telefonnummer eller WhatsApp, tidsbokning …).
• Vilket innehåll som behövs.
• Om jag kan få fram riktiga kundomdömen eller inte.
• Varifrån sidan ska få interna länkar.
• Vilket geografiskt område den ska fokusera på (kanske bara ett, men ibland är det klokt att upprepa en tjänstesida eftersom jag får kunder i två olika länder eller städer).

Bestäm också vilka sidor som ska indexeras. Eller snarare tvärtom: vilka som inte ska indexeras. Exempelvis juridiska sidor och sidor med duplicerat innehåll (om mig och startsidan).

För innehållet är det också viktigt att om företaget har en företagsprofil på Google, så ska uppgifterna där (namn, tjänster, kontakt, öppettider och faktiska verksamhetsområden) vara exakt desamma som på webbplatsen.

Leverans

En sidkarta med:

• URL.
• Sökord som sidan riktar in sig på.
• Särskilda beslut om sidans innehåll.
• Indexering: ja eller nej.

5. Slutför kraven och välj rätt teknik

Innan vi börjar utveckla något behöver alla beslut vi fattat samlas i ett arbetsdokument, en ny och fullständig version av vårt ursprungliga PRD. Dokumentet ska göra det möjligt för någon annan – eller AI:n i det här fallet – att förstå vad som ska byggas och hur vi avgör när det är färdigt.

Oftast är det smidigast att samla all information i ett ChatGPT-projekt och be ChatGPT skriva ett utkast och ställa frågor om uppgifter som saknas. När utkastet är klart behöver du bara granska och redigera det. Det går mycket snabbare.

Nu när vi har alla uppgifter är det dags att välja teknik. För den här sortens webbplatser föreslår jag att du jämför två system: ramverket Astro (här finns dess för- och nackdelar) eller WordPress. I den här artikeln finns en direkt jämförelse mellan dem, så att du ser varför jag just nu väljer Astro för sådana projekt.

Den vinnande kombinationen är den jag själv använder, och det är den jag kommer att följa i guiden::

• Astro för att generera webbplatsen.
• GitHub som kodarkiv.
• Cloudflare för publicering (inte nödvändigt, men enklare om domänen också är köpt där)
• Zoho Mail för företagets e-post och API för formuläret.

Om företagets medarbetare däremot behöver redigera stora mängder innehåll ofta via en adminpanel kan WordPress vara ett bättre förstaval.

När du väljer teknik är det också dags att ordna källmaterialet. Skapa en mapp på datorn med olika undermappar, till exempel:

• Kundens originalmaterial.
• Ditt eget material (efterfrågeanalys, mockuper, PSD, texter …)
• Kod.
• De slutliga resurser webbplatsen behöver (det som laddas upp till Cloudflare: främst HTML, CSS, JS och bilder).
• Hemligheter (lösenord) för produktion.

Allt detta ska inte laddas upp till kodarkivet, bara det som krävs för att återskapa webbplatsen. Inga lösenord eller enorma originaldokument som vi bara sparar som arbetsunderlag.

När mappstrukturen är på plats är det dags att skapa ett projekt i Codex, skilt från projektet i ChatGPT. Det är två olika projekt som delar material, till exempel PRD-dokumentet. Från och med nu kan du se det som att två personer arbetar åt dig:

1. ChatGPT: analytikern som utformar systemet efter dina specifikationer och föreslår lösningar.
2. Codex: utvecklaren som bygger webbplatsen utifrån analytikerns instruktioner.

Så här skapar du projektet i Codex:

1. Skapa ett nytt projekt i appen.
2. Ge det ett namn.
3. Ge projektet tillgång till projektets rotmapp som vi skapade på datorn.
4. Berätta var PRD-dokumentet finns och be Codex granska allt innan arbetet börjar.

Som avslutning på det här steget återstår bara några sista beslut före utvecklingen:

• Hur ändringar ska granskas före publicering (ska Codex göra det eller vill du hellre göra det manuellt?)
• Hur publiceringen ska gå till (ska Codex göra commit till GitHub och därifrån till Cloudflare eller gör du det manuellt?)
• Om webbplatsen ska finnas på flera språk och vilket språk ni börjar med.

När du har bestämt det, ber du Codex lägga in besluten i PRD-dokumentet. Eftersom Codex har skrivrättigheter till mappen gör det de ändringar som behövs i dokumentet. Så här ser arbetsflödet ut från och med nu:

1. Du funderar ut vad du behöver. Du är projektets ägare (owner).
2. Du beskriver det för ChatGPT och diskuterar frågorna och eventuella oklarheter tillsammans.
3. När allt är klart ber du ChatGPT formulera en prompt för Codex.
4. Du klistrar in prompten i Codex, som utför arbetet.
5. Du granskar vad Codex gjort och itererar vid behov.
6. Du går vidare till nästa del av utvecklingen.

Från och med nu är ditt enda jobb att tänka, bestämma och definiera. Din analytiker och din utvecklare bygger webbplatsen tillsammans.

Leveranser

• Ett godkänt PRD inför utvecklingen (det kan behöva ändras under arbetets gång).
• En mapp med kodarkivets struktur.
• En plan för publicering och testning.

6. Skriv texterna

Om du inte har gjort det tidigare är det nu, när webbplatsens struktur och projektet är på plats, dags att börja skapa innehåll till varje URL.

Startsidan ska förklara det övergripande erbjudandet och guida vidare till tjänsterna. Varje tjänstesida behöver beskriva vad som erbjuds, för vem, i vilka situationer, vilka frågor kunden brukar ha och hur man tar kontakt. Här ersätter inte SEO-texter texter som faktiskt hjälper människor: när båda är välgjorda samverkar de.

Använd AI för att skapa utkast med rätt sammanhang. Förklara:

• Tjänsten.
• Ditt unika värdeerbjudande.
• Målgruppen.
• Geografiskt område.
• Ton.
• Verkliga vanliga frågor.
• De kundomdömen som finns. Om företaget har en företagsprofil på Google kanske vi kan hämta bra recensioner därifrån.

Fortsätt bearbeta och redigera det AI:n ger dig tills du har något publicerbart. Fundera sedan på hur innehållet ska fördelas mellan olika moduler, eller be ChatGPT föreslå en struktur. Vissa moduler kanske återkommer på hela webbplatsen (formulär, karta, allmänna fördelar). Oroa dig inte för det än, det tar vi hänsyn till i nästa steg.

Här får du en exempelprompt för ett utkast till tjänstesida:

Skriv tjänstesidan för [servicio] åt [negocio] i [zona]. Unikt värdeerbjudande [propuesta]. Målgrupp: [audiencia]. Huvudsaklig avsikt: [necesidad]. Kundomdömen: [lista]. Vanliga frågor: [lista]. CTA: [acción]. Håll en [tono] ton. Föreslå struktur, copy, SEO-metadata och schema. Markera alla påståenden som kräver belägg och hitta inte på siffror, recensioner, fordon eller täckningsområden.

Skapa innehållet för alla sidor, en i taget.

Leverans

Godkända sidunderlag med innehåll: text, CTA, metadata, belägg och visuellt material. Du kan bygga startsidan och en representativ tjänstesida först för att kontrollera att systemet fungerar innan du bygger resten av tjänste- och kontaktsidorna.

7. Separera återanvändbara komponenter

Med mockuperna och sidunderlagen framför dig markerar du det som faktiskt upprepas: sidhuvud, navigering, sidfot, knappar, formulär, fördelskort, bildblock, avslutande CTA:er och meddelanden …

Tanken är att använda en återanvändbar komponent för varje sådant element, så att du bara behöver ändra telefonnumret i komponenten för att ändringen ska slå igenom på alla URL:er. Sidhuvud och sidfot är förstås återanvändbara, men det kan finnas fler.

Dessutom kanske du vill att alla tjänstesidor ska dela samma design eller struktur. Skilj därför på struktur och data. Exempel:

• En mall för tjänstesidor kan skapa gemensamma block utan att tvinga alla sidor att ha samma text.
• Mer konkret: en fördelskomponent kan behålla layouten samtidigt som rubrik, beskrivning och ikon varierar.

Testa i praktiken innan du använder mönstret överallt: be ChatGPT skriva en prompt som får Codex att bygga startsidan och en tjänstesida, jämför med mockuperna och justera både individuellt innehåll och gemensamma komponenter.

Testa hur det ser ut på dator och mobil. När allt fungerar som det ska kan du tillämpa systemet på resten.

Leverans

En färdiglayoutad startsida och en tjänstesida.

En förteckning över komponenter, vilka data de får och vilka sidor som använder dem.

8. Förbered bilderna för produktion

Så där, efter texterna är det dags att bestämma bilderna.

Helst har kunden gett dig några vettiga bilder att använda. I praktiken är det sällan så. Som tur är kan du, om du inte behärskar Photoshop, ta hjälp av ChatGPT – dess system för att skapa och redigera bilder är riktigt, riktigt bra. Så kör vi.

Krångla inte till det: en till tre bilder per URL borde räcka. Och några kommer förmodligen att återanvändas. Helst bör den första bilden, sidans huvudbild, vara unik.

Spara kundens original, och när du skapar en ny bild behåller du en högkvalitativ master i mappar som inte laddas upp till kodarkivet.

Sedan ber du ChatGPT be Codex anpassa varje bild till rätt plats på webbplatsen och:

• Skapa versioner med lämpliga mått och format, normalt .webp för fotografier och SVG för ikoner.
• Ange responsiva storlekar och undvik att skicka en bild gjord för en stor skärm till mobilen.
• Reservera bildens utrymme så att sidan inte hoppar runt under laddningen. Huvudbilden kan behöva prioriteras vid nedladdning, medan en bild långt ned på sidan kan vänta.
• Skriv en användbar alt-text som beskriver bilden. Om du kan få in ett relevant sökord är det ännu bättre.

Leverans

Slutliga bilder till webbplatsen.

9. Skapa ikonerna

Förmodligen den svåraste punkten att optimera på webbplatser med många ikoner (fler än 20 eller 30).

Problemet är att det är svårt att skapa varianter av alla i samma stil, särskilt på samma bildark. Till slut får man göra dem en och en, och det tar tid.

Och sedan kommer något ännu svårare: att konvertera dem till SVG och få dem att se bra ut. Därför tycker jag att du gott kan använda manuellt beskurna PNG-filer eller bilder från ett bildark skapat i Photoshop. Du får kanske inte 100 % av den möjliga optimeringen, men du sparar enormt mycket tid. Jag talar av erfarenhet.

I Rondabus testade jag exempelvis flera lösningar eftersom de första illustrationerna skilde sig från referenserna: några var för enkla och andra hade olika visuell skala trots att de låg i lika stora rutor. Jag övervägde utsnitt och PNG-filer från de godkända bildarken, men lösningen som till slut hamnade i version 2.0 var de ursprungliga SVG-filerna med större visningsstorlek..

Så här går processen till:

1. Identifiera först var varje ikon visas och vad den betyder.
2. Gruppera ikoner som återkommer.
3. Spara en master för varje illustration eller bildark.
4. Förbered en förhandsvisning i de verkliga sammanhangen: hero, tjänstekort, lista över fördelar, kontakt …
5. Justera den optiska storleken utan att förvränga formerna: två ikoner med samma filbredd kan se helt olika stora ut på grund av marginalerna i själva teckningen.
6. Kontrollera ett urval på en viktig sida (startsida eller tjänster) innan du ändrar alla sidor. Om ett försök inte återskapar mockupens stil går du tillbaka till referensen och förkastar försöket.
7. Tillämpa på resten av sidorna.
8. Filformatet är ett tekniskt genomförandebeslut, men den visuella kvaliteten och konsekvensen är det användaren kommer att bedöma. Och det är viktigast.

Leverans

En godkänd uppsättning ikoner och masterfiler.

10. Bygg webbplatsen etappvis

När startsidan och mönstret för tjänstesidor är godkända bygger du de andra sidorna och granskar dem en i taget. Att de delar mall betyder inte att alla fungerar visuellt: rubrikernas längd, bilderna, antalet fördelar, knapptexterna och målgruppens behov varierar.

Granska både dator, flera mobilbredder och surfplattor. Sätt dig i användarens ställe, jämför varje sida med mockupen och kontrollera sådant som en statisk design inte kan visa:

• Rullgardinsmeny.
• Länkar.
• Klientvalidering av formuläret.
• Bilder och ikoner som laddas.
• Långt innehåll
• Radbrytningar i rubriker.
• …

Det är klokt att spara kontrollpunkter i koden när en etapp med flera ändringar godkänns. Be ChatGPT hjälpa dig med det medan du finslipar detaljerna.

Leverans

Kompletta sidor i gränssnittet (formuläret återstår att validera, om du har ett).

Kontrollpunkt för färdigt gränssnitt, webbplatsens version V1 (ett språk). Om du anser webbplatsen färdig här kan du hoppa till avsnitt 17 för att publicera den på nätet.

11. Bygg ett formulär och andra kontaktvägar

Om du läst mina artiklar om Astro vet du två saker:

1. Att du publicerar HTML-filer.
2. På en server utan serverspråk (PHP, Python).

Det har många fördelar och en nackdel: du kan inte skicka formulär direkt.

Det finns flera lösningar, bland annat:

• Använd betaltjänster från Cloudflare.
• Använd en e-postleverantör (gratis eller betald) och integrera tjänsten via API.

Eftersom jag i sådana här projekt brukar ordna även företagets e-post och använder gratisversionen av Zoho Mail föredrar jag att använda den tjänsten för att skicka mejl från formulären i stället för att lägga till ännu en leverantör.

Det är lite krångligt och kräver flera steg som du själv måste utföra, så be ChatGPT guida dig steg för steg. Framför allt: ladda inte upp hemligheter till GitHub-arkivet. Cloudflare har en plats där de kan lagras.

När allt är klart testar du att fylla i formuläret både rätt och fel för att kontrollera att såväl validering som inskickning fungerar.

Om du inte redan gjort det är det också ett bra tillfälle att testa telefon- och WhatsApp-länkarna från en riktig mobil, om du har lagt till dem – vilket du nästan säkert borde ha.

Leverans

Ett formulär som testats och fungerar hela vägen.

Kontrollpunkt, webbplatsens version V1.5 (färdig med formulär och ett språk).

Med detta, och om vi bortser från själva publiceringen (steg 17), har vi allt det nödvändiga för en lokal företagswebbplats klart. Men följande steg är MYCKET REKOMMENDERADE om vi verkligen vill få kunder.

12. Mät kontakter och konfigurera samtycke

Vi börjar de valfria stegen med något grundläggande: mätning.

Vad vill vi mäta? Det viktigaste:

• Konverteringshändelser.
• Trafik.

Varför?

För att veta varifrån affärerna kommer, särskilt om vi planerar att betala för annonser för att få våra första kunder (det tycker jag verkligen att du borde överväga).

Det första är alltså att definiera en analysplan med affärshändelserna innan något installeras. De är glasklara:

• Kontakt via telefon.
• Via WhatsApp.
• Via mejl.
• Via formulär.
• Bokade tider i kalendern.
• Prenumeration (på nyhetsbrev, om det finns något).
• Klick för att visa adressen i Google Maps.

Och det täcker förmodligen allt du behöver mäta på den här sortens webbplats.

Bestäm vilka som gäller i ditt fall och be ChatGPT ge dig:

• Händelsens namn enligt Googles rekommenderade namngivning, eftersom jag föreslår att använda Google Analytics 4 för mätningen.
• Villkor som utlöser händelsen.
• Ytterligare parametrar (om det behövs).

Systemet fungerar så här:

En webbanvändare utlöser en händelse > Google Tag Manager fångar upp den > GA4 lagrar den så att du kan se uppgifterna.

Registrera dig i både GA4 och GTM med ditt Google-konto och passa samtidigt på att registrera dig i GSC, som vi senare använder för SEO.

Om ditt företag finns inom Europeiska unionen påverkas mätningen också av integritetsval. Be därför ChatGPT implementera avancerat Google Consent Mode v2, med ett alternativ för att öppna inställningarna igen. Då får du den vanliga cookiebannern.

När allt detta är bestämt ber du ChatGPT låta Codex skapa en JSON-fil med containern som ska importeras i GTM. AI:n kommer att be om identifierarna till dina GA4- och GTM-konton och ge dig en liten fil med allt som behövs, redo att importera.

Sedan återstår bara att testa varje händelse i GTM:s förhandsgranskning innan du publicerar containern och börjar samla riktiga data från webbplatsen.

Leverans

En mätplan och fungerande implementering av GTM och GA4, med testat samtycke om det gäller i ditt fall.

13. Slutför teknisk SEO och publicera den första versionen

Om du arbetar med lokal SEO, vilket du borde, är det dags att köra Screaming Frog och kontrollera felen. Be ChatGPT hjälpa dig att rätta dem.

Koppla webbplatsen till företagets Google-företagsprofil. Kontrollera namn, kategorier, adress eller serviceområde, telefonnummer, öppettider, bilder och tjänster utan att hitta på några platser.

Dessutom laddar du i GSC (Google Search Console) upp den webbplatskarta som genererats. Om du inte vet URL:en kan du fråga Codex direkt. Kontrollera efter några dagar om de viktiga sidorna går att genomsöka och indexera.

Leverans

En webbplats utan tekniska SEO-fel, med verifierade URL:er och webbplatskarta samt korrekt kanonisk domän.

Vi kan kalla detta för version V2..

14. Bestäm om det lönar sig att utöka webbplatsen till fler språk

Nu kommer vi till den sista delen av processen: att översätta webbplatsen till andra språk.

Innan du bestämmer dig bör du kontrollera:

• Vilka målgrupper du vill nå.
• Vilket språk du kommer att hjälpa dem på.

Det är inte samma sak att erbjuda massage till en norrman i Málaga utan att tala språket som att erbjuda juridiska tjänster. Du kan också locka japaner som söker taxi i Ronda, men då tydligt tala om att du bara kan hjälpa dem på engelska.

Ett nytt språk kräver dessutom översättning av innehåll, menyer, formulär, metadata, schema och framtida uppdateringar. Det är inte bara en knapp med en flagga.

När du tillsammans med ChatGPT har bestämt vilka språk webbplatsen ska ha, definierar du:

• Källspråket, alltså det språk som redan finns på den offentliga webbplatsen.
• De språk som innehållet ska översättas till.
• Vilka sidor som ska översättas – inte alla (till exempel inte 404-sidan eller de juridiska sidorna).
• URL-policyn. Bestäm om sluggar ska översättas, hur motsvarande sidor kopplas ihop och vad som händer om en översättning saknas.

Arkitekturen bör identifiera varje sida med en stabil kod som är oberoende av språket, så att språkväljaren kan öppna motsvarande sida och webbplatsen kan skapa hreflang -relationer utan att behöva gissa utifrån den synliga rubriken.

Allt detta ska vara klart före översättningen.

Leverans

Översättningsplan.

15. Separera export, översättning och integration

Den process som fungerar bäst för mig är att dela upp arbetet.

1. Codex granskar projektet och skapar ett textpaket med stabila identifierare, källtext, sammanhang, målspråk, markörer, länkar och skyddade termer. Vanligtvis får vi ett paket med JSON eller XML.
2. ChatGPT översätter paketen, granskar värdena och lämnar tillbaka översatta filer.
3. Codex integrerar filerna och validerar sidorna.

Med den uppdelningen kan du byta översättare (till och med använda en människa) utan att kräva att översättaren förstår koden eller att utvecklaren gissar vad varje mening betyder. ChatGPT:s granskning ersätter förstås inte en språklig granskning av en auktoriserad översättare.

Prompt för export:

Granska projektet och skapa en förteckning över översättningsbart innehåll för [idiomas]. Ta med synlig text, navigering, formulär, metadata och sluggar. Ange för varje enhet stabilt ID, källtext, sammanhang, markörer, länkar och skyddade termer. Översätt eller ändra inte sidorna ännu. Rapportera tvetydiga strängar och innehåll som saknar motsvarighet.

Prompt för översättning:

Översätt endast paketets värden till [idioma y variante]. Målgrupp: [audiencia]. Ton: [tono]. Ordlista: [términos]. Bevara ID:n, struktur, ordning, platshållare, egennamn, länkar och kod. Flagga utanför paketet meningar som kräver ett affärsbeslut eller granskning av en modersmålstalare.

Prompt för integration:

Importera de här godkända översättningarna i projektet. Kontrollera ID:n, markörer, skyddade termer, sluggar och motsvarande sökvägar. Publicera inte ett språk om obligatorisk text saknas. Kör översättningsgranskningen, projektkontrollerna och build-kommandot; rapportera avvikelser innan du driftsätter.

Leverans

Flerspråkig webbplats som ännu inte granskats.

16. Granska varje språk som en komplett webbplats

När översättningarna har integrerats öppnar du sidorna: en giltig fil kan ändå ge en meny som flödar över, en alltför lång CTA eller en avisering som täcker formuläret. Granska varje URL på varje språk, både på dator och mobil.

För SEO kontrollerar du (själv eller med ChatGPT):

• <html lang>.
• Titel.
• Beskrivning.
• Lokaliserad URL.
• Egen canonical-adress.
• Hreflang-relationer mellan motsvarande sidor.
• Webbplatskarta över indexerbara URL:er.
• Språkväljaren ska behålla den aktuella sidan när man byter språk, om en motsvarighet finns.
• Kontrollera även länkar i sidfoten.
• Formulär och felmeddelanden.
• Bildernas alt-texter.
• Strukturerade data som innehåller text eller URL:er.

Fortsätt justera tills allt är väl genomarbetat.

Leverans

Komplett flerspråkig webbplats, version V3.

17. Publicera en identifierbar version och kontrollera produktionsmiljön

Oavsett om du stannar efter steg 10 (V1), 11 (V1.5), 13 (V2) eller det föregående (V3) har du nu en webbplats som fungerar i en testmiljö. Den återstår att lägga ut i produktion. Det gör vi här.

Nu ber vi ChatGPT instruera Codex att publicera vår build på Cloudflare.

För att göra det ska Codex:

1. Logga in på vårt GitHub-konto.
2. Be oss välja eller skapa rätt kodarkiv.
3. Logga in på vårt Cloudflare-konto.
4. Fråga vilken domän webbplatsen ska publiceras på.
5. Publicera webbplatsens senaste version.

Sedan behöver vi bara kontrollera att allt ser likadant ut som i testversionen.

Då är webbplatsen färdig.

Leverans

Komplett publicerad webbplats.

18. Gör projektet till en metod du kan upprepa

Det här steget är ännu mer frivilligt, men väldigt användbart om du vill använda processen för ett annat företag.

Du behöver bara be ChatGPT skapa en Skill utifrån hela processen ni följt. Då slipper du komma ihåg alla steg från förra gången eller återvända hit för att läsa guiden igen. ChatGPT kommer att ha allt sparat och Codex kommer att ha det installerat i sitt inre.

På så sätt går nästa webbplats för ett annat lokalt företag mycket snabbare att skapa.

Snyggt, eller hur?