Hem › Migrera en Bolt (bolt.new)-sajt till statisk hosting — äg den, ranka den

WordPressEscape-guide

Migrera en Bolt (bolt.new)-sajt till statisk hosting — äg den, ranka den

Bolt.new är perfekt för att snabbt bygga interaktiva prototyper, men att göra om den där demon till en produktionssajt innebär att migrera den till statisk hosting som du själv fullt ut äger — med SEO, rena URL:er och en plan för omdirigeringar.

Varför en Bolt.new-prototyp inte är en produktionssajt

Bolt.new (StackBlitz Bolt) låter dig lansera en fungerande webbapp eller sajt på några sekunder. Det är fantastiskt för prototyper, kodexempel och interaktiva demos. Men samma egenskaper som gör Bolt så smidigt begränsar det också som långsiktig hemvist för en produktionssajt: du kör i någon annans plattform, på någon annans hosting och URL-struktur, och under någon annans begränsningar.

De flesta Bolt-projekt ligger på en icke-brandad URL, är knutna till ditt StackBlitz-konto och levereras inte med riktig SEO-infrastruktur från start. Ofta finns ingen produktionsklar sitemap, ingen strukturerad data, ingen strategi för kanoniska URL:er och ingen plan för omdirigeringar när du ändrar eller tar bort sidor. För en prototyp fungerar det. För en sajt du vill ska ranka, konvertera och bli en del av ditt varumärke är det en risk.

Det finns också en kontrollfråga. Om din Bolt-instans går ner, om plattformen ändrar sina villkor eller stryper äldre projekt, eller om du behöver funktioner Bolt inte är byggt för att stödja (egna TLS-regler, finmaskig cache, loggar), sitter du fast. Du kan inte bara SSH:a in på en server eller justera din egen edge-konfiguration. Du är låst till det Bolt exponerar.

Rätt uppgraderingsväg är inte att ”flytta prototypen till ett CMS och hoppas på det bästa”. Det är att behandla ditt Bolt-projekt som en kodbas. Du vill extrahera appen, definiera en statisk build-output och distribuera den statiska outputen till en miljö du äger och kontrollerar — samtidigt som du lägger till full SEO-struktur, rena URL:er, sitemaps, schema och en omdirigeringsstrategi. Det är där statisk hosting på moderna edge-plattformar, och tjänster som WordPressEscape, kommer in som Bolt-prototypens produktionssida.

• Prototyp: Snabb, förbrukningsbar, begränsad SEO och ägarskap.
• Produktion: Tålig, kontrollerad, med SEO, omdirigeringar och prestandagarantier.
• Målet med migreringen: Göra om Bolt-koden till statisk output du fullt ut äger, utan att förlora något viktigt.

Hur Bolt.new fungerar under huven (och varför det spelar roll vid migrering)

För att migrera en Bolt.new-sajt på ett effektivt sätt behöver du förstå vad Bolt faktiskt gör. Bolt kör din kod i en webbläsarbaserad miljö som drivs av StackBlitz WebContainers. Du får ett live-filsystem, en dev-server och hot reloads direkt i webbläsaren. Det betyder att kodbasen du ser i Bolt är ett riktigt projekt — React, Vue, Next, ren HTML/JS eller något liknande — som servas av en utvecklingsserver.

Ur migreringssynpunkt är det viktiga detta: Bolt är inte en svart låda. Det är ett filarkiv med en körbar app. Målet är att få ut filerna, köra en build som producerar statiska tillgångar (HTML, CSS, JS, bilder) och distribuera dem till din egen hosting. Om ditt Bolt-projekt redan använder en statisk webbplatsgenerator eller ett ramverk med statisk export (Next.js static export, Astro, Hugo osv.) ligger du före. Om det är en enkel SPA utan renderade rutter på serversidan behöver du tänka på crawlbarhet och HTML-output.

Bolt lagrar vanligtvis projektet antingen direkt i webbläsaren eller synkat med ett Git-repository. Om du skapade projektet från ett GitHub-repo eller har kopplat versionshantering kan du helt enkelt klona repot lokalt för att börja migreringen. Om projektet bara finns i webbläsaren behöver du ladda ner projektets ZIP från Bolt eller exportera det till Git. När det väl är ute ur Bolt är det bara kod: din bundler, din package.json och dina build-skript.

Det är också här du bestämmer den framtida arkitekturen. WordPressEscape använder till exempel Hugo som statisk generator under huven och distribuerar till Cloudflare:s edge. Du kan översätta en Bolt-sajt till ett Hugo-projekt (särskilt om den mest består av sidor och mallar), eller behålla din befintliga stack om den har en statisk build. Det viktiga är att Bolts utvecklingsmiljö måste ge vika för en reproducerbar build-pipeline som du kontrollerar.

• Kodexport: Ladda ner eller klona Bolt-projektets kod.
• Build-pipeline: Konfigurera en statisk build (t.ex. npm run build) som genererar HTML och tillgångar.
• Hostingmål: Bestäm var den statiska outputen ska ligga: Cloudflare, Netlify, S3 eller en tjänst som WordPressEscape.

Steg 1: Granska din Bolt.new-sajt innan du migrerar

Innan du flyttar något från Bolt är det klokt att göra en ärlig inventering av vad du faktiskt har byggt. De flesta Bolt-prototyper växer organiskt: en startsida, några rutter, kanske ett eller två API-anrop och några interaktiva komponenter. För att göra detta till en produktionsklar statisk sajt behöver du veta exakt vilka sidor som finns, hur de länkar till varandra och vad som driver dem.

Börja med att lista varje route och vy. Navigera genom din Bolt-app och skriv ner de URL:er som spelar roll: startsidan, viktiga landningssidor, blogginlägg eller dokumentation, eventuella registrerings- eller prissidor samt specialrutter (som /dashboard) som inte ska vara publika. Om du använder en router (React Router, Vue Router), granska routkonfigurationen för att bekräfta listan. Målet är att skapa en slutgiltig URL-karta som du kan bevara efter migreringen.

Därefter identifierar du dynamiskt beteende. Fråga dig själv: vilka delar av sajten drivs av klientbaserad JavaScript som hämtar data vid körning, och vilka delar kan renderas till statisk HTML? En statisk migrering fungerar bäst när kärninnehållet på varje sida kan bakas in i HTML vid build-tillfället. Om din Bolt-prototyp är en ren klientapp som hämtar innehåll från ett API, bör du överväga att för-rendera dessa svar under builden eller använda en statisk generator som stödjer datahämtning vid build-tillfället.

Till sist: bedöm design- och varumärkeselementen. Notera färgsättning, typografi, logotypanvändning, mellanrum och komponentbibliotek. Det är dessa delar du vill bevara när du bygger om. WordPressEscape rekonstruerar till exempel frontend med Hugo-mallar som speglar den befintliga designen, så att du behåller känsla och uttryck medan den underliggande tekniken byts ut. Den här förmigreringsgranskningen gör att inget viktigt tappas bort när du lämnar Bolt.

• Rutininventering: Lista alla URL:er som är viktiga för användare och SEO.
• Dynamiskt kontra statiskt: Markera vilka sidor som kan renderas helt till HTML.
• Varumärkeselement: Dokumentera typsnitt, färger, logotyper och layoutmönster som ska bevaras.

Steg 2: Exportera Bolt-koden och sätt upp en lokal statisk build

När du vet vad du ska migrera är nästa steg att få ut koden ur Bolt.new och in i din egen miljö. Om ditt Bolt-projekt är länkat till GitHub klonar du repot lokalt med ditt vanliga Git-flöde. Om det inte är det använder du Bolts nedladdningsfunktion för att exportera en ZIP-fil av filsystemet och initierar sedan Git på din dator. Du vill ha en lokal kopia som du kan bygga om och refaktorera utan att vara beroende av Bolts webbläsarruntime.

När koden är lokal granskar du build-skripten i din package.json eller projektkonfiguration. De flesta moderna upplägg har kommandon som ”build”, ”export” eller ”generate”. Kör dem lokalt och inspektera utdatakatalogen — ofta /dist, /build eller /public. Målet är en statisk artefakt: HTML-filer för varje route du bryr dig om, plus CSS, JavaScript-bundles och tillgångar. Om du bara ser en enda index.html och en stor JS-bundle kan din app vara en SPA utan statisk export. I så fall bör du överväga server-side rendering eller en statisk generator i stället för att trycka ut SPA:n som den är.

Om du migrerar in i en Hugo-baserad pipeline (som WordPressEscape gör) översätter du Bolt-komponenterna till Hugo-mallar och partials. Det innebär ofta att innehåll flyttas till Markdown-filer, layouts till Hugo-mallar och delad UI till partials. Fördelen med Hugo är att det är byggt för statisk output: varje sida blir en URL med en riktig HTML-fil. Hugo kan generera hundratusentals sidor vid build-tillfället, vilket är hur vi har migrerat sajter med 528 854 sidor utan att förlora URL:er eller placeringar.

Innan du går vidare till hosting bör du verifiera att din lokala build beter sig som du förväntar dig. Starta en enkel statisk server (till exempel med ett verktyg som serve eller en snabb Python HTTP-server) och klicka dig igenom alla sidor. Kontrollera att interna länkar fungerar, att formulär skickas till rätt endpoints och att det inte finns några klientfel i konsolen. När den statiska builden beter sig som din Bolt-sajt är du redo att distribuera.

• Klona eller ladda ner: Få ut Bolt-projektets kod på din lokala dator.
• Kör builden: Kör det statiska build-kommandot och granska utdatakatalogen.
• Mallöversättning: Mappa eventuellt dina Bolt-komponenter till Hugo eller en annan statisk generator för mer kontroll.

Steg 3: Skapa en strategi för URL:er, omdirigeringar och kanoniska adresser

En prototyp kan komma undan med vilken URL-struktur som helst som Bolt råkar ge. Det kan inte en produktionssajt. När du migrerar bör du se URL-strukturen som ett långsiktigt avtal med både användare och sökmotorer. Rena, konsekventa URL:er är en av de enklaste och mest kraftfulla SEO-förbättringar du kan göra, och de är svårare att ändra i efterhand än att designa rätt från början.

Börja med att definiera din kanoniska domän och URL-form. Om din Bolt-prototyp låg på något i stil med bolt.new/your-project, bestäm om du ska flytta till www.yourbrand.com eller en dedikerad subdomän som app.yourbrand.com. Definiera sedan mönster för centrala innehållstyper: till exempel /blog/post-slug/, /docs/topic-slug/, /pricing/ och /about/. Undvik URL:er som är beroende av query-strängar och slumpmässiga ID:n för sidor som ska leva länge. Både användare och Google föredrar läsbara sökvägar.

Om dina Bolt-URL:er redan har delats, indexerats eller bokmärkts behöver du planera omdirigeringar. Det är här en produktionsklar plattform spelar roll: du behöver kunna konfigurera 301-omdirigeringar från gamla Bolt-URL:er till nya statiska URL:er. På Cloudflare och liknande edge-plattformar kan du definiera omdirigeringsregler som skickar trafik från de gamla sökvägarna till de nya permanent. Med WordPressEscape blir varje befintlig WordPress-URL en statisk Hugo-URL med omdirigeringar hanterade vid edge:n; du kan använda samma disciplin när du lämnar Bolt.

Kanoniska taggar är den sista pusselbiten. För alla sidor som kan nås via mer än en URL (till exempel med och utan avslutande snedstreck, eller både /blog och /blog/) ska du definiera en enda kanonisk URL och skriva ut en link rel="canonical"-tagg som pekar dit. Det talar om för sökmotorerna vilken version som ska betraktas som auktoritativ och undviker problem med duplicerat innehåll. Om du designar detta i förväg, innan du publicerar din statiska sajt, slipper du smärtsamma justeringar senare.

• Kanonisk domän: Välj www.yourbrand.com eller en stabil subdomän som huvudadress.
• Rena mönster: Definiera läsbara URL-strukturer för varje innehållstyp.
• Omdirigeringsregler: Mappa gamla eller delade Bolt-URL:er till dina nya kanoniska sökvägar med 301:or.

Steg 4: Lägg till riktig SEO-struktur: sitemap, schema och metataggar

En av de största skillnaderna mellan en Bolt-prototyp och en produktionsklar statisk sajt är hur sökmotorer ser den. Bolt genererar inte automatiskt XML-sitemaps, strukturerad data eller noggrant justerade metataggar. När du migrerar har du chansen att lägga till dessa delar systematiskt och få en omedelbar SEO-fördel — utan att ändra ditt innehåll.

Börja med en XML-sitemap. Det är en maskinläsbar lista över sajtens sidor, som sökmotorer använder som en ledtråd för crawlning. För en liten sajt kan du skapa den manuellt, men för något större än ett dussin URL:er bör du automatisera den. Statiska generatorer som Hugo kan skriva ut sitemaps automatiskt utifrån dina innehållsfiler. Sitemapen ska innehålla kanoniska URL:er för dina kärnsidor och länkas i din robots.txt-fil. När den är publicerad skickar du in sitemapen till Google Search Console och andra webmaster-verktyg.

Implementera sedan strukturerad data (schema). För en typisk marknadsförings- eller dokumentationssajt fokuserar du på typer som Organization, Website, Article och FAQPage. Det här är JSON-LD-snuttar som bäddas in i din HTML och beskriver innebörden av ditt innehåll. Schema hjälper till med rich results (som FAQ-accordioner i sökresultat) och ger sökmotorer tydligare kontext om ditt varumärke. Eftersom sajten är statisk kan du baka in schema vid build-tillfället med mallar som säkerställer konsekvens.

Försumma inte metataggar och grundläggande on-page SEO. Varje sida bör ha en unik, beskrivande <title>, en tydlig metabeskrivning, hreflang-taggar om du erbjuder flera språk och en rubrikstruktur som matchar innehållet. Statiska mallar gör detta enklare än ad hoc-redigering. Med WordPressEscape till exempel ger ESC'dashboard dig en bekant WordPress-lik redigeringsupplevelse för att hantera titlar, beskrivningar och innehåll utan att återinföra ett dynamiskt CMS under ytan. Du får både prestandan hos en statisk sajt och smidigheten i ett strukturerat SEO-arbetsflöde.

• Sitemap: Generera och publicera en XML-sitemap med kanoniska URL:er.
• Schema: Lägg till JSON-LD för Organization, Website, Article och andra relevanta typer.
• Metataggar: Säkerställ unika titlar, metabeskrivningar och rena rubrikstrukturer för varje sida.

Steg 5: Distribuera till statisk hosting du äger (Cloudflare och mer)

Med en statisk build och SEO-struktur på plats är du redo att lämna Bolt.new bakom dig och distribuera till infrastruktur du kontrollerar. Dagens alternativ för statisk hosting sträcker sig från edge-nätverk som Cloudflare till plattformar som Netlify, Vercel och klassisk objektlagring med en CDN framför. Nyckeln är att välja en host som ger dig låg latens, förutsägbara kostnader och finmaskig kontroll över cache och omdirigeringar.

Cloudflares edge-nätverk är en stark passform för statiska sajter som migrerats från Bolt. När du distribuerar statiska tillgångar till Workers eller Pages som backas av Cloudflares CDN kan sajten nå en time to first byte (TTFB) i spannet runt 30 ms globalt och PageSpeed-poäng på 94+ eftersom innehållet serveras från datacenter nära dina besökare. I våra migreringar på WordPressEscape ser vi regelmässigt att cumulative layout shift (CLS) sjunker till noll eftersom sidorna inte längre är beroende av långsam tredjepartsrendering.

Om du är bekväm med DevOps kan du koppla ihop CI/CD själv: pusha din statiska build till ett Git-repo, konfigurera Cloudflare Pages eller Workers att distribuera vid commit och hantera miljövariabler och omdirigeringar via konfigurationsfiler. Om du vill ha en hanterad upplevelse sköter en tjänst som WordPressEscape edge-distributionen åt dig, mappar varje befintlig URL till en statisk Hugo-sida och verifierar att inga URL:er går förlorade i processen — även för enorma sajter med hundratusentals sidor.

Oavsett vem som hanterar hostinglagret måste du se till att HTTP-cachningen är korrekt inställd. Cacha statiska tillgångar aggressivt, använd immutable-cache för hashade filer och konfigurera kortlivad cache där snabba uppdateringar behövs. Testa din produktionsdistribution med verktyg som Googles Lighthouse för att bekräfta att migreringen från Bolt gav den prestanda du förväntade dig. En korrekt distribuerad statisk sajt ska inte bara matcha Bolts snabbhet; den ska överträffa den och förbli snabb under verklig trafik.

• Edge-hosting: Distribuera statiska tillgångar till ett edge-nätverk som Cloudflare för TTFB under 50 ms.
• CI/CD: Automatisera builds och distributioner från ditt Git-repo.
• Cache och prestanda: Justera cache-headrar och verifiera PageSpeed, CLS och TTFB i produktion.

Varför WordPress inte är den uppgradering du tror

När utvecklare växer ur en prototyp i Bolt.new är standardinstinkten ofta ”flytta det till WordPress”. På pappret ser WordPress ut som en uppgradering: ett fullskaligt CMS, ett plugin-ekosystem, teman och ett välbekant admin-gränssnitt. I praktiken byter du bara ut en uppsättning begränsningar mot en annan — och introducerar nya risker som statisk hosting inte har.

WordPress arkitektur är i grunden dynamisk. Varje sidladdning träffar PHP, databasen och en rad plugins, om du inte bygger på ett komplext cachelager ovanpå. Det gör prestandan skör. Det är vanligt att WordPress-sajter har svårt att hålla PageSpeed-betyg över 90, särskilt när plugins staplas på varandra. TTFB kan lätt överstiga 500 ms på delad hosting, och även optimerade upplägg hamnar ofta i spannet 150–300 ms globalt. Du kan kringgå detta med cache-plugins och CDN:er, men då lappar du på ett system som inte var byggt för att vara statiskt.

Det finns också ett överhäng kring plugins och säkerhet. Varje plugin introducerar potentiella sårbarheter och kompatibilitetsproblem. Att hålla WordPress uppdaterat, hantera säkerhetskopior och härda installationen mot attacker är ett löpande jobb. Det här är inga inbillade problem; de är orsaken till att så många byråer satsar på managed WordPress-underhåll. Om målet efter Bolt är en enkel, snabb sajt som rankar och konverterar, är det inte säkert att ännu ett dynamiskt CMS-lager är den mest effektiva vägen.

Statiska lösningar undviker de här fallgroparna. WordPressEscape tar en ännu tydligare position genom att permanent radera WordPress i varje migrering. I stället för att behålla WordPress som en dold backend (som vissa statiska exportverktyg gör) bygger WordPressEscape om sajten som statisk Hugo på Cloudflare:s edge, bevarar varje URL och varje placering och ger dig en WordPress-lik redigerare (ESC'dashboard) utan WordPress under huven. Du behåller CMS:ets redigeringsflöde men tar bort runtime-overheaden. För en sajt som började som en Bolt-prototyp betyder det att din ”uppgradering” inte innebär att du lägger till en tung backend — du går från prototyp till statisk produktion i ett steg.

• Dynamiskt overhead: WordPress är beroende av PHP och databaser för varje begäran.
• Prestandarisk: Plugins och teman drar ofta ner PageSpeed och TTFB.
• Statiskt alternativ: Använd statisk Hugo vid edge:n med en CMS-lik redigerare i stället för att lägga till WordPress.

Bolt.new vs statisk Hugo på Cloudflare: avvägningar och resultat

Att jämföra Bolt.new med en statisk Hugo-distribution på Cloudflare hjälper till att tydliggöra vad du vinner och vad du förlorar i migreringen. Bolt är optimerat för utvecklarbekvämlighet och snabb prototypframtagning. Hugo vid edge:n är optimerat för reproducerbara builds, prestanda och långsiktig stabilitet. När du förstår de här avvägningarna blir migreringsbeslutet mindre en fråga om verktyg och mer en fråga om resultat.

I Bolt får du omedelbar start, en webbläsarbaserad utvecklingsmiljö och noll uppsättning. Sajten blir live snabbt, men du är bunden till plattformens hostingmodell och URL-rymd. SEO-funktioner måste hanteras manuellt, och att skala bortom en enkel prototyp innebär ofta genvägar. I Hugo med Cloudflare tar den första uppsättningen mer tid, men varje efterföljande build är förutsägbar. Hugo kan generera tiotusentals sidor på sekunder, och Cloudflare serverar dem från edge:n. Enligt vår erfarenhet gör den kombinationen det möjligt att migrera enorma sajter — vår egen WordPress-sajt med 528 854 sidor, till exempel — samtidigt som inga URL:er tappas och placeringarna bevaras.

Prestandamässigt når en väljusterad statisk Hugo-sajt vanligtvis PageSpeed-poäng runt 94+ och TTFB nära 30 ms för en global publik, med cumulative layout shift i praktiken på 0. Det är siffror som är svåra att nå konsekvent med ett dynamiskt CMS eller en plattformslösning för prototyper. När sajten väl är ute i produktion finns färre rörliga delar: ingen PHP-runtime, inga databasavbrott och inga plugin-konflikter. Dina löpande kostnader handlar främst om hosting och bandbredd, inte underhåll.

Den största avvägningen är var du gör ditt redigeringsarbete och din iteration. Bolt gör redigering kodvänlig men inte innehållsvänlig. Hugo gör builds deterministiska men förutsätter att du hanterar innehåll som filer, om du inte lägger till ett redigeringslager. WordPressEscapes ESC'dashboard bygger bro över den klyftan genom att ge dig en WordPress-lik redigerare ovanpå den statiska Hugo-sajten. För team innebär det att utvecklarna får den statiska arkitektur de vill ha, medan innehållsredaktörerna får den bekanta känslan av ett CMS utan WordPress-bagaget eller Bolts begränsningar.

• Bolts styrkor: Snabb prototypframtagning, utveckling i webbläsaren, omedelbara demos.
• Statiska Hugo-styrkor: Edge-prestanda, enorm skala, förutsägbara builds.
• Resultatfokus: Välj den stack som matchar långsiktiga behov av SEO, prestanda och arbetsflöde — inte bara initial bekvämlighet.

Vanliga migreringsmissar (och hur du undviker dem)

Att migrera en Bolt.new-sajt till statisk hosting är inte svårt, men det är lätt att missa detaljer som spelar roll i produktion. Genom att förutse vanliga misstag kan du slippa jaga buggar efter lansering och skydda både SEO och användarupplevelse. De flesta problem hamnar i några få kategorier: trasiga länkar, förlorad metadata, försummade omdirigeringar och förbisedda prestandadippar.

Trasiga interna länkar är det mest uppenbara. Bolt-rutter bygger ofta på klientbaserad navigation, och det är lätt att missa skillnader i relativa sökvägar när du går över till statisk hosting. Under migreringen bör du granska dina länkar och se till att de pekar på kanoniska URL:er, med absoluta sökvägar där det är lämpligt. En länkgranskare före lansering kan fånga upp saknade sidor eller stavfel som annars skulle ge 404:or. Om du arbetar med Hugo eller en annan generator, verifiera att utdatakatalogens struktur matchar dina förväntningar.

Förlust av metadata är mer subtilt men lika viktigt. Om din Bolt-prototyp använde inbyggda titlar och beskrivningar eller dynamiska SEO-bibliotek kan du förlora dem när du byter ramverk. Bevara sidspecifik metadata medvetet under ombyggnaden. För varje route du identifierade tidigare ska du föra över eller skriva om title-taggen, metabeskrivningen och eventuella Open Graph-taggar som är viktiga för delning i sociala medier. Tjänster som WordPressEscape bygger in det här steget i migreringsprocessen så att varje URL behåller sina SEO-signaler när den underliggande tekniken byts ut.

Omdirigeringar och prestanda är de sista riskzonerna. Det är vanligt att anta att eftersom den nya statiska sajten är snabb lokalt, så är den snabb överallt. I verkligheten behöver du rätt hosting och cache för att behålla prestandan under belastning. På samma sätt, om du inte sätter 301-omdirigeringar från gamla URL:er till nya, ber du sökmotorer och användare att hitta ditt innehåll från början igen. Använd edge-regler för omdirigeringar för att mappa gamla sökvägar till nya med minimal latens, och kontrollera efter lansering att varje viktig URL returnerar 200 eller 301 — inte 404. Övervakningsverktyg och Search Console kan hjälpa dig att upptäcka problem tidigt.

• Trasiga länkar: Använd länkgranskning före lansering för att hitta saknade eller felpekande sidor.
• Metadataluckor: Bevara eller förbättra titlar, beskrivningar och Open Graph-taggar under migreringen.
• Omdirigering och prestanda: Konfigurera 301:or och verifiera global prestanda på den nya statiska hosten.

Vanliga frågor

Ta bort WordPressBehåll dina URL:er + placeringarStatisk · PageSpeed 90+ESC'dashboard-redigerare