Next.js-Entwickler in Geneva

Mein Name ist Mariusz Szatkowski. Ich arbeite von Gdynia in Polen aus und seit 2006 mit WordPress. Next.js setze ich dort ein, wo eine Website mehr können muss als ein Theme. Auf dieser Seite geht es um den Fall, in dem sie weniger können darf: Eine Organisation will eine schnelle, wartungsarme Website, für die kein Server mit Programmcode laufen soll. Ich arbeite allein, remote und in Schriftform. Es gibt keine Termine und keine Telefonate, dafür einen schriftlichen Umfang mit Annahmen.

Die Plattform Genève internationale nennt auf ihrer Startseite 42 internationale Organisationen und 497 Nichtregierungsorganisationen (abgerufen am 11. November 2026). Viele Organisationen dieser Art betreiben eine Website, deren Inhalt sich nach festen Abläufen ändert: Jahresbericht, Veranstaltungsliste, Stellenausschreibungen, Publikationen. Für solche Seiten lohnt die Frage, ob dafür überhaupt ein Server laufen muss.

Foto: Pymouss, CC BY-SA 4.0, Wikimedia Commons.

#Was output: ‘export’ tut

Laut der Anleitung zum statischen Export erzeugt next build mit dieser Einstellung eine HTML-Datei pro Route. Die Dateien landen im Ordner out und lassen sich auf jedem Webserver ausliefern, der statische Dateien liefern kann. Die Einstellung steht in der next.config:

// next.config.mjs
export default {
  output: 'export',
  trailingSlash: true,
  images: { unoptimized: true },
}

trailingSlash: true legt jede Route als Ordner mit index.html ab, also termine/index.html statt termine.html. Das macht die Konfiguration des Webservers einfacher. Die Version, mit der ich diese Seite geprüft habe, ist Next.js 16.4.6, laut npm-Registry am 9. November 2026 veröffentlicht.

Ein Export ist keine Notlösung. Die Next.js-Dokumentation beschreibt den Weg ausdrücklich so: Sie starten als statische Website und können später Funktionen dazunehmen, die einen Server brauchen.

#Was im Export funktioniert

Ein Beispiel für eine dynamische Route, die beim Build alle Seiten festlegt:

// app/publikationen/[slug]/page.tsx
export const dynamicParams = false

export function generateStaticParams() {
  return [{ slug: 'jahresbericht' }, { slug: 'positionspapier' }]
}

export default async function Page({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params
  return <h1>{slug}</h1>
}

Ich habe dieses Muster und den Route Handler in einem Testprojekt mit Next.js 16.4.6 gebaut. Der Build erzeugte pro Slug eine Datei index.html in einem eigenen Ordner und eine data.json, wie in der Anleitung beschrieben.

#Was im Export nicht funktioniert

Die Anleitung führt diese Funktionen als nicht unterstützt auf, weil sie einen Node.js-Server oder Logik brauchen, die sich beim Build nicht berechnen lässt. Die mittlere Spalte zeigt, was in meinem Testprojekt mit Next.js 16.4.6 tatsächlich passierte.

Gefährlich sind die Zeilen, in denen der Build grün bleibt. Eine Weiterleitung, die nur in der next.config steht, fehlt auf der fertigen Website, ohne dass ein Fehler auffällt. Deshalb prüfe ich den Export nicht am Exit-Code des Builds, sondern an der Liste im Umfang: jede Adresse, jedes Bild, jedes Formular, auf dem Staging.

#Weiterleitungen, Header und Fehlerseite beim Webserver

Weil next.config hier nichts durchsetzt, liegt die Auslieferung beim Webserver. Die Dokumentation zeigt dafür eine Nginx-Konfiguration mit try_files und einer eigenen Fehlerseite. Für einen Export mit trailingSlash: true sieht eine angepasste Fassung so aus:

server {
  listen 80;
  server_name beispiel.ch;
  root /var/www/out;

  location / {
    try_files $uri $uri/ =404;
  }

  # Alte Adresse aus dem URL-Inventar
  location = /rapport-annuel { return 301 /de/jahresbericht/; }

  error_page 404 /404.html;
  location = /404.html { internal; }
}

Next.js legt beim Export eine 404.html an, die der Webserver als Fehlerseite ausliefern kann. Sicherheitsheader und Cache-Regeln gehören in dieselbe Konfiguration. Bei einem Hoster ohne Nginx-Zugang übernimmt eine .htaccess oder eine Oberfläche des Anbieters diese Aufgabe, entscheidend ist, dass die Liste der Weiterleitungen vor dem Livegang vollständig ist. Wie ich das URL-Inventar bei einem Relaunch aufbaue, steht auf der Seite zur Migration zwischen Next.js und Astro in Genf.

#Bilder ohne Optimierer

Der Bildoptimierer von next/image ist ein Server. Im Export fehlt er. In meinem Testprojekt baute der Standard-Loader trotzdem fehlerfrei, das HTML enthielt aber Adressen der Form /_next/image/?url=..., und der Ordner out hat keinen Pfad _next/image. Auf einem Webserver wären das lauter 404-Antworten. Ein grüner Build beweist also nicht, dass die Bilder ankommen.

Die Dokumentation nennt zwei Wege:

• images: { unoptimized: true }: Die Quelldatei wird unverändert ausgeliefert, ohne Anpassung von Qualität, Grösse oder Format. Die Bilder müssen vorher in passenden Grössen und Formaten vorliegen. Das ist ein Arbeitsschritt vor dem Build, den ich im Umfang festhalte.
• Eigener Loader: images: { loader: 'custom', loaderFile: './my-loader.ts' }. Der Loader baut die Adresse zu einem Bilddienst. Das heisst aber, dass ein Dritter die Bilder ausliefert und die Besucher-Anfragen sieht. Dann gehört er auf die Liste der Auftragsbearbeiter, siehe den Abschnitt zum Hosting.

Als Messlatte für Bilder und Ladezeit dienen nur die offiziellen Core Web Vitals: LCP bis 2,5 s, INP bis 200 ms, CLS bis 0,1. Ich messe auf Ihrem Staging und nenne keine eigenen Bestwerte.

#Formulare ohne Node-Server

Ohne Server Actions braucht ein Kontaktformular einen Empfänger ausserhalb von Next.js. Das kann ein kleines Skript auf Ihrem Hosting sein, ein Dienst Ihrer Wahl oder ein Endpunkt Ihrer Organisation. Die Next.js-Seite bleibt Frontend. Das folgende Formular funktioniert auch ohne JavaScript, weil es einen echten action hat, und meldet mit JavaScript das Ergebnis ohne Neuladen:

'use client'
import { useState, type FormEvent } from 'react'

export default function Kontakt() {
  const [status, setStatus] = useState<'idle' | 'ok' | 'fehler'>('idle')

  async function senden(e: FormEvent<HTMLFormElement>) {
    e.preventDefault()
    const res = await fetch('/kontakt/senden.php', {
      method: 'POST',
      body: new FormData(e.currentTarget),
    })
    setStatus(res.ok ? 'ok' : 'fehler')
  }

  return (
    <form action="/kontakt/senden.php" method="post" onSubmit={senden}>
      <input name="nachricht" required />
      <button>Senden</button>
      {status === 'ok' && <p role="status">Danke, die Nachricht ist angekommen.</p>}
      {status === 'fehler' && <p role="alert">Das hat nicht geklappt.</p>}
    </form>
  )
}

Der Export dieses Formulars baut fehlerfrei und enthält im HTML ein <form action="/kontakt/senden.php" method="post">. Was auf der Empfängerseite passiert, ist nicht mehr Next.js: Eingaben prüfen, Spam abwehren, Nachricht zustellen. Das gehört in den Umfang, mit Angabe, wer den Endpunkt betreibt. Der Pfad /kontakt/senden.php im Beispiel ist ein Platzhalter für Ihren Endpunkt.

#Hosting in der Schweiz oder der EU

Ein Export lässt sich ablegen, wo Dateien liegen können: auf einem klassischen Webhosting, hinter einem Reverse Proxy oder in einem Objektspeicher mit Auslieferung per HTTPS. Die Next.js-Anleitung stellt dafür keine Bedingungen ausser der, dass der Server statische Dateien liefern kann. Damit ist die Wahl des Standorts eine Frage des Datenschutzes und des Betriebs, nicht des Frameworks.

Zum Datenschutzgesetz (DSG) gebe ich keine Rechtsberatung. Drei Artikel berühren das Thema technisch:

Eine Bekanntgabe von Personendaten ins Ausland knüpft Art. 16 DSG an Bedingungen: Abs. 1 verlangt einen Entscheid des Bundesrates über angemessenen Schutz, Abs. 2 nennt Ersatzwege wie Standarddatenschutzklauseln. Ob ein Anbieter ausserhalb der Schweiz für Ihre Organisation geeignet ist, bewertet Ihre Rechtsberatung. Ich lege die technische Seite offen: welche Anbieter welche Daten sehen, und in welcher Datei der Pfad dorthin steht.

Das Log des Webservers bleibt in jedem Fall bestehen. Welche Angaben es enthält und wie lange es aufbewahrt wird, legen Sie mit dem Hoster fest.

#Wann der Export die bessere Wahl ist

Bei der letzten Zeile bin ich ehrlich: Eine Seite aus Text und Bildern braucht kein React im Browser. Ein Export liefert die HTML-Dateien, die Next.js zusätzlich für die Navigation im Browser mitgibt. Ich sage Ihnen vor dem Start, wenn Astro oder ein klassisches WordPress der kürzere Weg ist.

#Checkliste vor dem Livegang

• Läuft der Build mit output: 'export' ohne Warnungen zu Redirects, Rewrites, Headers und proxy.ts?
• Ist jede Adresse aus dem URL-Inventar auf dem Staging erreichbar, und leiten die alten Adressen weiter?
• Laden alle Bilder, und stammt keine Adresse aus /_next/image/?
• Erreicht jedes Formular seinen Empfänger, und wer betreibt den Endpunkt?
• Wer löst den Build aus, wenn sich ein Inhalt ändert, und wer lädt die Dateien hoch?
• Stehen Hoster, Formular-Empfänger und mögliche Bilddienste auf der Liste der Auftragsbearbeiter?
• Liefert der Webserver die 404.html mit dem Statuscode 404?

#So läuft ein Auftrag aus Genf bei mir

1. Ihre Beschreibung. Ziel, bestehende Website, Wunschtermin, vorgesehenes Hosting.
2. Meine Rückfragen, schriftlich. Welche Funktionen brauchen einen Server, wer empfängt die Formulare, wie oft ändern sich Inhalte.
3. Umfang mit Annahmen. Was gebaut wird, was nicht, wer den Build auslöst, wer den Endpunkt betreibt. Ich baue erst nach Ihrer schriftlichen Bestätigung, was nicht im Umfang steht, schätze ich getrennt.
4. Staging. Der Export läuft zuerst unter einer geschützten Adresse auf derselben Art Hosting wie später die Produktion.
5. Abnahme gegen die Liste im Umfang: Adressen, Weiterleitungen, Bilder, Formulare, Fehlerseite.
6. Betrieb, wenn Sie möchten. Updates der Abhängigkeiten auf Staging geprüft, Backups ausserhalb des Hostings, schriftliche Notiz zu jeder Änderung.

#Was Sie mitbringen

#Verwandte Seiten für Genf

• Astro in Genf, für Inhaltsseiten, die kaum Interaktion brauchen.
• Migration zwischen Next.js und Astro in Genf, wenn eine bestehende Seite das falsche Werkzeug nutzt.
• PHP-Entwicklung in Genf, wenn ein Endpunkt für Formulare oder Daten in PHP entstehen soll.
• Wartung und Support in Genf, für den Betrieb nach dem Start.

#Häufige Fragen zum statischen Export

#Läuft eine Next.js-Website auch auf einem normalen Webhosting ohne Node?

Ja, wenn sie als statischer Export gebaut wird. Mit output: 'export' erzeugt next build einen Ordner out mit HTML, CSS und JavaScript. Die Next.js-Dokumentation sagt, dass sich der Export auf jedem Webserver ausliefern lässt, der statische Dateien ausliefert. Vorher kläre ich schriftlich mit Ihnen, welche Funktionen Sie brauchen, denn einige gehen im Export nicht.

#Funktionieren Server Actions im statischen Export?

Nein. Server Actions stehen in der Liste der nicht unterstützten Funktionen, und ein Build mit einer Server Action bricht ab. Ein Kontaktformular läuft stattdessen über einen Endpunkt ausserhalb von Next.js, etwa ein kleines Skript auf Ihrem Hosting oder einen Dienst, den Sie ausgewählt haben.

#Warum fehlen nach dem Export meine Bilder?

Vermutlich nutzt next/image den Standard-Loader. In einem Testprojekt mit Next.js 16.4.6 lief der Build damit ohne Fehler durch, im HTML standen aber Adressen unter /_next/image/, die im Ordner out nicht existieren. Abhilfe ist images: { unoptimized: true } mit vorab vorbereiteten Bildern oder ein eigener Loader.

#Bleiben alte Adressen nach dem Relaunch erreichbar?

Ja, aber nicht über Next.js. Weiterleitungen, Rewrites und Header in next.config werden beim Export nicht angewendet, der Build warnt nur. Die Weiterleitungen gehören in die Konfiguration des Webservers, und ich liste sie vor dem Livegang aus Ihrem URL-Inventar.

#Wie kommen Änderungen der Redaktion auf die Website?

Jede Änderung heisst neu bauen und die Dateien ersetzen. Incremental Static Regeneration und Draft Mode gibt es im Export nicht. Wer Inhalte täglich ändert oder Entwürfe im Browser prüfen will, braucht einen Server und damit eine andere Betriebsart.

#Gestalten Sie auch das Layout?

Nein. Das Layout kommt von Ihnen oder Ihrer Agentur, ebenso Mockups und Wireframes. Fehlt ein Layout, bekommen Sie von mir eine Tabellenvorlage, in der Sie für jede Ansicht festhalten, welche Elemente wohin gehören. Daraus entsteht das responsive Frontend.

#Ihre Anfrage in einer E-Mail

Planen Sie eine Website für Ihre Organisation oder wollen Sie wissen, ob ein Export für Ihr Vorhaben reicht? Schicken Sie mir über das Kontaktformular die Adresse Ihrer heutigen Website, Ihr Ziel, den Wunschtermin, den vorgesehenen Hoster und die Funktionen, die Sie brauchen. Meine Rückfragen und die erste Schätzung bekommen Sie schriftlich. Die Schätzung ist kostenlos und unverbindlich.