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
- →JAMstack-Auslieferung über CDN (Netlify)
- →SEO-URL-Parität gegen die alten WP-Sitemaps
- →Yoast-Titel und -Descriptions zu 100 % in Sanity übernehmen
- →Redaktion im eingebetteten Studio unter
/studio - →Deploy-Trennung: Production auf
master, Staging aufpreview - →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.
| Baustein | Rolle | Details |
|---|---|---|
| Next.js 15 App Router | Frontend | Catch-all für Sanity-Dokumente, dedicated Service-Routes |
| Sanity (Free) | Headless CMS | post, page, service inkl. SEO-Felder und Bilder |
| Netlify + @netlify/plugin-nextjs | Hosting / CDN | Apex + www, Branch-Deploys |
| GitHub | Repo / CI | Production = master, Staging = Branch preview |
| Revalidation | Cache | Sanity-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-Balancer75.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.
| Kategorie | Mobil | Desktop |
|---|---|---|
| Leistung | 92 | 100 |
| Barrierefreiheit | 100 | 100 |
| Best Practices | 100 | 100 |
| SEO | 100 | 100 |
| Agentisches Browsing | 3/3 | 3/3 |
Weitere Belege:
| Claim | Zahl / Beleg |
|---|---|
| URL-Parität | 60/60 Posts, 25/25 Pages (Sitemap-Check) |
| SEO-Meta | Yoast → Sanity 100 % |
| Sicherheit | kein WP-Login mehr (/wp-login.php → 404) |
| Stack | Next.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
- →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.
- →Branch-Rollen. Production nur auf
master. Staging sichtbar über Branch-Deploypreview. Andere Branches im Build überspringen spart Netlify-Credits. - →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.
