fastsite er en publiseringsmotor, ikke et CMS. Du sender innhold, den produserer fullstendig statisk HTML, committer det per nettsted og lar CDN-en din servere det. Her er hele modellen, fra start til slutt.

1. Du sender kropper, ikke sider

Innhold er HTML kun for kroppen. Du forfatter aldri en fullstendig side — skallet eier krom-elementene, og motoren pakker inn hver kropp i det ved byggetid. Det er fire innganger, og de ender alle på samme sted:

  • REST — POST /api/v1/sites/{site}/content med en API-nøkkel.
  • MCP — verktøyene create_post og create_page, under OAuth-samtykke.
  • Webhooks — en HMAC-signert nyttelast fra et oppstrømssystem, tilordnet et innlegg, en side, medieimport eller komponent.
  • Dashbordet — for når du heller vil bare skrive det selv.

Alle disse veiene kjører den samme sanitisereren: en fast tillatt tag-liste, innebygde stiler fjernes, skript og iframes fjernes. Problemer blir advarsler knyttet til posten — de normaliseres og publiseres, og gjøres aldri om til en mislykket forespørsel. En dårlig innliming skal ikke kunne låse pipelinen din.

2. Skallet eier alt annet

Skallet er et lite tre av Twig-maler, et tokens.css-designsystem og UI-strenger per lokalitet. Det er hele designet til nettstedet, og det er det en AI-agent leser og omskriver via API eller MCP.

Endre et token, og hele nettstedet får nytt tema ved neste bygg. Fordi designet lever på ett sted og innhold alltid bare er en kropp, er det ingen malspredning mellom sider og ingenting å migrere når designet endres.

Skriving til skallet er beskyttet — stibegrensning, en tillatt filtype-liste, en størrelsesgrense — og en mal som ville kaste feil eller mislykkes i revisjonen avvises når du lagrer den, ikke når bygget kjører. Ta et øyeblikksbilde før en risikabel endring; gjenoppretting tar sitt eget øyeblikksbilde først, slik at angringen selv kan angres.

3. Motoren bygger statisk HTML

Ved hvert bygg:

  • Utvider <img data-media-id> til responsiv <picture>-markup — AVIF og WebP i fem bredder, en original-format-reserveløsning, eksplisitte dimensjoner og lazy-loading overalt unntatt det fremhevede bildet, som forhåndslastes i stedet.
  • Rendrer komponenter til statisk markup. React-komponenter server-renderes ved byggetid og resultatet er HTML — rammeverket når aldri nettleseren.
  • Bygger inn minifisert CSS med tokens først, og sender ingen JavaScript i det hele tatt.
  • Skriver et komplett head: tittel, beskrivelse, kanonisk, Open Graph og JSON-LD.
  • Genererer sitemap.xml, robots.txt, llms.txt, cache-headere og omdirigeringer — inkludert en omdirigering som legges til automatisk når en slug endres, slik at gamle lenker fortsetter å fungere.

Bygg er inkrementelle. Et manifest sporer hashen til hver utdatafil, slik at bare det som faktisk er endret skrives, og filer hvis kilde har forsvunnet slettes i stedet for å bli etterlatt foreldreløse.

4. Revisjonen avgjør hva som kan sendes

En perfekt poengsum er ikke noe du jager etter faktum — den håndheves før noe som helst skrives. Hvert bygg kjører en siderevisjon som skiller mellom to typer problemer:

  • Feil blokkerer bygget. En manglende bildedimensjon eller alt-attributt, en ekstern ressurs, et sendt <script>, et stilark over budsjett — dette er pipeline-invarianter, og et bygg som ville bryte én av dem fullføres ikke.
  • Advarsler blokkerer det aldri. Et hoppet over overskriftsnivå, en tung side, en ikke-apex kanonisk, en lenke som ikke er indekserbar — dette er innholdslukt. De rapporteres og siden publiseres likevel.

Skillet er poenget. Motoren nekter å bryte sine egne garantier, og nekter å holde innholdet ditt som gissel over en stilmening.

Det harde målet: 100/100/100/100 på Google PageSpeed for hver publiserte side. Revisjonen er det som holder det løftet ærlig.

5. Den committer og deployer

Publisering er et eksplisitt steg, ikke en bieffekt. Skriving av innhold lagrer det; publisering bygger nettstedet og pusher det. Det betyr at en agent eller et skript kan utarbeide, revidere og klargjøre så mye det vil uten at noe når besøkende.

Når en publisering kjøres, committes utdata til nettstedets git-repository — én commit per publisering — og pushes. Din statiske vert bygger ved push. Cloudflare Pages er det dette nettstedet bruker; alt som overvåker et repository fungerer på samme måte.

Bygg og publiseringer kjøres i en kø, så kallet som utløser ett returnerer umiddelbart og du poller for resultatet. Feil gjentas med backoff i stedet for å forsvinne, og en rekke redigeringer slås sammen til ett enkelt bygg i stedet for ett per endring.

Fordi hver publisering er en commit, er distribusjonshistorikken din også en tilbakerulle-mekanisme. Ingenting dynamisk deployes: ingen kjøretid ved kanten, ingen database tilgjengelig fra internett, og ingen opprinnelsesserver som kan falle under belastning.

Mer enn ett språk

Legg til en lokalitet og motoren oversetter publisert innhold og skallets UI-strenger til den, og bygger deretter på nytt. Primærlokaliteten ligger i roten og hver ekstra får sitt eget undertre, med hreflang-alternativer og x-default koblet opp på tvers av hele klyngen og et nettstedskart per språk.

Oversettelser spores per rad mot hashen til kilden deres, slik at redigering av ett avsnitt oversetter den siden på nytt og ingenting annet. Alt du merker som manuelt oversatt overskrives aldri. En side som ikke har en oversettelse ennå er ganske enkelt fraværende fra det språket — besøkende serveres aldri en side som stille faller tilbake til feil en.

Hurtigstart

  1. Opprett et nettsted og design skallet, eller start fra standard stillaset.
  2. Opprett en API-nøkkel, eller koble til en agent over MCP.
  3. Send et innlegg, og publiser deretter. Se en statisk side dukke opp, committet og live.
  4. Forhåndsvis når som helst uten å deploye — forhåndsvisningsbygget er selvstendig og trenger ingen server.
  5. Legg til en lokalitet og la motoren oversette og sende treet på nytt.

Klar for detaljer? Les REST API-referansen, MCP-referansen eller webhooks-gjennomgangen. Hvis du setter opp en egen motor, start med installasjon.