web: Portal-Inhalte sind auf dem Hub nicht mehr erreichbar (Anhang 2, E10)

Kategorien, Jahresarchive, Meldungen und Newsrooms liefen auch unter
pressekonto.com — die Ausgabe-Routen gelten für alle Hosts, und der
Portal-Kontext fällt dort auf businessportal24 zurück. Jetzt 301 auf das
Portal.

Meldung und Newsroom folgen ihrem eigenen Portal, nicht einer festen
Vorgabe; bei Doppelveröffentlichung (gleicher Slug auf beiden Portalen)
gewinnt die Erstquelle, sonst endete die Weiterleitung auf der Kopie.
Kategorie, Archiv und Suche gibt es auf beiden Portalen — dort entscheidet
canonical.portal_only_host.

Bewusst nicht weitergeleitet wird ein unbekannter Slug (sonst 301 in ein
404) und alles, was kein GET ist (ein 301 auf POST verliert die Anfrage —
Newsroom beanspruchen und Share-Zählung laufen weiter). Query-Parameter
bleiben erhalten.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

dev/2026-09-01/umsetzung-protokoll.md

@@ -2057,18 +2057,25 @@ Alle 24 Hub-Adressen und jeder Link der Hub-Startseite geprüft: **alles
 2. **Weiterleitungskette** (behoben): `/de/kontakt` und `/de/ueber-uns`
    zeigten auf `/de`, das auf dem Hub selbst auf `/` weiterleitet — zwei
    Sprünge. Jetzt direkt auf die Startseite des jeweiligen Hosts.
-3. **Portal-Inhalte unter pressekonto.com** (offen, Empfehlung unten):
-   `/de/category/{slug}`, `/de/category/{slug}/archiv/{jahr}` und
-   `/de/press-release/{slug}` sind auf dem Hub erreichbar und rendern das
-   Portal (businessportal24), weil die Ausgabe-Routen für alle Hosts
-   gelten. Ihr Canonical zeigt auf das Portal — sie stehen in keiner
-   Sitemap und werden nicht zusätzlich indexiert. **Empfehlung:** auch
-   diese Routen auf dem Hub per 301 auf businessportal24 legen (dasselbe
-   Portal, das der Hub ohnehin rendert; presseecho-only-Meldungen laufen
-   heute wie danach ins 404). Ein Eintrag in
-   `canonical.portal_only_pages` würde nicht reichen, weil das Ziel dort
-   fest auf presseecho steht — braucht eine eigene Zeile. Nicht ohne
-   Freigabe gemacht, weil es rund 34.000 Adressen betrifft.
+3. **Portal-Inhalte unter pressekonto.com** (behoben am 18.09.2026 nach
+   Freigabe): `/de/category/{slug}`, `/de/category/{slug}/archiv/{jahr}`,
+   `/de/press-release/{slug}`, `/de/newsroom/{slug}` und
+   `/de/newsroom/{slug}/verwalten` waren auf dem Hub erreichbar und
+   renderten das Portal, weil die Ausgabe-Routen für alle Hosts gelten.
+   Jetzt 301 (`canonical.portal_only_content_routes`):
+
+   - **Meldung und Newsroom folgen ihrem eigenen Portal**, nicht einer
+     festen Vorgabe. Bei Doppelveröffentlichung tragen beide Fassungen
+     denselben Slug — dann gewinnt die Erstquelle
+     (`canonical_press_release_id is null`), sonst landete die
+     Weiterleitung auf der Kopie.
+   - Kategorie, Jahresarchiv und Suche gibt es auf beiden Portalen: dort
+     entscheidet `portal_only_host` (presseecho).
+   - **Unbekannter Slug wird nicht weitergeleitet** — sonst entstünde eine
+     301-Kette in ein 404 auf dem Portal. Der Hub antwortet wie bisher 404.
+   - **Nur GET.** Ein 301 auf POST würde die Anfrage verlieren; Newsroom
+     beanspruchen und Share-Zählung laufen weiter.
+   - Query-Parameter bleiben erhalten (`/de/suche?q=…`).
 
 Technischer Nebeneffekt: Der Self-Canonical kommt jetzt aus dem
 tatsächlich aufgerufenen Host (`StaticPageCanonical::selfBase()`) statt aus