Unsere neue Webseite: In 2 Tagen von WordPress zu Hugo mit KI

Was als Experiment begann, wurde zum produktiven Relaunch

Am 16. Januar 2026 starteten wir ein Experiment: Kann Claude 4.5 Opus unsere veraltete WordPress-Webseite durch einen modernen Hugo Static Site Generator ersetzen? Zwei Tage später, am 18. Januar, ging die neue Seite live. Was wir dabei gelernt haben, teilen wir in diesem Artikel.

Die Ausgangssituation: WordPress an seinen Grenzen

Unsere alte WordPress-Webseite funktionierte. Aber:

• Performance: Ladezeiten von 4-5 Sekunden
• Wartung: CMS-Updates, Plugin-Konflikte, Sicherheitspatches
• SEO: Suboptimale Core Web Vitals
• Mehrsprachigkeit: Manuelle Übersetzungen mit hohem Pflegeaufwand

Wir hatten schon lange einen Relaunch auf der Liste. Aber wie immer: Das Tagesgeschäft hatte Priorität.

Der Wendepunkt: Claude 4.5 Opus und OpenCode

Dann kam Claude 4.5 Opus mit erweiterten Coding-Fähigkeiten. Wir wollten testen, wie gut der AI-Agent eine komplette Webseite bauen kann.

Das Setup:

• Basis: Hugo Extended Static Site Generator
• Theme: Blowfish (spezialisiert auf Corporate Sites)
• AI-Tool: Claude 4.5 Opus mit OpenCode
• Budget: Claude lief über unser GitHub Copilot Business Abo
• Zeitrahmen: 16.01. Kick-off → 18.01. Go-Live

Was Claude mit OpenCode übernommen hat

OpenCode hat im Sparring mit Tobias sowohl das Planning als auch die Umsetzung übernommen:

1. Migration aller Inhalte von WordPress zu Hugo Markdown
2. SEO-Redirects: Automatische Suche alter URLs in Google + Redirect-Setup
3. Mehrsprachigkeit: Übersetzung aller Inhalte DE ↔ EN
4. Bildoptimierung: Konvertierung und Komprimierung
5. Template-Anpassungen: Custom Layouts für References, Jobs, Blog
6. Deployment: Kubernetes-Config für GKE mit Google CDN

Was wir gemacht haben

• Product Owner: Tobias hat Anforderungen beschrieben und priorisiert
• Sparring-Partner: Iteratives Feedback und Design-Entscheidungen
• Infrastruktur-Decisions: GKE statt Strato, CDN-Setup
• Prozess-Design: GitHub Actions Workflows, Issue Templates

Realität: Claude hat zwar den Code geschrieben, aber wir haben den Prozess intensiv begleitet. Der Aufwand war dennoch deutlich geringer als ein klassischer Rewrite.

Die Ergebnisse: Zahlen, die überzeugen

Performance-Explosion

Die realen Messwerte aus Google PageSpeed Insights (18. Januar 2026):

Vorher vs. Nachher:

Der echte Mehrwert: Einfache Verwaltung

Die Performance-Zahlen sind beeindruckend, aber der eigentliche Gewinn liegt woanders:

Schluss mit Plugin-Chaos

WordPress lebt von Plugins. Und stirbt an ihnen. Nach jedem Update die bange Frage: Funktioniert noch alles? Bei Hugo gibt es keine Plugins, die plötzlich inkompatibel sind. Der gesamte Code liegt im Repository, versioniert und nachvollziehbar.

Automatische Übersetzungen

Neue Inhalte werden automatisch in DE und EN erstellt. GitHub Copilot übersetzt direkt beim Erstellen des Pull Requests. Keine manuellen Übersetzungen mehr, keine vergessenen Sprachversionen.

Klarer Prozess über GitHub Issues

Content-Erstellung folgt jetzt einem definierten Workflow:

1. Issue mit Template erstellen (Blog, Job, Referenz)
2. Copilot generiert Markdown + Übersetzung
3. Review im Pull Request
4. Merge → automatisches Deployment

Jeder im Team versteht den Prozess. Keine Schulung für ein CMS-Backend nötig.

Patches ohne Risiko

Änderungen laufen über Pull Requests. Staging-Preview vor dem Go-Live. Rollback per Git Revert in Sekunden. Bei WordPress war jedes Update ein Risiko.

SEO: Keine Rankings verloren

Claude hat alle alten WordPress-URLs in Google gesucht und automatisch Redirects erstellt. Dabei kommen zwei Mechanismen zum Einsatz:

1. Hugo Aliases für einzelne Artikel

Alte WordPress-URLs werden direkt im Frontmatter des Artikels definiert:

# content/blog/119-chatgpt-cloud-kosten.md
---
title: "ChatGPT: Die Cloud Kosten des berühmtesten AI Sprachmodells"
aliases:
  - /artificial-intelligence/was-kostet-der-cloudbetrieb-von-chatgpt/
---

Der Artikel /artificial-intelligence/was-kostet-der-cloudbetrieb-von-chatgpt/ hat nach wie vor ein extrem gutes Google-Ranking, obwohl die URL jetzt intern auf /de/blog/119-... zeigt.

2. Nginx Redirects für strukturelle Änderungen

Für Kategorien, Sprachpräfixe und allgemeine URL-Patterns verwenden wir nginx:

# Beispiel aus nginx-live.conf
location ~ ^/category/news/?$ { return 301 /de/blog/; }
location ~ ^/author/(.*)$ { return 301 /de/authors/$1; }
location = /karriere/ { return 301 /de/karriere/; }

Das Ergebnis: Kein Einbruch im Ranking, alle Backlinks funktionieren weiter.

Die neue Architektur: Static Site + Go API

Frontend: Hugo Static Site Generator

# Hugo Build in GitHub Actions
- name: Build Hugo
  run: hugo --minify --environment production
  
- name: Deploy to GKE
  run: |
    kubectl apply -f k8s/deployment.yml
    kubectl rollout status deployment/innfactory-web

Vorteile:

• Keine Datenbank, kein PHP
• HTML wird zur Build-Zeit generiert
• Extrem schnell, extrem sicher
• Versionierung via Git

Backend: Go API für dynamische Inhalte

Für das Kontaktformular und Analytics haben wir eine schlanke Go API entwickelt. Das Kontaktformular validiert ReCAPTCHA und leitet Anfragen an Slack weiter.

Analytics ohne Cookies:

Statt Google Analytics JS direkt einzubinden, läuft alles über unsere API. Das Frontend sendet Events an die eigene API, diese aggregiert die Daten und sendet sie anonymisiert an Google Analytics.

Vorteil: Kein Cookie-Banner mehr nötig, DSGVO-konform.

Content-Management ohne CMS: GitHub Issues + Copilot

Neue Inhalte erstellen wir jetzt über GitHub Issue Templates:

1. Issue erstellen mit Template (Blog, Case Study, Job)
2. GitHub Copilot übernimmt:
   • Markdown-Datei erstellen (DE + EN)
   • Bilder verarbeiten
   • Interne Links setzen
   • SEO-optimierte Metadaten generieren
3. GitHub Action deployed automatisch auf Staging
4. Review und Merge → Automatischer Produktiv-Deploy

Beispiel-Issue für diesen Blogpost:

### Inhaltstyp
Blogpost

### Inhalt
- WordPress ersetzt
- Claude hat in 2 Tagen die Webseite neu gebaut
- Performance und SEO besser als je zuvor
...

### Autor
tobias-jonas

Copilot generiert daraus:

• content/blog/133-ki-website-rebuild.md (DE)
• content-en/blog/133-ki-website-rebuild.md (EN)
• Passende Bilder und Metadaten

Migration von Strato zu Google Cloud

Von Strato vServer zu GKE:

Warum GKE?

• Reserved Instances bereits vorhanden
• Hochverfügbarkeit über mehrere Zonen
• Google CDN mit Edge-Caching weltweit
• Native Integration mit Cloud Build, Cloud Storage

So funktioniert das Setup

Die Architektur besteht aus drei Schichten: Ingress (Load Balancer), Service und Deployment.

1. Ingress mit Global Load Balancer

Der GKE Ingress erstellt automatisch einen Google Cloud HTTP(S) Load Balancer mit statischer IP:

# k8s/overlays/live/ingress.yml (vereinfacht)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: innfactory-live
  annotations:
    # Statische IP für DNS
    kubernetes.io/ingress.global-static-ip-name: wwwinnfactory-ip-live
    # Managed SSL-Zertifikate
    networking.gke.io/managed-certificates: innfactory-live-cert
    # HTTPS Redirect
    networking.gke.io/v1beta1.FrontendConfig: innfactory-https-redirect
spec:
  rules:
    - host: innfactory.de
      http:
        paths:
          - path: /api/*
            backend:
              service:
                name: innfactory-web-api
          - path: /*
            backend:
              service:
                name: innfactory-website

2. Service mit BackendConfig für CDN

Der Service verbindet Load Balancer mit den Pods und aktiviert Cloud CDN:

# k8s/base/service.yml
apiVersion: v1
kind: Service
metadata:
  name: innfactory-website
  annotations:
    # BackendConfig für CDN und Health Checks
    cloud.google.com/backend-config: '{"default": "innfactory-website-backendconfig"}'
    # Network Endpoint Groups für bessere Performance
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: ClusterIP
  selector:
    app: innfactory-website
  ports:
    - port: 80

3. BackendConfig mit CDN-Caching

# k8s/overlays/live/backendconfig-patch.yml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: innfactory-website-backendconfig
spec:
  cdn:
    enabled: true
    cachePolicy:
      includeHost: true
      includeProtocol: true
      includeQueryString: false
  healthCheck:
    type: HTTP
    requestPath: /health

Wie Google CDN mit dem Load Balancer arbeitet

Der Traffic-Flow sieht so aus:

1. User-Request → Google Edge Location (weltweit 150+ Standorte)
2. Cache Hit? → CDN liefert direkt aus (< 50ms)
3. Cache Miss? → Request geht zum Load Balancer
4. Load Balancer → verteilt auf Nginx-Pods in GKE
5. Response → wird im CDN gecacht für folgende Requests

Das CDN cached basierend auf Cache-Control Headers aus nginx. Statische Assets (CSS, JS, Bilder) werden bis zu einem Jahr gecacht, HTML nur 60 Sekunden. Nach jedem Deployment invalidieren wir den CDN-Cache über die GitHub Action.

Lessons Learned: Was hat funktioniert?

Das lief gut

1. Claude 4.5 Opus mit OpenCode als Code-Generator

• Extrem schnell bei repetitiven Tasks (Markdown-Migration)
• Gute Qualität bei klar definierten Anforderungen
• Spart Entwicklerzeit für Standard-Patterns

2. Hugo als Basis

• Perfekt für Corporate Sites
• Riesiges Theme-Ökosystem
• Build-Zeiten < 5 Sekunden

3. GitHub-basierter Workflow

• Content in Git = volle Versionskontrolle
• Issues als CMS-Ersatz funktioniert
• Entwickler und Marketing arbeiten im gleichen Tool

Das war herausfordernd

1. AI braucht genaue Vorgaben

• Vage Anforderungen → unbefriedigende Ergebnisse
• Iteratives Feedback war essentiell
• Manche Entscheidungen erfordern menschliche Expertise

2. Styling und komplexe Designs

• Initiales Styling ist nicht einfach mit AI
• Komplexe Designs sind derzeit noch schwierig umzusetzen
• Viel Trial-and-Error bei CSS-Anpassungen

3. Vibe Coding braucht Guardrails

• Während des Prozesses wurden gute Inhalte zum Teil wieder entfernt
• Guardrailing für den Content ist extrem wichtig
• Klare Anweisungen, was nicht verändert werden darf

4. Migration ist nie trivial

• WordPress-Inhalte hatten inkonsistente Formate
• Bilder mussten manuell nachbearbeitet werden
• Alte Shortcodes → Hugo Shortcodes

Fazit: MVP-Ansatz auch bei Webseiten

Die Seite ist noch nicht 100% perfekt. Aber wie in der Softwareentwicklung üblich: Wir starten mit einem MVP. Die Performance unserer alten Seite schlägt sie allemal, und der ein oder andere Text wird in den kommenden Wochen noch verbessert.

Was wir gelernt haben:

1. AI verkürzt Entwicklungszeit massiv: aber nur bei guter Führung
2. Product Ownership bleibt menschlich: Claude braucht klare Anweisungen
3. Static Sites sind unterschätzt: nicht jede Webseite braucht ein CMS
4. Git > CMS für tech-affine Teams: volle Kontrolle, keine Vendor Lock-ins
5. Der Prozess ist wichtiger als das Tool: GitHub Issues + Templates schaffen Klarheit

Es wird sich zeigen, wie das langfristig funktioniert. Spannend wird auch, wie sich dynamischer Content entwickelt. Für uns ist das alte monolithische CMS-Modell überholt, da wir keine Anforderungen wie Shop & Co haben.

Bei solchen Use-Cases wird es in Zukunft sehr spannend. Wobei komplexe E-Commerce-Lösungen ja auch heute schon eigentlich ein Softwareprojekt sind und nichts mehr mit klassischem Webdesign zu tun haben. Komplexere UIs und interaktive Inhalte sind mit Static Site Rendering schwieriger, aber nicht unmöglich: KI kann die Komplexität gut managen.

Ausblick: Was kommt als Nächstes?

Wir sammeln jetzt über die nächsten Wochen Erfahrungen mit innfactory.de. Danach werden wir selbiges für innfactory.ai ausführen.

Geplant:

• Automatische Blog-Post-Generierung aus Issue-Stichpunkten
• AI-gestützte Übersetzungen mit Qualitätssicherung
• Automatische Bild-Optimierung und Alt-Text-Generierung
• SEO-Monitoring mit automatischen Verbesserungsvorschlägen

Die Vision: Content-Idee → Issue → AI generiert Artikel → Review → Live

In 12 Monaten schauen wir zurück und bewerten, ob das funktioniert hat.

Wir begleiten Sie auf Ihrer GitOps-Reise

Als Cloud-Partner helfen wir Unternehmen bei der Einführung von GitHub und begleiten sie auf ihrer GitOps- und DevOps-Reise. Von der ersten Strategie bis zur produktiven Umsetzung.

Cloud Reselling aus einer Hand: Google Cloud, Azure, AWS, STACKIT und GitHub können Sie bei uns zentral beziehen. Eine Rechnung, ein Ansprechpartner, gebündeltes Know-how.

Wollen Sie mehr über GitOps, GitHub oder KI erfahren? Sprechen Sie uns oder die innFactory AI Consulting an. Gerne teilen wir unsere Erfahrungen.

Kontaktieren Sie uns für ein unverbindliches Gespräch.