Livegang vorbereitet: Checkliste, Weiterleitungen, www-Regel

docs/LIVEGANG.md trennt, was geprueft ist, von dem, was nur auf dem
echten Hosting geprueft werden kann - Mailversand, HTTPS, MySQL,
Cronjobs, Rechtstexte - und nennt die Reihenfolge am Umzugstag.

Fuer den Nachbau sind 14 Weiterleitungen von den alten
WordPress-Adressen auf die neuen angelegt; ohne sie haette jede bei
Google stehende Adresse nach dem Umzug mit 404 geantwortet. Die
Datenschutzerklaerung nennt jetzt die Tatsachen: Schriften vom eigenen
Server, kein Google Maps, kein reCAPTCHA.

In der .htaccess steht die www-Umleitung vorbereitet und
auskommentiert, mit dem Hinweis, dass sie zu SITE_ORIGIN passen muss.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/LIVEGANG.md

@@ -0,0 +1,43 @@
+# Livegang von kant-it.de
+
+Stand: 13.09.2026. Diese Liste trennt, was **geprüft ist**, von dem, was **nur auf dem echten Hosting geprüft werden kann** – und in welcher Reihenfolge umgeschaltet wird.
+
+## Geprüft (lokal, gegen den Nachbau)
+
+| Prüfung | Ergebnis |
+| --- | --- |
+| PHPUnit, PHP 8.2 und 8.4 | 409 Tests, 1791 Zusicherungen, grün |
+| JavaScript-Modelltests | grün |
+| Editor durchgespielt (Playwright + axe) | grün, isolierte Datenbank |
+| Öffentliche Seiten (Playwright + axe, 1440 px und 390 px) | keine Beanstandung |
+| Interne Verweise (`npm run test:links`) | 35 Seiten, 408 Adressen, kein toter Verweis |
+| Lighthouse, vier Adressen, je drei Läufe | Barrierefreiheit, Best Practices, SEO, agentic browsing **100** überall; Performance 100 außer Startseite (98 mobil / 96 Desktop) |
+| Sicherung (`cms:backup`) | angelegt: 33 Seiten, 100 Fassungen, 388 Mediendateien |
+| Weiterleitungen der alten WordPress-Adressen | 14 Stück angelegt, alle beantwortet mit 301 |
+
+Gemessen wurde im Produktionsmodus auf dem PHP-Entwicklungsserver, der dieselben Kopfzeilen sendet wie `public/.htaccess`. **Das ist kein Ersatz für eine Messung auf dem echten Hosting.**
+
+## Nicht geprüft – muss vor dem Umschalten passieren
+
+1. **E-Mail-Versand.** Nie ausgeführt, in keiner Umgebung. `MAILER_DSN=sendmail://default` funktioniert auf den meisten PHP-Hostings; verlangt der Anbieter SMTP, gehört dort eine Zeile der Form `smtp://benutzer:passwort@mailserver:587` hinein. **Nach dem Hochladen eine echte Anfrage über das Kontaktformular abschicken und prüfen, ob sie ankommt** – auch im Spam-Ordner. Die Anfrage wird vor dem Versand gespeichert; kommt keine Mail an, steht sie trotzdem unter „Formulare“ in der Verwaltung.
+2. **HTTPS.** Zertifikat einrichten, dann in `public/.htaccess` die drei Zeilen der HTTPS-Umleitung einschalten. **Erst wenn das eine Weile läuft**, die HSTS-Zeile aktivieren – sie lässt sich in einem Browser ein halbes Jahr lang nicht zurücknehmen.
+3. **www oder nicht.** Das alte kant-it.de ist kanonisch mit `www`. In `.htaccess` steht die Umleitung dafür vorbereitet und auskommentiert; sie muss zur Einstellung `SITE_ORIGIN` passen, die in `.env` steht. Beide zeigen auf dieselbe Schreibweise, sonst zeigt jede Seite auf eine Adresse, die weiterleitet.
+4. **Datenbank.** Geprüft ist ausschließlich SQLite. Für MySQL ist alles vorbereitet, aber nichts erprobt – wer MySQL nimmt, sollte danach Seiten anlegen, veröffentlichen, Bilder hochladen und ein Formular absenden.
+5. **Cronjobs.** Täglich `php bin/console cms:backup` und `php bin/console cms:stats:prune`. Ohne den ersten gibt es keine Sicherung außer der von Hand angelegten.
+6. **Schriften.** Auf dem neuen Server einmal `php bin/console cms:fonts:fetch` ausführen oder im Designbereich den Knopf drücken – die Dateien liegen nicht im Repository. Bis dahin lädt die Seite die Schriften von Google, was sie nicht soll.
+7. **Rechtstexte.** Impressum und Datenschutzerklärung sind vom alten Auftritt übernommen. Der Abschnitt über Google Fonts wurde an die Wirklichkeit angepasst (die Schriften kommen jetzt vom eigenen Server), die Abschnitte über Google Maps und reCAPTCHA entfernt, weil beides nicht eingebunden ist. **Das ersetzt keine anwaltliche Prüfung**, und es ist die Verantwortung des Betreibers, nicht des CMS.
+8. **Texte.** Acht Projektbeschreibungen stammen nicht vom alten Auftritt, sondern sind neu geschrieben. Sie sollten gelesen werden, bevor sie öffentlich sind.
+
+## Reihenfolge am Umzugstag
+
+1. Dateien auf das Hosting, `.env` mit `APP_ENV=prod`, `APP_DEBUG=0`, `DATABASE_URL`, `MEDIA_DIRECTORY`, `SITE_ORIGIN`, `MAILER_DSN` und einem neuen `APP_SECRET`.
+2. Datenbank und Medienordner einspielen (oder `php vendor/bin/doctrine-migrations migrate` auf einer leeren Datenbank und dann der Installer).
+3. `php bin/console cms:fonts:fetch`, danach eine Seite aufrufen und im Quelltext prüfen, dass nichts von `fonts.googleapis.com` geladen wird.
+4. Kontaktformular abschicken, Mail prüfen.
+5. **Jetzt erst** die Domain umstellen.
+6. Danach: `CMS_URL=https://www.kant-it.de npm run test:links` von einem Rechner mit Node, `robots.txt` und `sitemap.xml` im Browser aufrufen, die Sitemap in der Google Search Console neu einreichen, und drei bis vier alte Adressen von Hand aufrufen (etwa `/productsolutions/`, `/kanttresor-dsgvo-konforme-archivierung-fuer-moderne-unternehmen/`) – sie müssen mit 301 auf die neue Adresse führen.
+7. Eine Woche lang in der Search Console auf 404-Meldungen schauen; jede weitere alte Adresse bekommt eine Weiterleitung unter „Einstellungen → Weiterleitungen“.
+
+## Rückweg
+
+Das alte WordPress bleibt bis auf Weiteres bestehen. Geht etwas schief, wird die Domain dorthin zurückgestellt; die Inhalte des neuen Auftritts liegen unverändert in der Sicherung unter `var/backups/`.

docs/STATUS.md

@@ -4,6 +4,8 @@ Stand: 12.09.2026. Das System heißt **KantSites** (vorher Arbeitstitel „Kant
 
 Erster Commit angelegt (`82b0782`); das Projekt hat damit einen Rückfallpunkt. Noch kein Remote und kein Push.
 
+**Für den Livegang vorbereitet (13.09.2026):** `docs/LIVEGANG.md` trennt, was geprüft ist, von dem, was nur auf dem echten Hosting geprüft werden kann, und nennt die Reihenfolge am Umzugstag. **14 Weiterleitungen** von den alten WordPress-Adressen auf die neuen sind angelegt und beantwortet (`/productsolutions` → `/projekte`, die gekürzten Beitragsadressen, `/category/allgemein`); ohne sie hätte jede bei Google stehende Adresse nach dem Umzug mit 404 geantwortet. In der Datenschutzerklärung wurde der Abschnitt über Google Fonts an die Wirklichkeit angepasst (die Schriften kommen jetzt vom eigenen Server) und die Abschnitte über Google Maps und reCAPTCHA entfernt, weil beides nicht eingebunden ist – eine Erklärung, die Datenflüsse beschreibt, die es nicht gibt, ist so falsch wie eine, die welche verschweigt. **Nicht geprüft und nicht prüfbar von hier: der E-Mail-Versand.**
+
 **Vom Original übernommen (13.09.2026):** die Meta-Beschreibung der Startseite im Wortlaut von kant-it.de, das Symbol der Website (dort 192 × 192) und die Bot-Regeln der robots.txt. Titel, Canonical, Open Graph, strukturierte Daten (`LocalBusiness` statt Yoasts `ProfessionalService`), Sitemap, robots.txt und `llms.txt` entstehen in KantSites aus dem Inhalt und stimmen mit dem Original überein. **Beim Abgleich aufgefallen:** das `og:image` des echten kant-it.de zeigt auf `wp-content/uploads/kant-it-share.png` – die Datei antwortet mit 404, beim Teilen erscheint dort also kein Bild.
 
 **Im Nachbau von kant-it.de gefunden und behoben:** vier tote Verweise im Hero-Slider – die Adressen waren im Aufbauskript von Hand geschrieben, die Beiträge bekamen längere. Sie werden jetzt aus derselben Regel abgeleitet, mit der die Beiträge entstehen, und ein zweiter Lauf des Skripts aktualisiert vorhandene Seiten, statt sie zu überspringen. Eine Prüfung aller internen Verweise auf 404 gibt es im CMS noch nicht; gefunden wurden sie mit einem einmaligen Durchlauf im Browser.

public/.htaccess

@@ -14,6 +14,14 @@ RewriteRule ^ index.php [L]
 #RewriteCond %{HTTP:X-Forwarded-Proto} !=https
 #RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
 
+# Eine Domain, eine Adresse. Ohne diese Umleitung ist dieselbe Seite unter www und ohne www
+# erreichbar - zwei Adressen fuer denselben Inhalt, und Suchmaschinen muessen raten, welche gilt.
+# Die Richtung muss zu SITE_ORIGIN passen; hier die Fassung "immer mit www".
+#RewriteCond %{HTTP_HOST} !^www\. [NC]
+#RewriteCond %{HTTP_HOST} !^localhost [NC]
+#RewriteCond %{HTTP_HOST} !^127\.0\.0\.1 [NC]
+#RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
+
 # Uebertragen wird komprimiert. HTML, CSS, JavaScript und XML schrumpfen dabei auf etwa ein
 # Viertel; Bilder und Schriften sind bereits komprimiert und bleiben aussen vor.
 <IfModule mod_deflate.c>