presseportale/dev/frontend/Umsetzungskonzept - Frontend BusinessPortal24 Startseite.md

Umsetzungskonzept - Frontend BusinessPortal24 Startseite

Stand: 12. Mai 2026
Status: Arbeits- und Umsetzungskonzept
Scope: Startseite businessportal24.test / spaeter businessportal24.com
Referenzen: Pass B _ _ Deutschland _aktiv.html, Pass B _ _ Deutschland _aktiv.png, Mobile _ Startseite.html, Ver_ffentlichen _ Variante A _aktiv_.html, Konzeptdokumente unter docs/konzept/

---

1. Ziel dieses Dokuments

Dieses Dokument uebersetzt das vorhandene Entwicklungskonzept und die Mockups in einen konkreten, abarbeitbaren Plan fuer die BusinessPortal24-Startseite.

Wichtig: Das Dokument ersetzt nicht die strategischen Konzepte, sondern passt sie an den realen Projektstand an. Im Projekt existieren bereits:

• ein Laravel-12-Backend mit Admin- und Customer-/Publisher-Bereichen,
• eine migrierte Datenbasis fuer Pressemitteilungen, Kategorien, Kontakte, Firmen und Legacy-Bezuege,
• eine config-basierte Multi-Domain-Struktur in config/domains.php,
• ein Web-Frontend unter resources/views/web und resources/views/livewire/web,
• ein separates Web-Asset-Bundle ueber vite.web.config.js und tailwind.web.config.js.

Das Ziel ist deshalb nicht, eine neue Multi-Brand-Architektur von null aufzubauen, sondern die bestehende Struktur zu konsolidieren, fachlich richtig auszurichten und die BusinessPortal24-Startseite aus dem Mockup heraus in echte Laravel-/Blade-/Volt-Komponenten zu ueberfuehren.

---

2. Relevante Ausgangslage

2.1 Strategische Leitplanken

BusinessPortal24 ist laut Positionierung kein allgemeines Magazin und kein Reichweiten-Versprechen. Die Marke steht fuer:

• aktuelle Unternehmens- und Wirtschaftsmeldungen,
• Mittelstand, Selbststaendige, PR-Agenturen und regionale Akteure,
• gepruefte Pressemitteilungen statt ungefiltertem SEO-Spam,
• dauerhaft auffindbare Inhalte,
• klare, sachliche, wirtschaftsnahe Tonalitaet.

Die Startseite muss deshalb eher wie ein dichter Wirtschaftsteil wirken als wie eine SaaS-Landingpage oder ein News-Magazin mit redaktionellen Versprechen.

Nicht verwenden:

• "fuehrende Plattform",
• "maximale Reichweite",
• "exklusive Interviews",
• "Analysen" als redaktionelles Versprechen, wenn diese nicht operativ erstellt werden,
• grosse Orange-/Rot-Gradienten als Hauptlook,
• generische Stock-/SaaS-Optik,
• harte Marketing-Funnels auf der Startseite.

2.2 Technischer Ist-Stand

Die Domain-Aufloesung ist aktuell config-basiert:

• portal nutzt build/portal, FluxUI und das Admin-/Publisher-Frontend.
• businessportal24 nutzt build/web, Theme businessportal24, View-Prefix web.
• presseecho nutzt ebenfalls build/web, Theme presseecho, View-Prefix web.

Die aktuelle Web-Startseite ist unter resources/views/web/businessportal24.blade.php vorhanden. Sie nutzt:

• web.layouts.web-master,
• Volt-Komponenten wie livewire:web.header, livewire:web.filter-bar, livewire:web.press-releases-grid, livewire:web.footer,
• Blade-Komponenten wie x-web.hero-banner, x-web.highlights-slider, x-web.section-header, x-web.pagination.

Der aktuelle Stand ist aber noch stark mockdatengetrieben und stilistisch nicht voll kompatibel mit der neuen Positionierung.

2.3 Datenmodell-Realitaet

Die Migration ist nicht nur hypothetisch. Relevante Tabellen und Modelle existieren bereits:

• press_releases mit portal, language, status, published_at, legacy_portal, legacy_id,
• categories mit portal, Parent-Struktur und Legacy-Bezug,
• press_release_images,
• companies, contacts, Footer-Codes, Newsletter und weitere Admin-/Customer-Strukturen.

Das Portal-Enum kennt presseecho, businessportal24 und both. Die Startseite muss deshalb von Anfang an mit echten Eloquent-Daten gedacht werden, nicht als statische Marketingseite.

---

3. Anpassung des bisherigen Entwicklungskonzepts

Das vorhandene Konzept beschreibt eine Zielarchitektur mit BrandResolver, Brand-Model, Middleware, View-Overrides und einer moeglichen brands-Tabelle. Dieser Ansatz ist langfristig plausibel, aber fuer den aktuellen Schritt zu gross.

Fuer die Startseite gilt:

1. Die bestehende config/domains.php bleibt zunaechst die fuehrende Brand-/Domain-Konfiguration.
2. ThemeServiceProvider, ThemeHelper, web-master und das bestehende Web-Bundle werden weiterverwendet.
3. Kein neues Brand-Model nur fuer die Startseite einfuehren.
4. Keine neue Base-Struktur unter app/Brand anlegen, solange der aktuelle Config-Ansatz reicht.
5. Komponenten werden dort neu gebaut oder ersetzt, wo das Mockup und die Positionierung es erzwingen.
6. Bestehende Admin-/Customer-/Publisher-Strukturen bleiben unberuehrt.

Langfristige Punkte aus dem Konzept bleiben als spaetere Ausbaustufe erhalten:

• Brand-Resolver mit DB-basierter Konfiguration,
• View-Override-Mechanik pro Brand,
• Score-/Quality-Tier-Anzeigen,
• Cross-Domain-Uebergabe zum Hub,
• differenziertere Presseecho-Logik.

3.1 Geklaerte Leitentscheidungen

Die offenen Fragen aus der ersten Konzeptfassung sind wie folgt entschieden:

• Region/Land wird nicht aus Legacy-Daten erwartet. Falls entsprechende Daten fehlen, wird die Information nicht angezeigt; die Felder koennen spaeter ergaenzt und dann in Filter/Metadaten aktiviert werden.
• Legacy-URLs duerfen nicht zu 404 fuehren. Bestehende Kategorie- und Pressemitteilungs-URLs muessen entweder direkt weiter rendern oder sauber auf neue kanonische Ziele gemappt werden.
• Qualitaetsstufen erscheinen auf der Startseite nur selektiv: sichtbar bei hohem Score oder Empfehlung, sonst keine Anzeige.
• /veroeffentlichen bleibt immer eine lokale Brand-Seite auf der jeweiligen Domain. Von dort fuehrt ein CTA in das zentrale Portal.
• Belastbare Zahlen wie Archivgroesse, Gruendungsjahr oder Anzahl aktueller Meldungen duerfen oeffentlich genutzt werden, wenn sie aus Datenbank/Import verifizierbar sind.
• Desktop ist die gesetzte Hauptvorlage. Mobile wird direkt parallel mitgeprueft; das mobile Mockup ist optische und funktionale Orientierung, die Inhalte folgen der Desktop-Variante.

---

4. Zielbild der BusinessPortal24-Startseite

Die Startseite beantwortet primaer: "Was ist aktuell bei Unternehmen los?"

Sie ist keine Verkaufsseite fuer Publisher. Der Publisher-CTA ist sichtbar, aber nicht der Hauptinhalt. Die Verkaufs-/Publishing-Argumentation gehoert auf die lokale Brand-Seite /veroeffentlichen; erst von dort fuehrt der naechste CTA in das zentrale Portal.

Inhaltliche Hauptaufgaben

• aktuelle Pressemitteilungen schnell sichtbar machen,
• DACH-/Deutschland-Aktivitaet zeigen,
• Branchenzugang anbieten,
• Suche und Filter prominent, aber ruhig integrieren,
• Vertrauen ueber gepruefte Qualitaet und Archiv-Stabilitaet aufbauen,
• Publisher sauber zur lokalen Landing /veroeffentlichen fuehren.

Visuelle Richtung aus Mockup

Die Mockups geben die konkrete Richtung vor:

• Desktop-Startseite: Pass B _ _ Deutschland _aktiv.html und .png,
• mobile Fassung: Mobile _ Startseite.html,
• spaetere Anschlussseiten: Detailseite und Branchenseite liegen ebenfalls im Ordner, sind aber nicht Teil dieses ersten Umsetzungsschritts.

Das Mockup ist als visuelle Zielvorgabe zu verwenden, nicht als HTML-Quelle fuer Copy-Paste. Die exportierten HTML-Dateien enthalten eingebettete Fonts und generierten Code und sollen in saubere Blade-/Tailwind-Komponenten uebersetzt werden.

---

5. Seitenstruktur Startseite

Die Startseite wird in klar getrennte Abschnitte zerlegt.

5.1 Header / Top-Navigation

Ziel:

• Marke sichtbar,
• Hauptnavigation mit Aktualitaetslogik,
• Suche erreichbar,
• CTA "Veroeffentlichen" vorhanden, aber nicht dominant.

Inhalte:

• Logo BusinessPortal24,
• Hauptnavigation: Aktuell, Branchen, Unternehmen, Pressemitteilung veroeffentlichen,
• Suche,
• optional Login/Publisher-Link.

Umsetzung:

• bestehende livewire:web.header pruefen und stark vereinfachen,
• bei rein statischem Header besser als Blade-Komponente x-web.site-header neu aufbauen,
• Livewire/Volt nur fuer mobile Suche oder interaktive Suche verwenden.

Entscheidung:

• Header-Grundmarkup als Blade-Komponente.
• Suchinteraktion spaeter als Volt-Komponente, wenn echte Suche angebunden wird.

5.2 Hero / Aktuell-Block

Ziel:

• sofort klarmachen: aktuelle Unternehmensmeldungen aus Deutschland/DACH,
• keine Reichweitenversprechen,
• erste Top-Meldung oder aktuelle Meldung prominent zeigen.

Moegliche Headline:

Aktuelle Pressemitteilungen aus der deutschen Wirtschaft

Subline:

Neue Unternehmensmeldungen, Personalien, Produktankündigungen und Wirtschaftsnachrichten aus Mittelstand, Industrie und Dienstleistung.

Umsetzung:

• keine reine Marketing-Hero-Section,
• eher Editorial-Header mit Datum, Region-/Land-Filter und Top-Meldung,
• Top-Meldung aus echten PressRelease-Daten laden,
• Fallback fuer leere Datenbank nur fuer lokale Entwicklung definieren.

5.3 Region-/Land- und Zeitfilter

Ziel:

• BusinessPortal24 folgt der Aktualitaetslogik.
• Der Zustand "Deutschland aktiv" aus dem Mockup wird als Startzustand interpretiert.

Filter:

• Region: Deutschland, Oesterreich, Schweiz, optional DACH,
• Zeitraum: Heute, 7 Tage, 30 Tage,
• Branche: optional im Hauptfilter oder als Branchenleiste.

Umsetzung:

• bestehende livewire:web.filter-bar kann als Ausgangspunkt dienen,
• Werte aus hardcodierten Listen spaeter in Kategorien/Region-Config ueberfuehren,
• Filterevents muessen mit press-releases-grid verbunden werden; aktuell ist die Grid-Komponente mockdatenbasiert.

5.4 Aktuelle Meldungsliste

Ziel:

• Hauptinhalt der Startseite.
• Timeline-first: neueste Pressemitteilungen stehen im Zentrum.

Darstellung:

• Listen-/Card-Hybrid statt Magazin-Kacheln,
• klare Metadaten: Firma, Kategorie/Branche, Region, Datum,
• kurze Teaser,
• optionale Bildvorschau, wenn vorhanden,
• Qualitaetslabel nur selektiv anzeigen: bei hohem Score oder ausdruecklicher Empfehlung; sonst keine Anzeige.

Umsetzung:

• livewire:web.press-releases-grid durch eine datenbasierte Komponente ersetzen oder umbauen,
• Query auf PressRelease mit portal in (businessportal24, both), Status veroeffentlicht, Sprache de, published_at desc,
• Eager Loading fuer company, category.translations, erstes Bild,
• Pagination serverseitig.

Wichtig:

• Keine erfundenen Analyse-/Interview-Typen ausgeben, wenn die Daten nur Pressemitteilungen sind.
• Content-Type kann spaeter aus realen Feldern kommen, darf aber zum Start nicht redaktionelle Formate vortaeuschen.

5.5 Branchenzugang

Ziel:

• schneller Einstieg in relevante Themen,
• Startseite bleibt aktualitaetszentriert, bietet aber Branchenpfade.

Inhalte:

• Branchenliste aus aktiven Kategorien,
• optional Anzahl aktueller Meldungen je Kategorie,
• Link auf Branchenseiten wie /kategorie/{slug}.

Umsetzung:

• Blade-Komponente x-web.industry-strip oder x-web.category-strip,
• Query ueber Category mit aktiven Kategorien fuer businessportal24 oder both,
• Uebersetzungen fuer de nutzen.

5.6 Vertrauens-/Qualitaetsblock

Ziel:

• BusinessPortal24 als geprueftes, dauerhaftes Pressearchiv positionieren,
• ohne Fake-Trust und ohne uebertriebene Reichweite.

Moegliche Inhalte:

• "Gepruefte Pressemitteilungen",
• "Dauerhaft auffindbar",
• "Archivierte Unternehmensmeldungen seit vielen Jahren",
• "Korrektur statt Loeschung".

Umsetzung:

• statische Blade-Komponente,
• Zahlen offensiv verwenden, wenn sie aus Datenbank/Import verifizierbar sind,
• bei Zahl "~100.000" erst nach Datenabgleich final anzeigen,
• "seit 2008" oder vergleichbare Historienhinweise nutzen, wenn sie fuer die jeweilige Domain belegbar sind.

5.7 Publisher-CTA

Ziel:

• sichtbarer, aber dezenter Uebergang zur Veroeffentlichung.

CTA:

• Primaer: Pressemitteilung veroeffentlichen
• Ziel immer zuerst: /veroeffentlichen
• von dort aus: CTA in das zentrale Portal / den Publisher-Bereich

Umsetzung:

• nicht als dominanter SaaS-Banner,
• als sachlicher Infokasten oder Footer-CTA,
• klare Sprache: "Die Einreichung startet auf BusinessPortal24 und wird im zentralen Publisher-Bereich fortgefuehrt."
• fuer die Ausarbeitung der Landing den Entwurf Ver_ffentlichen _ Variante A _aktiv_.html beruecksichtigen.

5.8 Footer

Ziel:

• rechtliche Links,
• Betreiberhinweis,
• dezenter Markenfamilien-Hinweis,
• RSS/Newsletter nur wenn funktional.

Aktuelle Footer-Crosslinks muessen sprachlich korrigiert werden:

• Nicht: "Fuer maximale Reichweite?"
• Besser: "Weitere Branchen- und Archivzugänge finden Sie bei Presseecho."

---

6. Komponentenplan

6.1 Blade-Komponenten

Diese Komponenten sollen statisch oder serverseitig gerendert werden:

• x-web.site-header
• x-web.main-navigation
• x-web.home-hero
• x-web.press-release-list-item
• x-web.category-strip
• x-web.quality-summary
• x-web.publisher-cta
• x-web.site-footer

Blade ist hier bevorzugt, weil diese Bausteine keine dauerhafte Livewire-Hydration brauchen.

6.2 Volt-Komponenten

Volt wird nur dort eingesetzt, wo echter State benoetigt wird:

• livewire:web.press-release-feed fuer Filter, Pagination und spaeter Suche,
• livewire:web.search-box falls Suchvorschlaege/autocomplete kommen,
• optional livewire:web.region-filter.

Die bestehende press-releases-grid kann als Arbeitsgrundlage dienen, soll aber von Mockdaten auf echte Daten umgestellt und fachlich umbenannt werden, wenn sie keine Grid-Komponente mehr ist.

6.3 Nicht fuer Sprint 1

Nicht in die Startseiten-Umsetzung aufnehmen:

• Score-Berechnung,
• Boost-Slots,
• Editorial-Pick-Admin-Workflow,
• Cross-Domain-Sanctum-Auth,
• vollstaendige Suchmaschine,
• Presseecho-Override-Architektur,
• neue Brand-DB-Tabelle.

---

7. Daten- und Query-Konzept

7.1 Startseiten-Feed

Basisquery:

• nur veroeffentlichte Pressemitteilungen,
• Portal businessportal24 oder both,
• Sprache de,
• nach published_at desc,
• Soft-Deletes ausschliessen.

Benötigte Relationen:

• company,
• category.translations,
• erstes/primäres Bild aus images,
• optional Kontakte erst auf Detailseite.

7.2 Kategorien / Branchen

Basisquery:

• aktive Kategorien,
• Portal businessportal24 oder both,
• Parent-Struktur beachten,
• deutsche Uebersetzung laden,
• Anzahl aktueller Meldungen optional per withCount.

7.3 Region / Land

Region und Land werden nicht verlaesslich aus den Legacy-Daten erwartet. Fuer die erste Startseitenfassung gilt:

• vorhandene Region-/Landdaten anzeigen, wenn sie sauber vorhanden sind,
• fehlende Daten nicht durch geratenen Text ersetzen,
• Filter fuer Region/Land erst aktivieren, wenn die Datenquelle klar ist,
• spaetere Ergaenzung ueber neue Felder oder normalisierte Zuordnung vorbereiten.

7.4 Fallbacks

Fuer migrierte Inhalte muessen Komponenten tolerant sein:

• fehlendes Bild,
• fehlende Kategorie,
• fehlende Firma,
• fehlende Region / fehlendes Land,
• altes oder sehr langes Textfeld,
• fehlender Teaser,
• Legacy-Slugs und Permalink-Stabilitaet.

Fallbacks duerfen nicht wie Demo-Daten wirken. Besser:

• Bildbereich weglassen,
• Firma als "Unternehmensmeldung" nur wenn kein Firmenname existiert,
• Region/Land ausblenden, solange keine sauberen Daten vorhanden sind,
• Teaser aus Text sauber kuerzen,
• keine Platzhalterbilder von externen Diensten.

---

8. Routing-Konzept

Aktueller Stand:

• / waehlt anhand des Hosts web.businessportal24 oder web.presseecho.
• /veroeffentlichen, /kategorien, /kategorie/{slug}, /release/{slug} sind bereits angelegt.

Fuer die Startseite:

• Route / bleibt.
• View web.businessportal24 wird zur echten Startseite.
• Keine neue Route noetig.

Fuer spaetere Unterseiten:

• Detailseite: neue Route darf existieren, aber Legacy-URLs muessen weiter funktionieren.
• Branchenseite: neue Route darf existieren, aber Legacy-Kategorie-URLs muessen weiter funktionieren.
• Veroeffentlichen-Landing: /veroeffentlichen.

Legacy-Beispiele:

• https://www.businessportal24.com/de/category/kultur.html
• https://www.businessportal24.com/de/die-zehn-stufen-vom-haben-zum-sein-ein-wegweiser-zu-innerer-freiheit-und-echter-erfuellung.html

Wichtig:

• Keine URLs in Komponenten hardcoden, wenn named routes existieren oder sinnvoll ergaenzt werden koennen.
• Legacy-Permalinks aus der Migration nicht durch neue Frontend-Pfade brechen.
• Kein Legacy-Aufruf darf zu 404 fuehren.
• Fuer neue, sauberere URLs kann spaeter eine kanonische Struktur entstehen. Dann ist pro URL-Typ zu entscheiden, ob die alte URL direkt rendert oder per 301 auf die neue kanonische URL weiterleitet.
• Kategorie- und Pressemitteilungs-Routing muessen vor Umsetzung der Detail- und Branchenseiten anhand der Legacy-Daten konkret gemappt werden.

---

9. Styling- und Asset-Konzept

9.1 Bestehende Basis

Das Web-Frontend nutzt:

• resources/css/web/theme-businessportal24.css,
• resources/css/web/theme-presseecho.css,
• resources/css/web/shared-styles.css,
• tailwind.web.config.js,
• vite.web.config.js,
• Build-Ausgabe public/build/web.

9.2 Anpassung fuer die neue Startseite

Das aktuelle BusinessPortal24-CSS enthaelt noch viel Glow-, Glass- und Gradient-Sprache. Das widerspricht der neuen Positionierung teilweise.

Neue Richtung:

• neutrale, helle Flaechen,
• Orange/Rot als Akzent,
• feine Linien,
• typografische Dichte,
• wenig Schatten,
• keine starken Glows,
• kein Glassmorphism als Grundmuster.

9.3 Design Tokens

Kurzfristig reichen die vorhandenen CSS-Variablen. Ergaenzen oder schaerfen:

• --bp-surface
• --bp-surface-muted
• --bp-text
• --bp-text-muted
• --bp-accent
• --bp-border

Nicht fuer Sprint 1 noetig:

• kompletter Umbau auf neue @theme-Token-Architektur,
• Tailwind-v4-Designsystem von Grund auf.

---

10. Umsetzungsschritte

Schritt 1 - Bestandsseite sichern und fachlich bereinigen

Aufgaben:

• aktuelle web.businessportal24 analysieren,
• Inhalte entfernen, die der Positionierung widersprechen,
• Mockdaten-Inhalte markieren oder ersetzen,
• Header-/Footer-Sprache korrigieren.

Ergebnis:

• klare, noch nicht finale Startseite ohne falsche Versprechen.

Schritt 2 - Layout aus Mockup in Sektionen schneiden

Aufgaben:

• Desktop-Mockup in Abschnitte zerlegen,
• Mobile-Mockup gegenpruefen,
• Abstaende, Typografie, Spalten und Navigationszustaende dokumentieren,
• keine generierte HTML-Struktur uebernehmen.

Ergebnis:

• Komponentenliste mit Zuordnung zu Blade oder Volt.

Schritt 3 - Statische Shell bauen

Aufgaben:

• neues Header-/Footer-Markup erstellen,
• Hero/Aktuell-Block als Blade-Komponente,
• Kategorie-/Branchenleiste als Blade-Komponente,
• Publisher-CTA als Blade-Komponente,
• CSS auf editorialen BusinessPortal24-Look reduzieren.

Ergebnis:

• Startseite sieht im Grundlayout wie das Mockup aus, nutzt aber noch einfache Daten/Fallbacks.

Schritt 4 - Pressemitteilungen datenbasiert anbinden

Aufgaben:

• Feed-Komponente mit echter PressRelease-Query bauen,
• Relationen eager loaden,
• Pagination integrieren,
• leere/alte Daten sauber behandeln,
• Kategorie- und Datumsanzeige aus echten Feldern.

Ergebnis:

• Startseite zeigt echte migrierte/veroeffentlichte Meldungen.

Schritt 5 - Filter aktivieren

Aufgaben:

• Zeitraum- und Branchenfilter mit Query verbinden,
• Region-/Landfilter erst aktivieren, wenn die Datenquelle sauber vorhanden ist,
• URL-State pruefen (?region=de&zeitraum=7), damit Links teilbar bleiben,
• Mobile-Darstellung aus Mockup umsetzen,
• Ladezustand minimal halten.

Ergebnis:

• aktive Filterzustaende funktionieren serverseitig nachvollziehbar; fehlende Region-/Landdaten werden nicht angezeigt.

Schritt 6 - SEO und Meta-Basis

Aufgaben:

• Seitentitel und Description fuer BusinessPortal24 setzen,
• Open-Graph-Basisdaten,
• canonical URL je Domain,
• Legacy-URL-Strategie fuer Kategorie- und Detailseiten beruecksichtigen,
• keine noindex-/Demo-Reste,
• strukturierte Daten nur, wenn fachlich sauber.

Ergebnis:

• Startseite ist SEO-tauglich und teilbar.

Schritt 7 - Tests und technische Abnahme

Aufgaben:

• Feature-Test fuer Startseite businessportal24 anlegen/erweitern,
• Test fuer sichtbare Kerntexte,
• Test fuer veroeffentlichte BusinessPortal24-/Both-Meldungen im Feed,
• Test gegen Presseecho-Verwechslung,
• responsive Smoke-Check manuell im Browser.

Ergebnis:

• Startseite ist gegen Regressionen abgesichert.

---

11. Akzeptanzkriterien Startseite

Die Startseite gilt als fertig fuer den naechsten Schritt, wenn:

• businessportal24.test/ ohne Fehler rendert,
• keine falschen Reichweiten-/Lead-/Exklusivversprechen sichtbar sind,
• keine Demo-Placeholders von externen Bilddiensten sichtbar sind,
• echte Pressemitteilungen aus der Datenbank angezeigt werden,
• Meldungen nach Portal-Kontext gefiltert werden,
• fehlende Region-/Landdaten nicht als Platzhalter angezeigt werden,
• selektive Qualitaets-/Empfehlungslabels nur bei vorhandenem Score/Flag erscheinen,
• Header, Navigation, Feed, Branchenzugang, Publisher-CTA und Footer responsiv funktionieren,
• die mobile Ansicht direkt parallel am Mockup Mobile _ Startseite.html orientiert ist,
• /veroeffentlichen lokal auf BusinessPortal24 bleibt und von dort ins Portal fuehrt,
• php artisan test --compact fuer die betroffenen Tests erfolgreich ist,
• php bin pint --dirty --format agent nach PHP-Aenderungen gelaufen ist,
• php npm run build:web oder der relevante Build erfolgreich ist, sobald CSS/JS geaendert wurden.

---

12. Dokumentationslog waehrend der Umsetzung

Dieses Dokument soll waehrend der Umsetzung fortgeschrieben werden. Pro abgeschlossenem Schritt:

• Datum eintragen,
• erledigte Dateien nennen,
• offene Punkte festhalten,
• bewusste Abweichungen vom Mockup begruenden.

Log

Datum	Schritt	Status	Notiz
12.05.2026	Konzept erstellt	offen	Startpunkt fuer Umsetzung der BusinessPortal24-Startseite
12.05.2026	Offene Fragen eingearbeitet	erledigt	Region-Fallbacks, Legacy-URLs, lokale Veroeffentlichen-Seite, Qualitaetslabels, Zahlen und Mobile-Vorgehen geklaert
12.05.2026	Mockup Pass B _ _ Deutschland _aktiv 1:1 in Blade/Volt-Sektionen ueberfuehrt	erledigt	Neue Komponenten: site-header (Top-Bar/Brand/Suche/Navigation/Live-Ticker), focus-hero (Hauptmeldung + 'Was sonst zaehlt'), Volt-Feed mit Tabs Alle/Heute/Diese Woche, Sidebar (most-read, publisher-cta, active-newsrooms), industry-spotlight (KPI + Liste + Studie), events-week, industry-index, newsletter-strip (dunkel), quality-summary, site-footer. Echte Daten aus PressRelease/Category/Company. Demo-Inhalte fuer Ticker, Termine, Newsletter-Topics, Studie bleiben statisch und sind als spaetere Datenquelle markiert. Theme-CSS auf editorialen Look (Source Serif 4 / Inter Tight / JetBrains Mono, neutrale Beige-Surface, ruhige Akzentfarbe #cf3628) umgestellt.
12.05.2026	Formatierung an dev/frontend/tailwind_v3/Startseite Tailwind.html angeglichen	erledigt	Theme-CSS auf vollstaendiges v3-Farbsystem migriert (bg/bg-elev/bg-rule/bg-rule-strong/bg-card-warm/bg-card-warm-border, ink/ink-2..4/ink-on-dark*, brand/brand-deep/brand-soft/gain/loss, Gradient-Tokens bg-topbar-grad/bg-feature-grad/bg-hero-grad, max-w-layout: 1280px, Akzentfarbe nun #C84A1E). Site-Header bekam dunkle Top-Bar mit Edition-Tabs (DE/AT/CH/EN), Suchfeld mit Cmd+K-Hinweis und "Erweiterte Suche", Underline-Navigation; neuer live-ticker mit Pulse-Dot + DAX-Sparkline. Focus-Hero: 500px-Hero mit bg-hero-grad, TOP-MELDUNG- und Audio-Tag, nummerierte Sidebar (01-04) mit 64×64 Bild-Block + Verifiziert-Icon, abgesetzte 4px-Pagination, eigene Anzeigen-Karte. Press-Release-Feed komplett auf flache 60/100/1fr-Liste umgestellt (Featured-Top mit 240×160-Bild, Empfehlung-Stern-Badge, In-Feed-Anzeigen mit Anzeige/Ende Anzeige-Hairlines auf bg-card-warm). Most-Read mit horizontalem Brand-Balkenindikator; Publisher-CTA, Newsletter-Strip und Site-Footer durchgehend auf bg-topbar-grad umgestellt; Active-Newsrooms mit Brand-Marken-Initial + Pulse-Badge "heute aktiv". Industry-Spotlight als 3-Spalten-Stat-Grid + Liste + warme Studien-Karte mit Brand-Topborder; Events-Week als zusammenhaengendes 7-Spalten-Grid mit "Heute"-Highlight; Industry-Index als 4×2-Grid mit Gain/Loss-Trend und Balken; Quality-Summary als warm-beige Card mit Schild-Icon. 215 Tests gruen (213 Tests bei 1095 Assertions; einziger Fail ist vorbestehender api/v1.yml-Test ohne Bezug zur Startseite).

---

13. Entscheidungen und Restklaerungen

13.1 Geklaerte Entscheidungen

• Region/Land kommt nicht verlaesslich aus den Legacy-Daten. Fehlende Daten werden nicht angezeigt und koennen spaeter durch neue Felder oder Zuordnungen ergaenzt werden.
• Die komplette Legacy-URL-Struktur muss sauber migriert werden. Weder Kategorie- noch Detail-URLs duerfen zu 404 fuehren.
• Beispiel Kategorie alt: https://www.businessportal24.com/de/category/kultur.html
• Beispiel Pressemitteilung alt: https://www.businessportal24.com/de/die-zehn-stufen-vom-haben-zum-sein-ein-wegweiser-zu-innerer-freiheit-und-echter-erfuellung.html
• Neue, sauberere URLs sind zulaessig. Pro URL-Typ muss aber entschieden werden, ob alte URLs direkt rendern oder per 301 auf kanonische neue URLs leiten.
• Qualitaetsstufen koennen auf der Startseite sichtbar sein, aber nur selektiv bei hohem Score oder Empfehlung; sonst bleibt die Anzeige leer.
• /veroeffentlichen bleibt immer lokal auf der jeweiligen Brand-Domain. Von dort fuehrt ein CTA in das zentrale Portal. Der Entwurf Ver_ffentlichen _ Variante A _aktiv_.html ist fuer diese Landing zu beruecksichtigen.
• Oeffentliche Zahlen wie "100.000", "seit 2008" oder aktuelle Meldungszahlen duerfen genutzt werden, wenn sie belastbar sind und der Positionierung helfen.
• Desktop ist die gesetzte Vorlage. Mobile wird parallel geprueft und umgesetzt; das mobile Mockup liefert Optik/Funktion, die Inhalte folgen der Desktop-Variante.

13.2 Noch offen

• Header langfristig als statische Blade-Komponente oder als Volt-Komponente: vor Umsetzung anhand der tatsaechlichen Such-/Menue-Interaktion entscheiden.
• Konkretes Legacy-URL-Mapping fuer Kategorien und Pressemitteilungen anhand der migrierten Daten pruefen.
• Kanonische neue URL-Struktur fuer Kategorien und Pressemitteilungen festlegen.

---

14. Reihenfolge nach der Startseite

Nach finaler Desktop- und Mobile-Startseite werden die weiteren Mockups in dieser Reihenfolge umgesetzt:

1. Startseite Desktop auf Basis Pass B _ _ Deutschland _aktiv finalisieren.
2. Mobile Startseite parallel gegen Mobile _ Startseite.html pruefen und responsiv finalisieren.
3. Detailseite Pressemitteilung inklusive Legacy-URL-Mapping.
4. Branchenseite Energie/Klima als Vorlage fuer alle Kategorien inklusive Legacy-Kategorie-URLs.
5. Veroeffentlichen-Landing auf Basis Ver_ffentlichen _ Variante A _aktiv_.html.
6. Presseecho-Ableitung erst nach stabiler BusinessPortal24-Basis.

Diese Reihenfolge verhindert, dass gemeinsame Komponenten zu frueh abstrahiert werden. Erst wenn Startseite, Detailseite und Branchenseite konkret sind, ist sichtbar, welche Bausteine wirklich wiederverwendbar sind.