Hosting nach der Migration — DNS, Edge & Abschaltung

Hosting ist nach dem Stack-Wechsel keine „Serverfrage“ mehr, sondern eine Trennungs- und Cutover-Frage: Welche DNS-Zeilen gehören zur Webseite, welche zur Mail, welche zur Domain-Verifikation — und was darf am alten PHP-Webspace erst abgeschaltet werden, wenn Staging, Redirects und Formulare stabil sind. Dieser Beitrag analysiert Kostenmodell, Sicherheitsfläche, DNS/MX-Trennung, TLS, Edge-Auslieferung und die Abschalt-Checkliste — eingebettet in den Projektablauf von Modern Stack.

Warum PHP-Shared-Hosting nach dem Cutover obsolet wird

Antwort zuerst: Die öffentliche Webseite braucht nach Re-Platforming keine PHP-Laufzeit und keine MySQL-Datenbank auf dem Ursprungsserver mehr — Shared-Hosting-Pakete für WordPress verlieren damit ihren Zweck.

Klassisches Shared Hosting bündelt PHP-Worker, MySQL, FTP, oft cPanel und ein WordPress-One-Click-Setup. Jeder Seitenaufruf trifft (ohne Cache) die App-Schicht; Plugins und Themes erweitern die Angriffsfläche und die Wartungslast. Nach WordPress-Migration und vollständigem Re-Platforming liefert Modern Stack vorkompiliertes oder request-nahes HTML aus dem Next.js-Build — Inhalte aus MDX/Code oder Headless-Quellen, dynamische Teile (Formulare, CRM) über getrennte Dienste wie Convex und Resend, nicht über wp-cron und SMTP-Plugins.

Das bedeutet nicht, dass „Server verschwinden“. Es bedeutet: die öffentliche Origin ist read-mostly und edge-nah; Administrationsflächen wie /wp-admin und /wp-login.php existieren öffentlich nicht mehr. Headless-WordPress als Ausnahme behält PHP hinter Firewall — das ist nicht der Modern-Stack-Default.

Praktisch spürst du den Unterschied so: Deployments kommen aus Git statt aus FTP-Uploads; Previews prüfst du vor dem Go-Live; Rollback ist ein Release zurück, nicht „gestern Abend per FTP überschrieben“. Die Webarchitektur im KI-Zeitalter setzt genau auf diese Entkopplung — Hosting ist dann Auslieferungsschicht, nicht CMS-Gefängnis.

Wie unterscheidet sich das Kostenmodell Shared Hosting vs. Edge/CDN?

Antwort zuerst: Shared Hosting verkauft feste Kapazität und PHP-Features; Edge/CDN verkauft Auslieferung, Builds und Traffic — für Broschüren-Webseiten oft schlanker, weil Plugin- und Patch-Komplexität entfallen.

Vergleich: PHP-Shared vs. Edge/CDN nach Migration

Für mittlere Dienstleister-Webseiten ohne Shop folgt die Kostenkurve nach Cutover typischerweise Traffic und Deployments, nicht der Anzahl installierter Plugins. „Hosting ist immer billiger“ ist trotzdem falsch formuliert: wer massive dynamische Personalisierung oder einen großen Shop betreibt, braucht andere Kapazitätsplanung. Für den Standardpfad Modernisierung (Marketingseiten, Anfragen, GEO-Basis) ist das Betriebsmodell nach Migration vorhersehbarer — siehe Wartung & Updates und Preise & Pakete.

Rechenbeispiel ohne Marketingversprechen: Ein typisches Shared-Paket plus Premium-Cache-, Security- und Backup-Plugins summiert oft laufende Kleinkosten und Arbeitszeit für Updates. Nach Cutover entfallen diese Plugin-Lizenzen und die PHP-Patch-Last; übrig bleiben Plattform-Hosting (häufig im Abo), Domain und Mail. Die sichtbare Rechnung wird kürzer — die echte Einsparung liegt oft in weniger Ausfällen und weniger Notfall-Updates, nicht nur in der Hosting-Zeile der Rechnung.

Was der Census zum Hosting nach Migration sagt

Antwort zuerst: Migration und Hosting-Wechsel entfernen den Legacy-Bottleneck; sie machen dich nicht automatisch „AI-sichtbar“.

In der AI-Readiness-Studie (6.675 Audits) laufen 69,4 % der Sites auf Legacy-CMS. Benchmarks: Agent-Ready Ø 25/100, llms.txt 15,6 %, JSON-LD 41,9 %, Sitemap 73,5 %, robots 72,5 %, Markdown-Negotiation 0,3 %.

Viele dieser Sites hängen an Shared-Hosting-Paketen mit Plugin-Stack. Schnellere Origin und stabile TLS/DNS sind technische Mindestbedingungen für Crawler und generative Engines — zitierfähige Inhalte und Entities kommen danach über GEO & AI-Sichtbarkeit und optional Knowledge Graph. Readiness ≠ Visibility.

Wie trennst du Domain, DNS, MX und Webhosting?

Antwort zuerst: Nur die DNS-Zeilen der Webseite zeigen auf die neue Plattform; MX, SPF, DKIM und Verifikations-TXT bleiben beim bestehenden Mail-/Identitäts-Setup.

Typischer Fehler bei deutschen KMU: Domain, Postfächer und Webspace sitzen in einem Vertrag bei IONOS, Strato, Alfahosting oder ähnlichen Anbietern. Eine unvorbereitete Komplett-Kündigung kann mitreißen:

• MX-Records für info@deine-domain.de
• SPF/DKIM/DMARC für Transaktions- und Newsletter-Mail
• TXT für Google Search Console, Microsoft 365 oder Domain-Ownership
• ggf. Nameserver, wenn der Registrar die Zone hostet

DNS-Rollen klar zuordnen

Vor Cutover dokumentiert Modern Stack im Projektablauf die Zone: Screenshot oder Export aller Records, Owner je Funktion, Rollback-TTL-Plan. Webhosting kündigst du erst, wenn 301-Matrix, Formulare und TLS weltweit grün sind — nicht am Cutover-Freitag 17 Uhr.

Wie läuft Edge-Auslieferung ohne Plattform-Jargon-Dump?

Antwort zuerst: Du brauchst keine Feature-Liste fremder Cloud-Marketingseiten — du brauchst eine klare Auslieferungskette: Build → Edge/CDN → DNS → TLS.

Vercel ist bei Modern Stack der häufige Betriebsort für Next.js — nicht weil „Hype“, sondern weil Deployments, Previews und Edge-nahe HTML-Auslieferung zum Stack passen. Gleichwertig zählt das Muster, nicht der Markenname:

1. Git-Push oder Release erzeugt einen Build.
2. Statische Assets und SSG-Seiten liegen am CDN (CDN).
3. Dynamische Pfade nutzen SSR oder Revalidation nahe am Request (Edge-Rendering, SSR/SSG-Stack).
4. DNS zeigt die Domain auf diese Origin; Zertifikate stellt die Plattform aus.

Was du nicht brauchst: einen Vergleichskatalog aller Edge-Anbieter, Serverless-Buzzwords oder „wir nutzen X weil Cool“. Was zählt für dich als Betreiber: Preview vor Go-Live, Rollback, Logs bei Formularfehlern, globale Erreichbarkeit. Referenzmethode und Vorher/Nachher: Mallorca Expats, Alexandre Liard.

Wie Edge- und CDN-Auslieferung Performance und Core Web Vitals trägt

Antwort zuerst: Edge/CDN senkt Latenz und entlastet die Origin — aber nur sauberes Markup und gezieltes Rendering heben LCP nachhaltig unter die Google-Schwellen.

Core Web Vitals definieren messbare Grenzen: LCP unter 2,5 s gilt als „gut“. Im internen Vergleich Next.js vs WordPress liegen typische WordPress-LCP-Werte bei 2,5–4,0 s, SSG/Edge-Next.js oft bei ~0,8 s. Hosting-Wechsel allein heilt kein Elementor-/Divi-Rauschen — deshalb kommt Content-Migration und Rebuild vor Feintuning unter Core Web Vitals Modernisierung.

Für Crawler und KI-Fetcher gilt: langsame Origins und Timeout-Risiken senken Extraktionschancen. Princeton GEO (Aggarwal et al., arXiv:2311.09735) adressiert inhaltliche Zitierbarkeit — technisch vorausgesetzt ist erreichbares, schnelles HTML. Reihenfolge: Stack + Hosting → Inhalte/Entities → Conversion.

Wie schrumpft die Sicherheitsfläche ohne öffentliches PHP?

Antwort zuerst: Wenn kein PHP-Theme und kein /wp-admin mehr im Internet stehen, entfallen die häufigsten automatisierten Angriffsvektoren des WordPress-Ökosystems.

WordPress ist wegen Marktanteil Dauerziel für Credential-Stuffing, Plugin-RCEs und Theme-Exploits. Shared Hosting multipliziert das Risiko, wenn viele Kunden auf derselben PHP-Maschine sitzen und Admin-Pfade öffentlich erreichbar sind.

Nach Cutover auf dem Modern-Stack-Default:

• keine öffentliche PHP-Ausführung für die Marketing-Webseite
• kein xmlrpc.php, kein Plugin-Update-Endpoint nach außen
• Admin nur noch über Deploy-/CMS-Pipeline mit Zugriffskontrolle
• TLS und Security-Headers zentral an der Edge-Origin

Das ist der härteste Sicherheitshebel der Migration — härter als jedes Security-Plugin im Monolithen. Parallel bleiben Formular- und Datenschutzfragen unter Datenschutz & Formulare relevant; Hosting ersetzt keine Consent- oder Spam-Absicherung.

Was schaltest du nach dem WordPress-Cutover ab?

Antwort zuerst: Nach stabilen Smoke-Tests deprovisionierst du den alten Web-Stack — nicht Domain, nicht Mail, nicht die DNS-Zone als Ganzes.

Abschalten (nach Stabilität)

Bewusst behalten

Parallelbetrieb von Alt- und Neu-Origin länger als nötig erzeugt Ranking- und Cache-Chaos — siehe Rankingverlust vermeiden und Redirect-Pflege unter Redirect.

Wie sicherst du TLS und HTTPS am Cutover?

Antwort zuerst: Zertifikate stellt die neue Origin aus; du prüfst nach DNS-Flip Chain, Redirect HTTP→HTTPS, Mixed Content und www/Apex-Konsistenz.

Praktische Reihenfolge:

1. DNS mit kurzer TTL vorbereiten (Stunden, nicht Wochen).
2. Domain an der neuen Plattform verifizieren; Zertifikat ausstellen lassen.
3. Cutover: A/AAAA/CNAME bzw. ALIAS umstellen.
4. Sofort-Checks: HTTPS ohne Warnung, HTTP→HTTPS, www↔Apex als 308/301 konsistent (kein Ketten-Pingpong).
5. Optional HSTS erst wenn HTTPS überall stabil ist — sonst sperrst du dich bei Fehlkonfiguration aus.
6. CAA-Records prüfen, falls streng gesetzt — Issuer muss zur Plattform passen.

Mixed Content (HTTP-Bilder/Scripts auf HTTPS-Seiten) ist ein typisches Residuum alter WordPress-URLs in Texten — gehört in die Medien-Pipeline der Migration, nicht in den „Freitag-Abend-Fix“. Zertifikatswarnungen nach Cutover sind meist DNS-Propagations- oder CAA-Probleme, selten „die Domain ist kaputt“: Propagation prüfen, alte Origin nicht parallel mit gleichem Hostheader belassen, danach erneut testen.

Technisches SEO nach dem Hosting-Wechsel bleibt Pflichtprogramm unter Modernes Technical SEO und Technical-SEO-Basis: Canonicals, Sitemap-URL, robots und konsistente HTTPS-Canonicals müssen zur neuen Origin passen — sonst indexiert Google Parallelwelten.

Checkliste: Cutover, Monitoring und erste 48 Stunden

Antwort zuerst: Erfolgreiches Hosting nach Migration ist ein Messprogramm — nicht nur ein DNS-Klick.

1. Zone-Export und Rollenmatrix (Web / Mail / Verifikation) vollständig.
2. Staging: Top-20-URLs, Formular-E2E, Mobile-LCP-Stichprobe.
3. 301-Matrix ohne Soft-404 und ohne Redirect-Ketten.
4. DNS-Flip im Wartungsfenster; TLS-Smoke weltweit.
5. Sitemap und robots.txt auf neuer Origin (Census-Baseline Sitemap 73,5 % / robots 72,5 % — Ziel: beides korrekt live).
6. Anfrageformular + Notify an info@modern-stack.de-Pfad des Projekts prüfen.
7. 48-Stunden-Monitoring: Verfügbarkeit, Search Console, Core Web Vitals, 404-Spitzen.
8. Altes PHP erst deprovisionieren, wenn Stabilität bestätigt — Rollback-Zugang bis dahin behalten.

Optional: öffentlicher KI-Sichtbarkeits-Check als Readiness-Stichprobe — nicht als Ranking-Versprechen.

Was kostet Hosting nach der Migration?

Antwort zuerst: Einmalige Basis-Migration ab 500 € (bis 10 Seiten); laufendes Plattform-Hosting oft im Webseiten-Abo 49 €/Monat (12 Monate, keine automatische Verlängerung, Code-Export nach Laufzeit).

Im Basisumfang typisch: Inventar, Rebuild, Redirect-Map im Scope, Staging, Cutover-Begleitung inkl. DNS-Rollenklärung. Außerhalb: Shop, umfangreiche Custom-Logik, Redesign ab 1.000 €, Knowledge Graph ab 500 €, Conversion ab 500 €.

Du administrierst keinen klassischen Webspace. Updates betreffen Stack und Inhalte — nicht vierzig WordPress-Plugins. Preise im Kontext: Preise & Pakete. Architekturrahmen: Webarchitektur im KI-Zeitalter, WordPress im KI-Zeitalter.

Wann darfst du beim alten Hoster bleiben — und was genau?

Antwort zuerst: Registrar und Mail dürfen bleiben; nur der Web-A-Record (bzw. CNAME/ALIAS) zeigt auf die neue Plattform.

Viele Betriebe müssen nicht „alles kündigen, um modern zu werden“. Häufig reicht:

1. DNS-Update der Web-Records auf die Edge-Origin.
2. Mail und Domain unverändert.
3. Nach zwei stabilen Wochen ohne 404-Spitzen: PHP-Webspace und Datenbank abschalten bzw. Tarif auf Domain/Mail reduzieren.

Erst wenn der Hoster Nameserver und Zone so verkoppelt, dass Web-DNS nicht getrennt steuerbar ist, kommt ein kontrollierter Registrar- oder DNS-Umzug — geplant, mit Record-Parität, nie als spontane Vertragsstrafe am Go-Live-Tag.

Kurz: Hosting nach Migration ist Trennungsarbeit — Webseite an den Edge-Stack, Mail und Domain unangetastet, PHP-Schuld bewusst abschalten. Anfrage stellen