OLDSCHOOLSEO
CASE STUDY
WordPress zu Jamstack: fitte-tuete.com
Migration von WordPress zu Next.js 15, Sanity und Netlify

Case Study: WordPress (Elementor, Yoast, webgo) zu Next.js 15, Sanity und Netlify. SEO-URL-Parität 60/60 Posts, PageSpeed Mobil 92 / Desktop 100.

Case Study: WordPress zu Jamstack für fitte-tuete.com
✓

PageSpeed Mobil 92 / Desktop 100

✓

URL-Parität 60/60 Posts, 25/25 Pages

✓

Yoast→Sanity SEO-Meta 100 %

✓

Stack: Next.js 15, Sanity, Netlify

✓Von OLDSCHOOLSEO
|Veröffentlicht: 5. Oktober 2026

Case Study Website: WordPress zu Jamstack für fitte-tuete.com

Am 5. Oktober 2026 zeigte Google PageSpeed Insights für die Live-Startseite von fitte-tuete.com mobil 92 und Desktop 100 Leistungspunkte. Wir haben die Markenwebsite Fitte Tüte von WordPress (Elementor, Yoast, webgo) auf Next.js 15, Sanity und Netlify umgezogen. URL-Parität und Redirects halten wir. Die Redaktion läuft ohne Plugin-Wartung.

Über das Projekt

Fitte Tüte ist die Content- und SEO-Marke von OLDSCHOOLSEO. Die Website lief auf WordPress bei webgo: Elementor fürs Layout, Yoast für Metadaten, dazu Plugin-Abos und Serverwartung.

Auftrag: Domain behalten, E-Mail (Gmail über MX) unberührt lassen, alle indexierbaren URLs weiter erreichbar machen oder bewusst umleiten, CMS ohne Plugin-Wartung, CI in Orange und Schwarz.

Herausforderung

WordPress trug Plugin-Last und Hosting-Aufwand. Complianz Premium und Elementor Pro (abgelaufen) standen im Abo-Audit. Jedes Update gefährdete Sicherheit und Layout.

Die Domain blieb bei webgo DNS. E-Mail lief über Gmail. MX- und NS-Einträge durften sich nicht ändern. Content-Typen mischten sich: Magazin-Posts, statische Pages und Leistungsseiten mit eigenen Routen.

Ziele

  1. →JAMstack-Auslieferung über CDN (Netlify)
  2. →SEO-URL-Parität gegen die alten WP-Sitemaps
  3. →Yoast-Titel und -Descriptions zu 100 % in Sanity übernehmen
  4. →Redaktion im eingebetteten Studio unter /studio
  5. →Deploy-Trennung: Production auf master, Staging auf preview
  6. →Cutover ohne Mail-Ausfall

Architekturentscheidung und Tech-Stack

Wir trennten Frontend, Inhalte und Hosting. Next.js rendert die Seiten. Sanity liefert Posts, Pages und Services. Netlify baut und liefert über CDN. GitHub speichert Code und steuert Deploys. Ein Design-System hält Fonts und die Orange-Schwarz-CI fest.

BausteinRolleDetails
Next.js 15 App RouterFrontendCatch-all für Sanity-Dokumente, dedicated Service-Routes
Sanity (Free)Headless CMSpost, page, service inkl. SEO-Felder und Bilder
Netlify + @netlify/plugin-nextjsHosting / CDNApex + www, Branch-Deploys
GitHubRepo / CIProduction = master, Staging = Branch preview
RevalidationCacheSanity-Webhook → /api/revalidate, Fallback 24 h

ISR und Tag-Cache halten Inhalte frisch. Ein Publish im Studio triggert On-demand-Revalidation auf Tags und Paths für post, page, service sowie Magazin und Home. Feature-Arbeit läuft auf preview. Der Merge nach master geht live. Andere Branches überspringt der Build (Netlify-Credits). Env: Sanity Project, Dataset, API-Version und SANITY_REVALIDATE_SECRET.

Mehr zur Leistung: Jamstack-Websites bei OLDSCHOOLSEO. Beispiele im Showroom.

Content-Migration

Vor dem Import legten wir das URL-Inventar aus den WP-Sitemaps (post-sitemap, page-sitemap) an. Coverage-Ziel: jede indexierbare URL bleibt erreichbar oder bekommt bewusst einen 301.

Quelle war die Live-WP-API (WP_BASE), ohne Dump. Ein Import-Skript zog Posts, Pages und Services inkl. Slugs, Excerpts und Daten.

HTML ging nach Portable Text (html-to-blocks): Überschriften, Listen, Links, Blockquotes und Bilder. Tabellen und Code-Blöcke folgen später. Yoast-Felder landeten in seoTitle und seoDescription (Abdeckung 100 %). Featured Images und Medien zogen wir nach Sanity Assets. Tote WP-Bild-URLs bereinigten wir.

Nacharbeit: Autoren nachziehen, Taxonomie (SEO, Content, KI, Leben), Audio- und NotebookLM-Reste entfernen, Stichproben zur Zeichenparität im Body. Checkpoints im Repo: check-url-coverage, check-sitemap-coverage, check-seo-metadata, image-stats.

Coverage-Check gegen Live-WP-Sitemaps: 60/60 Posts, 25/25 Pages.

Frontend-seitig fängt [...slug] Sanity-Dokumente ab. Dedicated Service-Routes (Texterstellung, Content Template, Regionale SEO, Retainer, Freelancer, White Label, Leistungen, Referenzen, Über-uns, Magazin) überschreiben Sanity-Slugs. Das Magazin hat Index, Pagination, Topic-Hubs unter /magazin/[topic], text-first Karten und Detailseiten mit Autor und dateModified.

SEO-Parität und Redirects

Die Redirect-Matrix leiteten wir aus WP-Legacy ab und pflegen sie doppelt: in netlify.toml und in next.config.ts. Netlify und Next müssen dieselbe Matrix kennen.

Mindestens:

  • →/blog* → /magazin
  • →Taxonomien und Feeds → /magazin
  • →Yoast-/WP-Sitemaps → /sitemap.xml
  • →verschachtelte Service-URLs → neue dedicated Paths

Maschinen-SEO: sitemap.ts, robots.ts, llms.txt, JSON-LD (Organization, Person, Article, Breadcrumb). Nav, Footer und CI folgen dem Brand-System inkl. Touch-Targets. Nach jedem Deploy prüften wir 301-Ketten und Coverage gegen die Live-WP-Sitemaps.

Ein Fehlgriff zeigte sich schnell: /white-label-seo als Service und als Guide-Post. Blind-Redirects aus der WP-Zeit hätten den Service auf den Guide gelegt. Dedicated Routes und Smoke-Tests vor Cutover haben das abgefangen.

Cutover DNS

Netlify bekam Apex und www als Custom Domain. Sanity CORS: Apex, www, Netlify-URLs, localhost.

Bei webgo:

  • →A @ → Netlify Load-Balancer 75.2.60.5
  • →CNAME www → Netlify-Hostname
  • →MX, NS und TXT für Mail unverändert

Smoke nach Cutover: HTTPS 200 auf Apex und www. /wp-login.php antwortet 404. Der Revalidate-Webhook zeigt auf https://fitte-tuete.com/api/revalidate. Plugin-Abos stoppten wir sofort. Die Hosting-Kündigung bei webgo folgt zeitversetzt. Die Domain bleibt.

Cutover-Tag: 5. Oktober 2026.

Redaktion danach

Redaktion läuft in Sanity Studio unter /studio (gleiche Origin, CORS gepflegt). Publish oder Update sendet den Webhook an https://fitte-tuete.com/api/revalidate. Die Seite aktualisiert sich ohne Full-Deploy. Script-Imports brauchen einen manuellen Revalidate-Call (HTTP 200 im Smoke-Test).

Weiterentwicklung: Feature auf preview, Release über master. PageSpeed und Lighthouse messen wir auf der Prod-URL. Ein lokaler Lauf allein belegt die Live-Leistung nicht. Offen bleiben FAQ-JSON-LD, visueller Feinschliff und weitere Magazin-Rewrites über NeuronWriter → HTML → Sanity.

Kennzahlen nach Cutover

Quelle: Google PageSpeed Insights · URL https://fitte-tuete.com/ · Bericht 5. Oktober 2026, 15:28:11 (Lab-Daten). CrUX meldete „Keine Daten“ / noch zu wenig Feldmessungen.

KategorieMobilDesktop
Leistung92100
Barrierefreiheit100100
Best Practices100100
SEO100100
Agentisches Browsing3/33/3

Weitere Belege:

ClaimZahl / Beleg
URL-Parität60/60 Posts, 25/25 Pages (Sitemap-Check)
SEO-MetaYoast → Sanity 100 %
Sicherheitkein WP-Login mehr (/wp-login.php → 404)
StackNext.js 15 + Sanity Free + Netlify + GitHub

Vorher-PageSpeed und Euro-Beträge zu Hosting oder Plugins nehmen wir in dieser Fassung nicht als Case-Zahlen. Ausgangslage WordPress bleibt qualitativ: Plugin-Last, Abo-Audit, Serverwartung.

Learnings

  1. →White-Label-Redirect-Falle. Service-URL und Guide-Post teilen Themennamen. Blind-Redirects aus WP-Legacy zerstören die Service-Seite. Dedicated Routes und Smoke-Tests vor Cutover gehören dazu.
  2. →Branch-Rollen. Production nur auf master. Staging sichtbar über Branch-Deploy preview. Andere Branches im Build überspringen spart Netlify-Credits.
  3. →Webhook-Signatur. Sanity liefert t=…,v1=…. Derselbe Secret muss lokal, in Netlify Env und im Sanity-Webhook stehen. Die Webhook-URL zeigt auf die Live-Domain.

Nächster Schritt

Du willst WordPress oder ein schweres CMS ablösen und die SEO-URLs behalten. Wir bauen Jamstack-Websites mit Next.js, Headless CMS und Netlify. Live-Beispiele stehen im Showroom. Die Markenseite selbst: fitte-tuete.com. Die Kundenfassung der Case steht im Magazin: fitte-tuete.com auf Jamstack.

Professionelle Websites und SEO-Optimierung für Unternehmen

Kostenloses Erstgespräch vereinbaren