Slik lager du med KI et optimalisert nettsted som skaffer kunder til en lokal bedrift

Vi som bygger nettsteder, har alle opplevd det.

Vi snakker med en potensiell kunde som driver en lokal bedrift – en av dem der kundene kommer til kontoret, eller som tilbyr tjenester innenfor et begrenset geografisk område – og får høre: «Bare en enkel liten nettside, så folk kan ringe meg eller sende en WhatsApp-melding.»

Enkel, ja. Særlig.

Et netthandelsnettsted med tusenvis av produkter eller en SaaS-løsning er selvsagt mye mer komplisert. Men hvis en bedrift vil skaffe kunder via nettet (og helst bruke lite eller ingenting på annonser), kan jeg love deg at det slett ikke er så enkelt.

Før du i det hele tatt kan begynne, må du forstå hva bedriften tilbyr, finne ut hvordan kundene søker etter det, bestemme hvilke sider som trengs, skrive tekst, velge bilder, lage skjemaer, måle leads og kontrollere at alt fungerer på mobilen.

Skal nettstedet også publiseres på flere språk, blir det enda flere beslutninger å ta.

Jeg har laget en god del slike nettsteder. Og alle, alle sammen, absolutt hvert eneste ett, har overgått målene og skaffet flere leads enn det som opprinnelig var avtalt. Derfor vet jeg hva jeg snakker om.

Hittil har jeg hatt et system som omfattet den nødvendige markedsføringen, og som nesten alltid ble implementert i WordPress, av åpenbare grunner.

Men nå har KI kommet på banen. Den gjør ting enklere som tidligere tok lang tid, var direkte uhåndterlige eller ikke lønte seg. Nå gjør de det. Derfor bygde jeg mitt siste nettsted, for transportselskapet Rondabus, uten CMS, ved hjelp av utviklingsrammeverket Astro, som jeg ikke kjente fra før, men som ChatGPT anbefalte da jeg forklarte hva jeg ønsket å oppnå.

Og jeg tror det var helt riktig valg, for det bygger på noe jeg alltid har ment: For bedriftsnettsteder som knapt endres på flere måneder og ikke brukes til å publisere nytt innhold, har statisk HTML tre klare fordeler:

1. Raskere.
2. Sikrere.
3. Krever ikke betalt webhotell.

Jeg kommer nærmere inn på dette når jeg snakker om teknologistakken, i tilfelle det tredje punktet overrasket deg.

Et bedriftsnettsted med alt som trengs for å skaffe leads (skjema, e-post, telefon og WhatsApp), der du bare betaler rundt 3–10 euro i året for domenet, høres jo nesten for godt ut til å være sant.

Men det er sant.

I denne guiden viser jeg deg trinn for trinn hvordan du kan gjøre det samme. Det eneste du trenger i tillegg til domenet, er et betalt ChatGPT-abonnement til analyse, struktur, skriving, oversettelse og gjennomgang, mens Codex arbeider med koden..

Du kan selvfølgelig bruke andre verktøy. Jeg nevner det særlig hvis du også betaler for Claude, for kombinasjonen av ChatGPT som analytiker og Claude som utvikler er faktisk enda bedre.

Nå som behovene er avklart, går vi gjennom prosessen trinn for trinn.

1. Forstå prosjektet og avklar alt før du begynner

Først må kunden forklare deg:

1. Hva virksomheten går ut på.
2. Hvilke tjenester den tilbyr.
3. Hvem den retter seg mot.
4. Hvilke geografiske områder den faktisk betjener.
5. Hvem konkurrentene er.
6. Hva som skiller bedriften fra konkurrentene.
7. Hvilken dokumentasjon den kan vise fram.
8. Hva du vil at folk skal gjøre når de besøker nettstedet. Altså hvordan den digitale kanalen skal skape forretninger for bedriften.

I tillegg til dette må dere definere (du, kunden eller begge):

• Domenet.
• Kontaktkanaler (telefon, WhatsApp, e-post, skjema …)
• Planlagte språk.
• Hvem som skal skrive tekstene.
• Fotografier eller bilder.
• Om det skal publiseres nytt innhold jevnlig eller ikke.

Både du og KI-en kommer til å trenge alt dette.

Her skiller vi mellom tre typer beslutninger:

1. Beslutninger om virksomheten avgjør hva som selges, og til hvem.
2. Beslutninger om innhold og design avgjør hva som skal formidles, og hvordan det presenteres.
3. De tekniske beslutningene avgjør hvordan nettstedet bygges, publiseres og vedlikeholdes.

Når du har avklart alt dette, bør du samle beslutningene i en prosjektbrief og et kravdokument (PRD) før du begynner å bygge sidene. Ved å gi ChatGPT dokumentene slipper vi å forklare i hver eneste samtale hvilket domene som er riktig, hvilke sider som er godkjent, eller hvor telefonnummeret og e-postadressen kommer fra.

Teknologien spiller ingen rolle på dette stadiet. Metoden fungerer med WordPress, Astro eller et hvilket som helst annet system: Ha ett tydelig sted for beslutningene og en egen kilde til bedriftens opplysninger.

Leveranse

En kort brief og et fullstendig PRD, med godkjenninger, uavklarte beslutninger, konverteringsmål, tilgjengelig materiale og ansvarlige.

Når en beslutning endres, oppdaterer du PRD-et selv eller ber Codex gjøre det.

2. Lag mockuper for å bestemme designet

Før du ber Codex programmere noe som helst, er det bedre å lage to eller tre forslag som gjør det mulig å sammenligne ulike retninger. Det trenger ikke være tre ferdige nettsteder. Vanligvis holder det med forsiden eller en tjenesteside fra hvert forslag for å få et inntrykk av prosjektets generelle uttrykk.

Men du bør selvfølgelig også vise mobilversjonen , så ingen får seg en overraskelse.

Det er det første vi skal be Codex om.

Som utgangspunkt utforsker vi tre konsepter for en tjenesteside. De kan være lyse eller mørke, eller bruke ulike farger og stiler. Velg det du tror passer prosjektet, men be om tre. To er litt lite, mens fire eller fem fort blir for mange.

Når du har alternativene foran deg, ser du etter om forslaget har de nødvendige modulene, om tekstene er riktige (enten dine egne eller generert av ChatGPT), om telefonnummer og WhatsApp vises som de skal, om skjemaet bare ber om nødvendig informasjon, om bildene representerer tjenesten godt, osv. Kort sagt: om det oppfyller de viktigste kravene til CRO..

Når du har gjort justeringene som trengs, kan du vise forslagene til kunden, få tilbakemeldinger og forklare hvilket av de tre du mener fungerer best. Men sørg for at det du viser, ligger så tett som mulig på det endelige designet, og ikke bare er en omtrentlig skisse. Kunden er ikke nødvendigvis vant til samme abstraksjonsnivå som deg når det gjelder å utvikle nettsteder.

Leveranse

En mockup med godkjent visuell retning, skrivebords- og mobilversjon, oversikt over felles elementer (header, footer, ikoner, hero med skjema …) og en liste over detaljer som må ivaretas under utviklingen.

3. Gjør en enkel, målrettet markedsanalyse

Du trenger ikke en rapport på hundre sider for å bestemme den første strukturen til et lokalt nettsted. Du trenger bare nok informasjon til at sidene ikke velges på magefølelsen. Verken din egen eller, enda verre, kundens. Analysen har to deler: etterspørsel og konkurranse..

Etterspørselsanalyse: hva, hvor mye og hvor søker folk?

Det første du må finne ut, er om det finnes etterspørsel etter det kunden tilbyr, eller om den må skapes. Og særlig når det gjelder lokale virksomheter, hvor stor etterspørselen er i området de betjener..

Her finner du en fullstendig trinnvis artikkel om etterspørselsanalyse for netthandel, men nedenfor oppsummerer jeg den og tilpasser den til et nettsted for en lokal bedrift.

Begynn med en liste over tjenester, formulert med ordene en kunde ville brukt. Legg til varianter, behov og geografiske søkeord. Her er et eksempel fra mitt eget prosjekt:

• Bussutleie.
• Bussutleie Ronda.
• Transport til bryllup.
• Bryllupsbuss Ronda.
• …

Du skjønner poenget, ikke sant?

Deretter undersøker du hvilke søk som viser at folk ønsker å bestille, hvilke som er informasjonssøk, og hvilke som gjelder tjenester som bør dele side. For eksempel dekker «bussutleie til bryllup», «turistbuss for bryllupsgjester» og «transport til et selskap» omtrent samme behov. Du trenger ikke tre forskjellige sider bare fordi folk bruker tre ulike formuleringer. Derimot gjelder «skoleskyss» og «flyplasstransport» så forskjellige målgrupper, krav og spørsmål at de fortjener hver sin side.

I denne første fasen, når du skal bestemme nettstedets struktur, bør du bare beholde søk med kommersiell intensjon. Resten kan eventuelt brukes i bloggen, hvis du en dag lager en.

Bruk Google Ads Keyword Planner til å anslå søkevolumet, avgrenset til det aktuelle geografiske området. Da får vi en idé om hvor mye trafikk vi kan oppnå. Husk at søkevolumet ikke er det samme som antall organiske besøk: Bare en del av søkene fører til besøk. Med dette og en anslått konverteringsrate kan vi beregne hvor mange leads vi kan skaffe hver måned.

Konkurrentanalyse: hvem konkurrerer du egentlig mot?

Her har du igjen en artikkel der jeg forklarer i detalj hvordan du gjør en konkurrentanalyse innen netthandel. Den er noen år gammel, og enkelte ting har endret seg, men grunnprinsippene er de samme.

Tilpasset en lokal bedrift bør du søke slik en kunde i de aktuelle områdene ville gjort, og notere hvilke bedrifter som dukker opp i organiske og lokale søkeresultater. Se på:

• Tjenestene deres.
• Tekstene, CTA-ene og innholdet.
• Nettstedets struktur.
• Hvilke geografiske områder de dekker.
• Oppfordringene til handling.
• Kontaktmetodene.
• Omdømmet på nettet (vurderinger på tjenester som Google Maps eller Trustpilot).
• Eventuelle lead magnets (som regel har de ingen, siden de ikke driver med e-postmarkedsføring).
• Prisene.

Målet er ikke å kopiere den som ligger øverst på listen. Sammenligningen skal hjelpe deg med å oppdage ubesvarte spørsmål i eget innhold, tydeliggjøre verdiforslagene dine og finne muligheter bedriften faktisk kan utnytte.

Hvis du ikke har tilgang til økonomiske opplysninger om en konkurrent, må du ikke finne på tall. Spør ChatGPT, gjerne med Deep research..

Leveranse

To deler:

En tabell med søkeordene, gruppert etter foreløpig mål-URL (vanligvis forsiden og tjenestesider), geografisk område der det er relevant, kommersiell prioritet, synlige konkurrenter og konklusjoner. Formålet er å ta beslutninger om nettstedet, strukturen og innholdet (særlig overskriftene) på hver side.

I tillegg lager vi et dokument med alle de gode ideene fra konkurrentene som kan brukes i min egen bedrift og på nettstedet.

4. Bestem nettstedets og hver enkelt URLs struktur ut fra etterspørselen

Gjør nå de foreløpige søkeordgruppene om til et konkret sidekart. Noter for hver foreslått URL:

• Hvilket behov den dekker, hvem den retter seg mot, og hvilken tjeneste den representerer.
• Hvilken handling den skal utløse (skjema, klikk på telefonnummer eller WhatsApp, timebestilling …).
• Hvilket innhold den trenger.
• Om jeg kan skaffe ekte kundeuttalelser eller ikke.
• Hvor den skal få interne lenker fra.
• Hvilket geografisk område den skal rette seg mot (kanskje bare ett, men det kan også lønne seg å lage flere versjoner av tjenestesiden hvis jeg skaffer kunder i to ulike land eller byer).

Bestem også hvilke sider som skal indekseres. Eller rettere sagt: hvilke som ikke skal indekseres. For eksempel juridiske sider og sider med duplisert innhold (om meg og forsiden).

Når det gjelder innholdet, er det også viktig at opplysningene i bedriftens Google Business Profile – hvis den har en – om navn, tjenester, kontakt, åpningstider og faktiske dekningsområder er nøyaktig de samme som på nettstedet.

Leveranse

Et kart med:

• URL.
• Søkeordene den retter seg mot.
• Spesifikke avgjørelser om innholdet på siden.
• Om siden skal indekseres eller ikke.

5. Fullfør kravene og velg riktig teknologi

Før vi utvikler noe, må vi samle alle beslutningene vi har tatt i et arbeidsdokument, en ny og fullstendig versjon av det opprinnelige PRD-et. Dokumentet må gjøre det mulig for en annen person – eller KI-en i dette tilfellet – å forstå hva som skal bygges, og hvordan vi vet at jobben er ferdig.

Vanligvis er det enklest å samle alt dette i et ChatGPT-prosjekt og be verktøyet skrive et utkast, samtidig som det stiller spørsmål om opplysninger som mangler. Når utkastet er ferdig, trenger du bare å gjennomgå og redigere det. Det går mye raskere.

Når vi har all denne informasjonen, er det på tide å velge teknologi. For denne typen nettsteder foreslår jeg at du vurderer to systemer: rammeverket Astro (her er fordelene og ulempene) eller WordPress. I denne artikkelen finner du en direkte sammenligning av de to, slik at du kan se hvorfor jeg per i dag foretrekker Astro til denne typen prosjekter.

Kombinasjonen jeg selv bruker, er den som fungerer best for meg, og det er den vi skal bruke videre i denne veiledningen::

• Astro til å bygge nettstedet.
• GitHub som kodelager.
• Cloudflare til publisering (ikke strengt nødvendig, men enklere hvis du også har kjøpt domenet der).
• Zoho Mail til bedriftens e-post og API for skjemaet.

Når det er sagt, kan WordPress være et bedre utgangspunkt hvis de ansatte ofte må oppdatere mye innhold gjennom et administrasjonspanel.

I tillegg til teknologien må du nå organisere kildematerialet. Opprett en mappe på PC-en din med ulike undermapper, for eksempel:

• Originalmateriale fra kunden.
• Ditt eget materiale (etterspørselsanalyse, mockuper, PSD-filer, tekster …).
• Kode.
• Ferdige ressurser nettstedet trenger (det som skal lastes opp til Cloudflare: først og fremst HTML, CSS, JS og bilder).
• Hemmeligheter (passord) til produksjonsmiljøet.

Ikke alt skal legges i kodelageret, bare det som trengs for å bygge nettstedet på nytt. Passord og store originaldokumenter som vi bare bruker som arbeidsgrunnlag, skal ikke dit.

Når mappestrukturen er på plass, er det tid for å opprette et prosjekt i Codex. Det er ikke det samme prosjektet som vi opprettet i ChatGPT. Dette er to forskjellige prosjekter som deler materiale, blant annet PRD-et. Fra nå av bør du se for deg at to personer jobber for deg:

1. ChatGPT: analytikeren, som designer systemet ut fra spesifikasjonene dine og foreslår løsninger.
2. Codex: utvikleren, som bygger nettstedet etter instruksjonene analytikeren lager.

Slik oppretter du prosjektet i Codex:

1. Opprett et nytt prosjekt i appen.
2. Gi det et navn.
3. Gi tilgang til rotmappen til prosjektet som vi opprettet på PC-en.
4. Forklar hvor PRD-et ligger, og be Codex vurdere alt før arbeidet begynner.

For å avslutte dette trinnet gjenstår bare noen siste avklaringer før utviklingen:

• Hvordan endringene skal gjennomgås før publisering (vil du at Codex skal gjøre det, eller foretrekker du å kontrollere dem manuelt?).
• Hvordan publiseringen skal foregå (skal Codex gjøre commit til GitHub og derfra til Cloudflare, eller vil du gjøre det manuelt?).
• Om nettstedet skal finnes på flere språk, og hvilket språk vi begynner med.

Når du har avklart dette, ber du Codex legge beslutningene inn i PRD-et. Fordi Codex har skrivetilgang til mappen, kan verktøyet oppdatere dokumentet. Fra nå av følger vi denne arbeidsflyten:

1. Du finner ut hva du trenger. Du eier prosjektet (owner).
2. Du forklarer det til ChatGPT, og sammen vurderer dere hvert punkt og eventuelle spørsmål.
3. Når alt er avklart, ber du ChatGPT skrive prompten til Codex.
4. Du limer den inn i Codex, som utfører oppgaven.
5. Du vurderer resultatet fra Codex og justerer om nødvendig.
6. Så går du videre til neste utviklingsoppgave.

Fra nå av består jobben din utelukkende i å tenke, ta beslutninger og definere kravene. Analytikeren og utvikleren din tar seg av selve nettstedet.

Leveranser

• Godkjent PRD før utviklingen (det kan fortsatt bli endret underveis).
• Mappe med kodelagerets struktur.
• Plan for publisering og testing.

6. Skriv tekstene

Hvis du ikke allerede har gjort det, er det nå – når nettstedets struktur og prosjektet er på plass – på tide å lage innholdet til hver URL.

Forsiden skal forklare det overordnede tilbudet og lede folk videre til tjenestene. Hver tjenesteside må beskrive hva som tilbys, hvem det er for, i hvilke situasjoner tjenesten er aktuell, hvilke spørsmål kunden vanligvis har, og hvordan man tar kontakt. SEO-tekster er ikke en erstatning for tekster som er nyttige for mennesker. Når begge deler er godt gjennomtenkt, spiller de på lag.

Bruk KI til å utarbeide utkast med nok kontekst. Forklar:

• Tjenesten.
• Det unike verdiforslaget ditt.
• Målgruppen.
• Det geografiske området.
• Tonen.
• Reelle vanlige spørsmål.
• Kundeuttalelser du har tilgang til. Hvis bedriften har en Google-bedriftsprofil, kan vi kanskje hente gode anmeldelser derfra.

Juster og rediger svarene til du har noe du kan publisere. Når teksten er klar, tenker du på hvordan den kan fordeles på ulike moduler, eller ber ChatGPT komme med forslag. Kanskje oppdager du moduler som skal gjentas på hele nettstedet (et skjema, et kart, generelle fordeler). Ikke tenk på det ennå; det tar vi hensyn til i neste trinn.

Her får du en eksempelprompt for et utkast til en tjenesteside:

Skriv tjenestesiden for [servicio] til [negocio] i [zona]. Unikt verdiforslag: [propuesta]. Målgruppe: [audiencia]. Hovedintensjon: [necesidad]. Kundeuttalelser: [lista]. Vanlige spørsmål: [lista]. CTA: [acción]. Bruk tonen [tono]. Foreslå struktur, tekst, SEO-metadata og schema. Marker påstander som krever dokumentasjon, og ikke finn på tall, anmeldelser, kjøretøy eller dekningsområder.

Lag innholdet til alle sidene, én om gangen.

Leveranse

Godkjente sidebeskrivelser med innhold: tekst, CTA, metadata, dokumentasjon og visuelt materiale. Du kan bygge forsiden og én representativ tjenesteside først, for å teste at systemet fungerer før du utvider til resten av tjenestene og kontaktsiden.

7. Skill ut komponenter som kan gjenbrukes

Se på mockupene og sidebeskrivelsene, og merk det som faktisk går igjen: topptekst, navigasjon, bunntekst, knapper, skjema, fordelskort, bildeblokker, avsluttende CTA-er og meldinger …

Tanken er at vi lager gjenbrukbare komponenter for dette, slik at et nytt telefonnummer bare trenger å endres i én komponent for å bli oppdatert på alle URL-ene. Topptekst og bunntekst er åpenbart gjenbrukbare elementer, men det kan finnes flere.

Det kan også hende at du vil at alle tjenestesidene skal bruke samme design eller struktur. Derfor bør du skille strukturen fra dataene. For eksempel:

• En mal for tjenestesider kan sette sammen felles blokker uten å tvinge alle sider til å bruke samme tekst.
• Mer konkret: En fordelskomponent kan beholde oppsettet mens tittel, forklaring og ikon endres.

Test dette i praksis før du kopierer mønsteret overalt: Be ChatGPT lage prompten som får Codex til å bygge forsiden og én tjenesteside, sammenlign dem med mockupene og juster både det individuelle innholdet og de felles komponentene.

Sjekk hvordan det ser ut på datamaskin og mobil. Når alt er riktig, utvider du systemet til resten.

Leveranse

Ferdig oppsatt forside og én tjenesteside.

Oversikt over komponentene, hvilke data hver komponent mottar, og hvilke sider som bruker dem.

8. Klargjør bildene for produksjon

Nå som tekstene er klare, er det bildenes tur.

Ideelt sett har kunden sendt deg noen brukbare bilder. I praksis skjer det sjelden. Heldigvis er ChatGPT din venn, og systemet for å lage og redigere bilder er virkelig, virkelig bra, hvis du ikke er stødig i Photoshop. Så da setter vi i gang.

Ikke gjør dette unødvendig komplisert. Mellom ett og tre bilder per URL bør holde i massevis, og noen av dem vil trolig bli brukt flere steder. Det beste er om det første bildet, hovedbildet, er forskjellig på hver side.

Ta vare på kundens originaler, og lagre en hovedversjon i god kvalitet av hvert nytt bilde i mapper som ikke skal lastes opp til kodelageret.

Deretter ber du ChatGPT instruere Codex om å tilpasse hvert bilde til plasseringen på nettstedet ved å:

• Lage versjoner i riktige dimensjoner og filformater, vanligvis .webp for fotografier og SVG for ikoner.
• Definere responsive størrelser og unngå å sende en mobil et bilde som er beregnet på å fylle en stor skjerm.
• Reservere plass til bildet slik at siden ikke hopper mens det lastes. Hovedbildet kan trenge høy nedlastingsprioritet, mens et bilde langt nede kan vente.
• Skrive nyttig alternativ tekst som beskriver informasjonen i bildet, og gjerne ta med et relevant søkeord hvis det passer naturlig.

Leveranse

Ferdige bilder til nettstedet.

9. Lag ikonene

Dette er sannsynligvis det vanskeligste punktet å optimalisere på nettsteder med mange ikoner (mer enn 20 eller 30).

Saken er at det er vanskelig å lage varianter av alle ikonene i nøyaktig samme stil, særlig på ett og samme ikonark. Til slutt ender du med å ta ett og ett, og det tar tid.

Og så kommer noe enda vanskeligere: å konvertere dem til SVG og få dem til å se bra ut. Derfor er mitt råd at du bare bruker manuelt beskårne PNG-filer eller PNG-filer fra et ikonark laget i Photoshop hvis det er det som fungerer. Du oppnår ikke 100 % av den mulige optimaliseringen, men sparer utrolig mye tid. Jeg snakker av erfaring.

På Rondabus prøvde jeg for eksempel flere løsninger fordi de første illustrasjonene ikke stemte med referansene: Noen var for enkle, andre hadde en annen visuell skala selv om de lå innenfor samme ramme. Jeg undersøkte også utsnitt og PNG-er fra de godkjente arkene, men løsningen som ble brukt i versjon 2.0, var de originale SVG-ene, vist i større størrelse..

Slik gjennomfører du prosessen:

1. Finn først ut hvor hvert ikon vises, og hva det betyr.
2. Grupper ikoner som gjentas.
3. Ta vare på en master for hver illustrasjon eller hvert ikonark.
4. Lag en forhåndsvisning i de faktiske sammenhengene: hero, kortmodul for tjenester, modul med fordelsliste, kontakt …
5. Juster den optiske størrelsen uten å forvrenge formene: To ikoner med samme filbredde kan se svært ulike ut på grunn av luft rundt motivet.
6. Test et utvalg på en viktig side (forside eller tjenesteside) før du prøver å endre alle sidene. Hvis et forsøk ikke gjenskaper stilen fra mockupen godt nok, gå tilbake til referansen og forkast forsøket.
7. Bruk løsningen på resten av sidene.
8. Filformatet er et implementeringsvalg. Den visuelle kvaliteten og konsistensen er det brukeren legger merke til, og det er det viktigste.

Leveranse

Godkjent ikonsett og originalfiler.

10. Bygg nettstedet i etapper

Når forsiden og mønsteret for tjenestesidene er godkjent, bygger du resten av sidene og gjennomgår dem én etter én. Selv om de deler mal, er det ikke sikkert at alle fungerer visuelt: Lengden på overskrifter, fotografier, antall fordeler, knappetekster og målgruppens behov varierer.

Kontroller på datamaskin og flere skjermbredder for mobil og nettbrett. Ta på deg brukerbrillene, sammenlign hver side med mockupen, og test det en statisk designskisse ikke kan vise:

• Nedtrekksmeny.
• Lenker.
• Validering på klientsiden i skjemaet.
• At bilder og ikoner lastes inn.
• Langt innhold.
• Linjeskift i overskrifter.
• …

Det lønner seg å lagre kontrollpunkter i koden når en etappe med flere endringer blir godkjent. Be ChatGPT om det mens du finpusser detaljene.

Leveranse

Ferdige sider i frontenden (skjemaet må fortsatt testes, hvis du har et).

Kontrollpunkt for ferdig frontend, nettsted versjon V1 (ett språk). Hvis du regner nettstedet som ferdig på dette stadiet, hopper du til punkt 17 for å publisere det.

11. Sett opp et skjema og andre kontaktmuligheter

Hvis du har lest artiklene mine om Astro, vet du to ting:

1. Du publiserer HTML-filer.
2. På en server uten serversideprogrammering (PHP, Python).

Dette har mange fordeler og én ulempe: Du kan ikke sende inn skjemaer direkte.

Det finnes flere løsninger, blant annet:

• Bruke betalte tjenester fra Cloudflare.
• Bruke en e-postleverandør (gratis eller betalt) og koble til tjenesten via API.

Ettersom jeg vanligvis også setter opp e-postsystemet for disse prosjektene og bruker gratisversjonen av Zoho Mail, velger jeg å bruke denne tjenesten til å sende e-post fra skjemaene fremfor å legge til enda en leverandør.

Det er litt komplisert og krever flere trinn du må utføre manuelt, så be ChatGPT veilede deg trinn for trinn. Og framfor alt: Ikke legg hemmeligheter (secrets) i GitHub-kodelageret. Cloudflare har et eget sted for å oppbevare dem.

Når det er klart, fyller du ut skjemaet både riktig og feil for å kontrollere at valideringen fungerer, og at innsendingen faktisk kommer fram.

Hvis du ikke allerede har gjort det, er det også et godt tidspunkt å teste telefon- og WhatsApp-lenkene på en ekte mobiltelefon, hvis du har lagt dem til – noe du nesten helt sikkert bør ha gjort.

Leveranse

Et skjema som er testet og fungerer hele veien fra innsending til mottak.

Kontrollpunkt, nettsted versjon V1.5 (ferdig med skjema og ett språk).

Med dette, og med unntak av publiseringen (trinn 17), har vi faktisk alt det nødvendige for et nettsted til en lokal bedrift på plass. Men de neste trinnene er STERKT ANBEFALT hvis vi faktisk vil skaffe kunder.

12. Mål henvendelser og konfigurer samtykke

Vi starter de valgfrie trinnene med noe grunnleggende: måling.

Hva vil vi måle? Det viktigste:

• Konverteringshendelser.
• Trafikk.

Hvorfor?

For å vite hvor salgene kommer fra, særlig hvis vi tenker å bruke penger på annonser for å skaffe de første kundene (det bør du absolutt vurdere).

Før vi installerer noe, må vi derfor lage en måleplan som definerer forretningshendelsene. De vil være ganske opplagte:

• Kontakt via telefon.
• Via WhatsApp.
• Via e-post.
• Via skjema.
• Timebestilling i kalenderen.
• Abonnement (på nyhetsbrev, hvis aktuelt).
• Klikk for å se adressen i Google Maps.

Og dette er sannsynligvis alle hendelsene du trenger å måle på et slikt nettsted.

Bestem hvilke som er relevante for ditt prosjekt, og be ChatGPT gi deg:

• Hendelsesnavnet i tråd med Googles anbefalte navngivning, siden jeg foreslår å bruke Google Analytics 4 til å måle dette.
• Utløserbetingelsen for hendelsen.
• Ekstra parametere (der det er relevant).

Systemet fungerer slik:

En bruker utfører en hendelse på nettstedet > Google Tag Manager fanger den opp > GA4 lagrer den slik at du kan se dataene.

Opprett konto i både GA4 og GTM med Google-kontoen din. Når du først er i gang, kan du også registrere deg i GSC, som vi trenger senere til SEO.

Hvis bedriften ligger i EU, avhenger målingen også av personvernvalgene. Be derfor ChatGPT implementere Google Consent Mode v2 advanced, med en mulighet til å åpne samtykkeinnstillingene på nytt. Da får du det vanlige informasjonsbanneret om informasjonskapsler.

Når dette er avklart, ber du ChatGPT instruere Codex om å lage en JSON-fil med beholderen som skal importeres i GTM. KI-en vil be deg om ID-ene til GA4- og GTM-kontoene og gi deg en liten fil med alt som trengs, klar til import.

Så gjenstår det bare å teste hver hendelse i GTMs forhåndsvisning før du publiserer beholderen og begynner å samle reelle data fra nettstedet.

Leveranse

Måleplan og fungerende implementering av GTM og GA4, med testet samtykkehåndtering hvis det er aktuelt.

13. Fullfør teknisk SEO og publiser den første versjonen

Hvis du arbeider med lokal SEO, og det bør du, er det på tide å kjøre Screaming Frog og kontrollere feilene. Be ChatGPT hjelpe deg med å rette dem.

Koble nettstedet til Google-bedriftsprofilen din. Kontroller navn, kategorier, adresse eller dekningsområde, telefonnummer, åpningstider, bilder og tjenester uten å finne på steder.

I tillegg åpner du GSC (Google Search Console) og laster opp det genererte nettstedskartet . Hvis du ikke kjenner URL-en, kan du spørre Codex. Etter noen dager kan du se om de viktigste sidene kan gjennomsøkes og indekseres.

Leveranse

Et nettsted uten tekniske SEO-feil, med kontrollerte URL-er og sitemap og riktig kanonisk domene.

Dette kan vi kalle versjon V2..

14. Bestem om det er verdt å utvide nettstedet til flere språk

Nå er vi kommet til den siste delen av prosessen: å oversette nettstedet til andre språk.

Før du bestemmer deg, må du avklare:

• Hvilke målgrupper du ønsker å nå.
• Hvilket språk du vil betjene dem på.

Det er ikke det samme å tilby massasjetjenester til en nordmann i Málaga uten å snakke norsk som å tilby advokattjenester. Du kan også tiltrekke deg japanere som leter etter taxi i Ronda, men gjøre det tydelig at du bare betjener dem på engelsk.

Et nytt språk betyr dessuten oversettelse av innhold, menyer, skjemaer, metadata, schema og senere oppdateringer. Det handler ikke bare om en knapp med et flagg.

Når du og ChatGPT har bestemt hvilke språk nettstedet skal ha, avklarer dere:

• Utgangsspråket, altså språket som allerede brukes på det offentlige nettstedet.
• Språkene det skal oversettes til.
• Hvilke sider som skal oversettes – ikke nødvendigvis alle (for eksempel 404-siden eller de juridiske sidene).
• URL-strategien. Bestem om slugs skal oversettes, hvordan tilsvarende sider kobles sammen, og hva som skjer når en oversettelse mangler.

Arkitekturen bør identifisere hver side med en stabil kode som er uavhengig av språket. Da kan språkvelgeren sende brukeren til den tilsvarende siden, og nettstedet kan generere hreflang -relasjoner uten å måtte gjette ut fra den synlige tittelen.

Alt dette må være klart før du oversetter.

Leveranse

Oversettelsesplan.

15. Skill mellom eksport, oversettelse og integrasjon

Arbeidsmåten som fungerer best for meg, er å dele opp jobben.

1. Codex undersøker prosjektet og lager en tekstpakke med stabile ID-er, kildetekst, kontekst, målspråk, plassholdere, lenker og beskyttede termer. Vanligvis får vi en pakke med JSON eller XML.
2. ChatGPT oversetter pakkene, gjennomgår verdiene og leverer de oversatte filene.
3. Codex integrerer filene og validerer sidene.

Med denne arbeidsdelingen kan du bytte oversetter (eller bruke et menneske) uten å kreve at vedkommende forstår koden, og uten at utvikleren må gjette seg til betydningen av hver setning. Gjennomgangen i ChatGPT erstatter selvsagt ikke en språklig gjennomgang av en autorisert oversetter.

Prompt for eksport:

Undersøk prosjektet og lag en oversikt over oversettbart innhold for [idiomas]. Ta med synlig tekst, navigasjon, skjemaer, metadata og slugs. Oppgi for hver enhet en stabil ID, kildetekst, kontekst, markører, lenker og beskyttede termer. Ikke oversett eller endre sidene ennå. Rapporter tvetydige strenger og innhold som ikke har noen tilsvarende oversettelse.

Prompt for oversettelse:

Oversett bare verdiene i pakken til [idioma y variante]. Målgruppe: [audiencia]. Tone: [tono]. Ordliste: [términos]. Behold ID-er, struktur, rekkefølge, plassholdere, egennavn, lenker og kode. Rapporter utenfor pakken formuleringer som krever en forretningsbeslutning eller en språklig kontroll av en morsmålsbruker.

Prompt for integrasjon:

Importer disse godkjente oversettelsene i prosjektet. Kontroller ID-er, markører, beskyttede termer, slugs og tilsvarende ruter. Ikke publiser et språk hvis obligatoriske tekster mangler. Kjør oversettelsesrevisjon, prosjektkontroller og build, og rapporter alle avvik før utrulling.

Leveranse

Flerspråklig nettsted som ennå ikke er gjennomgått.

16. Kontroller hvert språk som et fullstendig nettsted

Når oversettelsene er integrert, åpner du sidene: En gyldig fil kan likevel gi en meny som går utenfor skjermen, en altfor lang CTA eller en melding som dekker skjemaet. Kontroller hver URL på hvert språk, både på datamaskin og mobil.

Når det gjelder SEO, kontrollerer du (selv eller med ChatGPT):

• <html lang>.
• Tittel.
• Beskrivelse.
• Lokaltilpasset URL.
• Egen canonical-lenke.
• Relasjoner med hreflang mellom tilsvarende sider.
• Sitemap med URL-er som skal indekseres.
• Språkvelgeren skal beholde den aktuelle siden ved språkbytte når det finnes en tilsvarende side.
• Kontroller også lenkene i bunnteksten.
• Skjemaer og feilmeldinger.
• Alternativ tekst til bildene.
• Strukturerte data som inneholder tekst eller URL-er.

Juster så mange ganger som nødvendig til alt er gjennomarbeidet.

Leveranse

Fullstendig flerspråklig nettsted, versjon V3.

17. Publiser en identifiserbar versjon og kontroller produksjonsmiljøet

Enten du er ferdig etter trinn 10 (V1), 11 (V1.5), 13 (V2) eller det forrige (V3), har du nå et nettsted som kjører i et testmiljø. Det gjenstår å legge det ut i produksjon. Det gjør vi her.

Her ber vi ChatGPT instruere Codex om å publisere builden på Cloudflare.

Da vil Codex:

1. Logge på GitHub-kontoen vår.
2. Be oss velge eller opprette riktig kodelager.
3. Logge på Cloudflare-kontoen vår.
4. Spørre hvilket domene nettstedet skal publiseres på.
5. Publisere den nyeste versjonen av nettstedet.

Deretter trenger vi bare å kontrollere at alt ser ut akkurat som i testversjonen.

Da er nettstedet ferdig.

Leveranse

Fullstendig versjon av nettstedet publisert.

18. Gjør prosjektet til en metode du kan gjenta

Dette er enda mer valgfritt, men veldig nyttig hvis du vil bruke samme prosess på nettstedet til en annen bedrift.

Du trenger bare å be ChatGPT lage en Skill med hele prosessen dere har fulgt. Da slipper du å huske alle trinnene neste gang eller komme tilbake hit for å lese guiden igjen. ChatGPT har tatt vare på den, og Codex får den installert i systemet sitt.

Da går det mye, mye raskere å lage det neste nettstedet for en lokal bedrift.

Ganske kult, ikke sant?