presseportale/docs/Echte öffentliche Unterseiten.md

Stand der Doku: 21.05.2026 — diese Liste beschreibt den Zielzustand der oeffentlichen Strecke. Welcher Punkt bereits umgesetzt ist, ist jeweils mit einer kurzen IST-Notiz markiert.

Update 17.06.2026 — Bestands-URL-Mapping (Launch-Vorbereitung). Die komplette URL-Struktur der Altseite (siehe docs/frontend/Struktur Frontend.md) ist jetzt per 301 auf die neue Struktur abgebildet: englische Alt-Slugs (login, contact, imprint, terms, privacypolicy, pricelist, service) → neue deutsche Pfade bzw. Hub, /presse/*-Ratgeber → /faq, presskit/{id}/{slug} → /newsroom/{slug} (Feinmapping über companies.legacy_id, Fallback /newsrooms), entfallene Sprachvarianten de-ch/de-at → /de. Region-Übersichten (/region/{slug}) sind bewusst ein späterer Schritt. Implementierung in routes/web.php; Test: tests/Feature/Web/LegacyRedirectTest.php.

Update 17.06.2026 — Newsrooms. Newsroom-Markenseiten pro Unternehmen (/{edition}/newsroom/{slug}) und das Newsrooms-Verzeichnis (/{edition}/newsrooms) sind im Editorial-Design mit echten Daten umgesetzt (siehe Punkt 4). Neue server-seitige Pagination-Komponente x-web.pagination. Test: tests/Feature/Web/NewsroomPageTest.php.

Update 16.06.2026 — Editorial-Relaunch & Ausgaben-Routing. Die oeffentliche Strecke wurde auf ein gemeinsames Editorial-Design (Komponenten x-web.site-header / x-web.site-footer, Design-Tokens in resources/css/web/shared-styles.css) umgestellt und auf ein Ausgaben-Praefix /{edition}/… (Sprache de | en) gehoben.

• Routing: Neue Middleware app/Http/Middleware/SetEdition.php liest die Ausgabe aus dem ersten URL-Segment, setzt Locale + URL::defaults. routes/web.php gruppiert alle oeffentlichen Routen unter /{edition}. / leitet auf die Default-Ausgabe (/de) um; Legacy-.html-URLs werden per 301 auf die neuen Pfade gemappt. Baseline-Default in AppServiceProvider fuer Route-Generierung ausserhalb von HTTP-Requests.
• Neue URL-Schemata: Detailseite /{edition}/press-release/{slug} (Route release.detail), Kategorie /{edition}/category/{slug} (Route kategorie).
• Ausgabe = Sprache: DE/EN-Umschalter im Header (Region-/CH-/AT-Auswahl entfernt). EditorialClock (app/Support/EditorialClock.php) und die Livewire-Komponenten sind sprachdynamisch.
• Rubriken-Navigation statt Uebersichtsseite: Helper app/Support/CategoryNavigation.php liefert die Top-Rubriken der Ausgabe; Header/Footer verlinken direkt auf die Kategorieseiten. Die alte web/kategorien.blade.php + Route wurden entfernt (Legacy-301).
• Tests: tests/Feature/Web/ deckt Edition-Routing, Kategorie-Seite, Kategorie-Navigation, Detailseite, Veroeffentlichen, Suche und den EditorialClock ab.

Das sind die Seiten, die eigene URLs brauchen, weil sie verlinkbar sein müssen, SEO-Wert haben oder direkt von extern angesteuert werden.

Inhalts-Seiten (Lese-Erfahrung)

1. Pressemitteilungs-Detailseite – /p/[slug] oder /pressemitteilung/[id] Die wichtigste Seite überhaupt. Jede einzelne PM bekommt eine eigene Seite. Hier landen 90% des Traffics aus Google, Newsletter und Social Shares. IST 21.05.2026: umgesetzt als resources/views/web/release-detail.blade.php (Route release.detail, URL /release/{slug}). Das URL-Schema weicht vom Plan ab, ist aber konsistent über alle Themen. IST 16.06.2026: im Editorial-Design neu aufgebaut, echte Daten (Firma, Kontakte, Bilder, verwandte Meldungen). Neue URL /{edition}/press-release/{slug}; Legacy-URLs per 301. Test: tests/Feature/Web/ReleaseDetailTest.php.

2. Branchen-Übersichten – /branche/[slug] Zum Beispiel /branche/energie-klima, /branche/finanzen. Aggregierte Sicht auf alle PMs einer Branche, mit Sub-Filtern. Das sind deine SEO-Goldgruben (jede Branche eine ranking-fähige Landing Page). IST 21.05.2026: umgesetzt (web/kategorie.blade.php, web/kategorien.blade.php). IST 16.06.2026: web/kategorie.blade.php im Editorial-Design mit echten Daten (Top-Meldung, Feed, Sub-/verwandte Branchen, Stats, Newsrooms). Neue URL /{edition}/category/{slug}. Es gibt keine Gesamt-Uebersicht mehr — die Header-/Footer-Navigation fuehrt direkt auf die Rubrik (CategoryNavigation); web/kategorien.blade.php + Route entfernt (Legacy-301). Tests: CategoryPageTest, CategoryNavigationTest.

3. Regionen-Übersichten – /region/[slug] /region/deutschland, /region/bayern, /region/oesterreich. Analog zu Branchen, regional gefiltert. IST 21.05.2026: noch nicht umgesetzt.

4. Newsroom-Seite eines Unternehmens – /newsroom/[slug] Markenseite eines Premium-Publishers mit eigener URL, Logo, allen PMs des Unternehmens. Ist gleichzeitig Verkaufsargument für Pro-/Agency-Tarif und SEO-Vorteil für die Unternehmen. IST 21.05.2026: Layout vorhanden (web/newsrooms.blade.php), Daten-Anbindung pro Firma noch offen. IST 17.06.2026: umgesetzt im Editorial-Design mit echten Daten. Markenseite web/newsroom.blade.php (Route newsroom, URL /{edition}/newsroom/{slug}): Logo/Initiale, Boilerplate, Website, Branchen der Firma, Kennzahlen (gesamt/30 Tage/heute/Aufrufe/seit Jahr), Top-Meldung und paginierte Meldungsliste (x-web.pagination), Sidebar (Meistgelesen, Publisher-CTA). 404 bei unbekanntem Slug oder Firma ohne veröffentlichte Meldung. Zusätzlich Verzeichnis web/newsrooms.blade.php (Route newsrooms, URL /{edition}/newsrooms): Karten-Grid aller aktiven Newsrooms mit Meldungs-/Aktivitätszahlen, Namens-Suche (?q=) und Pagination. x-web.active-newsrooms verlinkt jetzt über route('newsroom', …). Legacy-.html-URLs (/newsrooms.html, /newsroom/{slug}.html) per 301. Test: tests/Feature/Web/NewsroomPageTest.php.

5. Such-Ergebnisseite – /suche?q=... Volltextsuche mit Filtern (Erweiterte Suche schreibt in URL-Parameter, dadurch teilbar/bookmarkbar). IST 21.05.2026: Layout vorhanden (web/suche.blade.php), Volltextsuche noch nicht aktiv. IST 16.06.2026: aktive Suche umgesetzt. web/suche.blade.php im Editorial-Design + Volt-Komponente livewire/web/search.blade.php: Suche ueber Titel/Untertitel/Text/Keywords sowie Firmenname und Rubrik-Name, Rubriken-Filter, Sortierung (Neueste/Aelteste/Meistgelesen), Pagination. URL-Parameter q, category, sort (teilbar/bookmarkbar); portal-/sprachsensitiv. Test: tests/Feature/Web/SearchPageTest.php.

6. Tag-/Themen-Seite – /thema/[slug] (optional, später) Nicht im ersten Release zwingend, aber sehr SEO-wirksam für aktuelle Themen ("Künstliche Intelligenz", "Lieferkettengesetz", "Energiekrise"). Würde ich datengetrieben aus den meistverwendeten Tags generieren lassen. IST 21.05.2026: nicht umgesetzt (bewusst spaeter).

Service-/Vertriebs-Seiten

7. Pressemitteilung einreichen / Veröffentlichen – /veroeffentlichen Die Conversion-Landingpage für neue Publisher. Erklärt Mehrwert, zeigt Tarife, Editor-Vorschau. Dahinter der eigentliche Editor (im User-Bereich). IST 21.05.2026: Landing-Seite vorhanden (web/veroeffentlichen.blade.php). Editor-Strecke im User-Bereich ist umgesetzt (siehe Phase 7). IST 16.06.2026: Landing-Seite im Editorial-Design neu aufgebaut, echte Kennzahlen (Archiv-Gesamt, heute veroeffentlicht/in Pruefung, aktive Newsrooms, Beispiel-Mitteilung). Einreichung verweist auf den zentralen Publisher-Bereich. Test: tests/Feature/Web/VeroeffentlichenPageTest.php.

8. Tarife & Preise – /preise (oder als Modal aus mehreren Stellen aufrufbar) Da Tarife auch im Modal aus dem CTA aufgerufen werden, ist die Frage: brauchen wir die Seite? Antwort ja, weil SEO ("Pressemitteilung veröffentlichen Preise" ist eine wichtige Suche) und weil sie verlinkbar sein muss aus AGB, Footer, Mediadaten. IST 21.05.2026: Layout vorhanden (web/preise.blade.php), echte Tarife noch nicht hinterlegt (Tarif-Modul siehe Presseportal – Konzept für Relaunch.md Abschnitt 8). IST 17.06.2026: Tarife sind jetzt datengetrieben aus dem System (Plan::active()) auf der Startseite als Tarif-Teaser sichtbar (neue Komponente x-web.pricing-teaser, Preis/Quota/Tageslimit/Jahrespreis je Tarif, „Beliebt"-Hervorhebung). Der Preise-Link ist auf jeder Portalseite präsent: in der Header-Utility-Bar (neu) und im Footer („Tarife & Pakete", bestand bereits). Test: tests/Feature/Web/PricingTeaserTest.php. Offen: Die eigentliche /preise-Seite (web/preise.blade.php) ist noch im alten Theme mit Platzhalter-Tarifen — Editorial-Rebuild mit x-web.pricing-teaser/echten Plänen ist der nächste Schritt.

9. Mediadaten / Werbung – /mediadaten oder /werben Für Mediaplaner und potentielle Werbekunden: alle buchbaren Slot-Typen (Top-Slot, Highlights, Newsletter, Branchen-Sponsoring), Reichweiten-Daten, Preise, Booking-Kontakt. Pflicht-Seite für jede Plattform mit Anzeigeninventar. IST 21.05.2026: nicht umgesetzt.

10. Newsletter-Anmeldung als eigene Seite – /newsletter Auch wenn Newsletter im Footer und in einer Sektion auf der Startseite eingebettet ist, brauchst du eine eigene Seite für direkte Anmelde-Links (aus E-Mails, Social, Werbekampagnen). IST 21.05.2026: Layout in den Themes vorhanden, eigene Anmelde-Seite noch nicht.

Vertrauens- / Editorial-Seiten

11. Über uns – /ueber-uns Plattform-Geschichte, Team, redaktionelle Haltung. Kurz und persönlich, kein Marketing-Geschwurbel. IST 21.05.2026: Layout vorhanden (web/ueber-uns.blade.php, web/team.blade.php).

12. Redaktion / Redaktionsrichtlinien – /redaktion Wichtige Vertrauensseite: Wer prüft die Inhalte? Wie funktioniert der Content-Score? Was ist der Unterschied zu redaktionell geprüften Anzeigen? Diese Seite differenziert dich von Spam-Portalen. IST 21.05.2026: noch nicht umgesetzt.

13. Kontakt – /kontakt Klassisch, mit Funktions-E-Mails (presse@, redaktion@, werbung@, support@) und Kontaktformular. IST 21.05.2026: Layout vorhanden (web/kontakt.blade.php).

Rechtliches

14. Impressum – /impressum 15. Datenschutz – /datenschutz 16. AGB – /agb 17. Cookie-Einstellungen – /cookies (oder Modal)

Diese vier sind Pflicht und nicht zusammenfassbar. IST 21.05.2026: alle vier als Layout vorhanden (web/impressum.blade.php, web/datenschutz.blade.php, web/agb.blade.php, web/cookies.blade.php). Inhalte sind teilweise Platzhalter — vor Go-Live durch Anwalt zu pruefen.

Technik / Distribution

18. RSS-Feeds-Übersicht – /feeds Liste aller verfügbaren RSS-Feeds (alle, pro Branche, pro Region). Eine Seite, listet alle Feed-URLs auf. IST 21.05.2026: nicht umgesetzt.

19. API-Dokumentation – /api Für Distribution-Partner und Pro-/Agency-Kunden mit API-Zugang. IST 21.05.2026: Seite vorhanden (web/api.blade.php). Pre-existing ApiDocumentationTest ist rot, weil docs/api/v1.yml noch fehlt — eigener Track.

DSA-/Rechts-Pflichten

20. PM melden – /melden/[id] Öffentlicher Notice-and-Action-Endpoint, eigener Pfad pro PM (kann auch als Modal von der PM-Detailseite kommen, aber direkter Link für rechtssichere Beschwerden besser). IST 21.05.2026: nicht umgesetzt (Phase 2/3, DSA-Pflicht).

21. Pressemitteilung verwalten (Magic-Link) – /verwalten Einstiegspunkt für den Pressekontakt-Flow (E-Mail eingeben → Magic Link). Dahinter dann der eingeloggte Verwaltungs-Bereich. IST 21.05.2026: nicht umgesetzt (Phase 2, siehe Presseportal – Konzept für Relaunch.md Abschnitt 6).

---

Was als Modal/Overlay läuft (keine eigene Seite)

Das sind die Sachen, die man oft in einer separaten Seite versteckt sieht, aber besser inline gelöst werden – kein Kontext-Verlust für den User.

• Erweiterte Suche → Modal mit Filtern (URL-Parameter werden trotzdem gesetzt für Teilbarkeit)
• Tarife-Übersicht aus CTAs → Modal (neben der eigenen /preise-Seite)
• Whitepaper-Download mit Lead-Capture → Modal mit Name/E-Mail-Feldern
• Newsletter-Anmeldung aus Sektion → inline ohne Seitenwechsel
• PM melden aus Detailseite → Modal (mit Fallback auf eigene URL)
• Cookie-Einstellungen → Modal (mit Fallback auf eigene URL für Rechtssicherheit)
• Login → Modal (Anmelden-Button öffnet Modal, kein Seitenwechsel; eigene Seite nur als Fallback /login)
• Bild-Lightbox auf PM-Detailseite → Overlay
• Teilen-Funktionen auf PM-Detailseite → Modal mit Plattform-Auswahl und vorgenerierten Texten
• Tarif-Wechsel im User-Bereich → Modal
• Credit-Aufladung → Mini-Checkout-Modal (war im Konzept schon so geplant)

---

Was im eingeloggten User-Bereich liegt

Hier ist wichtig: alles unter einer einzigen Dashboard-URL, nicht 15 Untermenüs. Ein Bereich, mehrere Tabs/Sektionen.

Publisher-Dashboard – /dashboard

IST-Stand 21.05.2026: Im Code heisst der Customer-Bereich /admin/me (Routen-Namen me.*); das Admin-Backend liegt unter /dashboard und ist Editoren/Admins vorbehalten. Die Bereiche im User-Backend sind als eigene Pages mit wire:navigate (kein vollst. Seitenwechsel) umgesetzt und ueber die Sidebar navigierbar. Eine echte Tab-Komponente innerhalb einer einzigen URL gibt es nicht — der Mehrwert ist gleich.

Mit folgenden Bereichen als Tabs oder Sidebar-Navigation (kein Seitenwechsel zwischen den Tabs, oder URL-Tabs wie /dashboard/meldungen):

• Übersicht – Stats, Credit-Stand, letzte Aktivitäten (umgesetzt als customer/dashboard)
• Meine Pressemitteilungen – Liste mit Status, Bearbeiten, Korrektur, Update (umgesetzt als customer/press-releases/{index,show,create,edit})
• Editor – Neue PM erstellen / bestehende bearbeiten (eigene Unter-URL /editor oder /editor/[id]) (umgesetzt als Teil von press-releases.{create,edit})
• Newsroom – Markenseite konfigurieren (für Pro/Agency) (nicht umgesetzt — Phase 2)
• Statistiken – Detail-Auswertungen pro PM (nicht umgesetzt — Phase 2)
• Credits & Rechnungen – Stand, Verlauf, Pakete kaufen, Rechnungen herunterladen (nur Rechnungen umgesetzt; Credits sind Phase 2)
• Tarif & Account – Tarif-Verwaltung, Rechnungsdaten, Team-Mitglieder (für Agency) (Profil + Rechnungsadresse umgesetzt; Tarif/Team Phase 2)
• Boost & Platzierungen – Slot-Buchungen, Verlauf, neue buchen (als Stub vorhanden customer/bookings)

Pressekontakt-Bereich (Magic-Link) – /verwalten/[token]

Vereinfachte Version des Dashboards für nicht-registrierte Pressekontakte:

• Liste der PMs mit dieser E-Mail
• Änderungs-Wizard (Pfade A–G)
• Optional: Account-Anlage für späteren direkten Zugriff

Admin-Bereich – /admin (intern, nicht öffentlich)

Eigene Anwendung im Grunde, aber URL-mäßig unter Hauptdomain:

• Review-Queue (Gelb-PMs, Beschwerden, Persönlichkeitsrecht-Pfad F)
• User-Verwaltung
• Inventar-Management (welche Slots sind gebucht)
• Editorial-Picks setzen
• Reports / Statistiken

---

Strukturelle Faustregeln, die ich anwenden würde

1. Maximal zwei Klicks ab Startseite zu jeder Funktion. Aus Startseite → Branchenseite → PM-Detail. Aus Startseite → Veröffentlichen → Tarif-Auswahl. Wenn etwas drei Klicks braucht, ist es falsch verortet.

2. Footer ist die Sitemap. Alle Service- und Rechts-Seiten leben nur im Footer. Keine Mega-Menüs im Header. Die Hauptnavigation oben ist ausschließlich Branchen-Navigation plus Veröffentlichen-CTA.

3. URL-Schemata konsistent. Singular für Detailseiten (/branche/..., /newsroom/...), Verben für Aktionen (/veroeffentlichen, /melden, /verwalten). Keine kryptischen IDs in URLs, wenn vermeidbar – Slugs für SEO.

4. Modals statt Seiten, wenn möglich. Aber: jeder Modal hat einen Fallback-URL-Endpoint, falls jemand direkt verlinkt oder einen Bookmark setzt. Beispiel: Tarife-Modal → /preise als eigene Seite existiert weiterhin.

5. Dashboard ist EIN Bereich. Nicht "Meine PMs" als eigene Seite, "Stats" als andere, "Credits" als dritte – alles unter /dashboard mit Tabs. Reduziert kognitive Last und Navigation.

---

Zusammenfassung als Liste zum Abhaken

Öffentliche Inhalts-Seiten (6): Detailseite, Branche, Region, Newsroom, Suche, Thema

Service-/Vertriebs-Seiten (4): Veröffentlichen, Preise, Mediadaten, Newsletter

Vertrauen/Editorial (3): Über uns, Redaktion, Kontakt

Rechtliches (4): Impressum, Datenschutz, AGB, Cookies

Technik/Distribution (2): Feeds, API-Doku

DSA-Pflicht (2): Melden, Verwalten (Magic-Link-Einstieg)

Eingeloggte Bereiche (3): Dashboard, Pressekontakt-Bereich, Admin

Macht insgesamt 24 echte Seiten/Bereiche – das ist für eine Plattform dieser Tiefe sehr schlank. Vergleichswert: presseportal.de hat über 80 Seiten in der Sitemap.