diff --git a/dev/frontend/hub-flux/PROGRESS.md b/dev/frontend/hub-flux/PROGRESS.md index dbfd56e..31d18ea 100644 --- a/dev/frontend/hub-flux/PROGRESS.md +++ b/dev/frontend/hub-flux/PROGRESS.md @@ -5,6 +5,31 @@ --- +## 2026-06-12 · Tagesabschluss · PM-Vorschau-Feinschliff + Next Steps ✅ + +- **Was**: Letzte Review-Runde auf der PM-Vorschauseite: Sprache-Kachel + entfernt (Kürzel jetzt als Badge am Portal-Namen), Panel „Zugeordnete + Pressekontakte" zu **„Firma & Pressekontakt"** zusammengeführt — oben + die Firma als vollwertige `firm-card` wie in der Firmenübersicht + (Logo/Initialen, Name + Meta-Zeile, Portal-Pills, Aktiv-Badge, + PM-/Kontakt-KPIs, „Firma öffnen"), direkt darunter der zugeordnete + Pressekontakt bzw. der Leerhinweis. +- **Dateien**: `customer/press-releases/show.blade.php`, + `docs/README.md` (Stand + neuer `weiteres/`-Abschnitt). +- **Build/Test**: Suite 557 passed / 4 skipped, Pint clean. +- **Hinweis Doku**: Das umgesetzte Verlinkungs-Decision-Update wurde von + Kevin aus `docs/weiteres/` entfernt (Inhalt in §4 des + Preisstruktur-Decision-Updates integriert, Umsetzungsstand hier im Log). +- **Nächste Schritte (vereinbart 12.06.2026)**: + 1. **Decision-Update „Phase-2-Funktionen & Magic-Link-Änderungsprozess"** + umsetzen (Boost + Veröffentlichungsnachweis für den Launch, + Magic-Link-Zugangs-/Änderungsprozess; überschneidet sich mit 9G + Tageslimit und 9I Launch-Credits). + 2. **Decision-Update „Duplicate-Content & Duplicate-Checking"** umsetzen + (Cross-Portal-SEO vs. Duplikat-Erkennung eingereichter PMs). + 3. Danach weiter laut Kevins Liste: Login-/Registrierungs-Flow + durchtesten (Zweig 3), Code-Optimierung (Zweig 4). + ## 2026-06-12 · KI-generierte Bilder: Lizenztyp + Kennzeichnung ✅ - **Was**: Neuer Lizenztyp „KI-generiert" im Titelbild-Upload diff --git a/docs/README.md b/docs/README.md index de3add7..612663a 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,8 +1,11 @@ # `docs/` — Konzept- und Status-Dokumente -Stand: 11.06.2026 — Phase 8 (User-Panel-Konsolidierung) und die KI-Prüf-Pipeline -(Klassifikation + Content-Score, Phasen 0–5) sind abgeschlossen. Nächster großer -Block: Zahlung/Tarife + Veröffentlichungs-Flow laut Decision-Update. +Stand: 12.06.2026 — Phase 8, die KI-Prüf-Pipeline (Phasen 0–5) sowie aus +Phase 9 die Stripe-Anbindung (9E), die Tarif-Seite (9F), das +Admin-Zahlungsmodul, die User-Panel-Restarbeiten und das +Verlinkungs-Decision-Update sind abgeschlossen. Nächste Blöcke: die zwei +neuen Decision-Updates in `weiteres/` (Phase-2-Funktionen & Magic-Link, +Duplicate-Content), dazu 9G Tageslimit und der Login-/Registrierungs-Flow. Diese README ist der schnellste Einstieg in den `docs/`-Ordner. Sie verlinkt die zentralen Dokumente und sortiert sie nach „Was ist der aktuelle Stand?" vs. „Was ist konzeptueller Zielzustand?". @@ -29,6 +32,12 @@ Sie verlinkt die zentralen Dokumente und sortiert sie nach „Was ist der aktuel - [`Echte öffentliche Unterseiten.md`](./Echte%20%C3%B6ffentliche%20Unterseiten.md) — Sitemap-Konzept, jede Seite mit IST-Notiz. - [`KI-UND-ENTWICKLER-WORKFLOW.md`](./KI-UND-ENTWICKLER-WORKFLOW.md) — Workflow für KI-/Entwickler-Sessions. +### `weiteres/` — Abgestimmte Decision-Updates (nächste Umsetzungsblöcke) + +- [`Decision-Update Phase-2-Funktionen & Magic-Link-Änderungsprozess.md`](./weiteres/Decision-Update%20Phase-2-Funktionen%20&%20Magic-Link-%C3%84nderungsprozess.md) — Boost + Veröffentlichungsnachweis (Launch), Magic-Link-Zugangs-/Änderungsprozess, Phase-2-Funktionen (Vorab-Prüfung, Prüfzähler, kostenpflichtige Änderungspfade). **Noch nicht umgesetzt.** +- [`Decision-Update Duplicate-Content & Duplicate-Checking.md`](./weiteres/Decision-Update%20Duplicate-Content%20&%20Duplicate-Checking.md) — Cross-Portal-Duplicate-Content (SEO) vs. Duplikat-Erkennung eingereichter PMs. **Noch nicht umgesetzt.** +- Das Decision-Update „Verlinkung & Backlinks" ist umgesetzt (systemseitige `rel`-Auszeichnung, `PressReleaseLinkPolicy`, 12.06.2026) und wurde nach der Integration in §4 des Preisstruktur-Decision-Updates entfernt — Umsetzungsdetails im Hub-Flux-PROGRESS-Log. + ### `user-admin/` — User-/Admin-Backend Konzept und Status-Dokumentation für das User- und Admin-Backend. diff --git a/docs/weiteres/Decision-Update Duplicate-Content & Duplicate-Checking.md b/docs/weiteres/Decision-Update Duplicate-Content & Duplicate-Checking.md new file mode 100644 index 0000000..1c85339 --- /dev/null +++ b/docs/weiteres/Decision-Update Duplicate-Content & Duplicate-Checking.md @@ -0,0 +1,65 @@ + +**Version:** Juni 2026 **Datum:** 12.06.2026 **Status:** Abgestimmt – bereit zur Integration ins Konzept-/Decision-Log **Scope:** Klärung, ob das Portal doppelte/ähnliche Pressemitteilungen automatisch prüfen muss. Separates Thema, bewusst aus dem Phase-2/Magic-Link-Dokument herausgelöst. + +--- + +## 1. Kontext + +Beim Thema Cross-Portal-Veröffentlichung kam Duplicate-Content als SEO-Risiko auf. Daraus entstand die Folgefrage, ob das Portal doppelte oder ähnliche Pressemitteilungen automatisch erkennen/prüfen sollte. Wichtig: Hier werden zwei **verschiedene** Probleme vermischt, die getrennt zu betrachten sind. + +--- + +## 2. Die zwei Duplicate-Szenarien + +||Szenario A: System-Duplicate|Szenario B: Kunden-Duplicate| +|---|---|---| +|**Ursache**|Cross-Portal-Feature spiegelt dieselbe PM auf zwei Domains|Kunde legt manuell zweimal dasselbe an (zwei Firmen-Einträge, zwei ähnliche PMs)| +|**Wer trägt den Schaden**|das Portal (eigene Domains konkurrieren)|der Kunde selbst| +|**Häufigkeit**|systematisch (bei jedem Cross-Post)|seltener Randfall| +|**Status**|**gelöst durch Weglassen**|**kein aktiver Check**| + +--- + +## 3. Szenario A – gelöst durch Weglassen + +Das ursprüngliche SEO-Duplicate entstand ausschließlich durch das geplante Cross-Portal-Feature (eine PM, vom System auf presseecho.de **und** businessportal24.com gespiegelt). Da dieses Feature **bewusst nicht gebaut wird** (Portale optisch, inhaltlich und systemisch getrennt – siehe Decision-Update Phase 2/Magic-Link, Abschnitt 6), entsteht dieser Duplicate gar nicht erst. + +**Kein automatischer Spiegel = kein automatischer Duplicate.** Es ist hier nichts zu prüfen. + +--- + +## 4. Szenario B – bewusst kein automatisches Duplicate-Checking + +Ein Kunde, der manuell zweimal dasselbe einstellt und zweimal zahlt, ist ein seltener Randfall. Ein automatischer Erkennungsmechanismus steht in keinem Verhältnis: + +- **KI-Ähnlichkeitsprüfung** über alle PMs = laufende Kosten bei _jeder_ Veröffentlichung, für einen Randfall +- **DB-Vergleich** („gleiche Firma doppelt + ähnlicher Text") klingt simpel, ist es nicht: „ähnlich" sauber zu definieren (Schwellwert? gleicher Titel? gleicher erster Absatz?) ist die klassische Fuzzy-Matching-Falle – viel Tuning, trotzdem Fehlalarme +- **Gleiche Firma zweimal angelegt** ist oft **legitim** (verschiedene Abteilungen, verschiedene Pressekontakte) – kein verlässliches Duplicate-Signal + +**Entscheidender Punkt:** Den SEO-Nachteil eines selbst erzeugten Duplikats trägt der Kunde, nicht das Portal. Die Leistung wurde erbracht (zwei Veröffentlichungen, zweimal bezahlt). Der Kunde muss nicht vor seiner eigenen Entscheidung geschützt werden. + +--- + +## 5. Was stattdessen greift (kostenlos, sofort) + +1. **Score deckt den relevanten Teil ab.** Die Red-Flag-/Content-Prüfung läuft ohnehin bei jeder PM. Plump kopierte Massen-/Müll-PMs fallen dort als Qualitätsproblem auf – das ist der eigentliche Spam-Filter, kein separates Duplicate-System nötig. +2. **Canonical-Tags sauber setzen.** Rein technisch, keine laufenden Kosten. Jede PM erhält ihre eigene kanonische URL – saubere SEO-Hygiene statt aktivem Prüfprozess. +3. **Phase-3-Option, nur falls es real wird.** Sollte sich im Betrieb zeigen, dass Duplikate tatsächlich ein Problem sind (unwahrscheinlich), lässt sich ein billiger **Hash-/Shingle-Vergleich** auf Titel + erste Absätze nachrüsten – algorithmisch, keine KI. Erst bauen, wenn Daten zeigen, dass es vorkommt. + +--- + +## 6. Entscheidung + +- **Kein automatisches Duplicate-Checking zum Launch.** +- Szenario A (System-Duplicate) ist durch den Verzicht auf Cross-Portal erledigt. +- Szenario B (Kunden-Duplicate) wird nicht aktiv geprüft; der Score fängt Spam/Müll ab, Canonical-Tags sorgen für technische Hygiene. +- Hash-/Shingle-Vergleich bleibt als **Phase-3-Option** notiert, nur bei nachgewiesenem Bedarf. + +--- + +## 7. Anti-Zombie-Check + +- ✅ Keine Kosten auf Vorrat für ein Phantomproblem +- ✅ Kunde wird nicht für legitime Mehrfachnutzung (zwei Abteilungen, zwei Kontakte) fälschlich blockiert +- ✅ Spam-Schutz läuft über den ohnehin vorhandenen Score, nicht über ein zweites paralleles System +- ✅ Technische SEO-Hygiene (Canonical) statt aktivem, fehleranfälligem Prüfprozess \ No newline at end of file diff --git a/docs/weiteres/Decision-Update Verlinkung & Backlinks in Pressemitteilungen.md b/docs/weiteres/Decision-Update Verlinkung & Backlinks in Pressemitteilungen.md deleted file mode 100644 index 5be5c63..0000000 --- a/docs/weiteres/Decision-Update Verlinkung & Backlinks in Pressemitteilungen.md +++ /dev/null @@ -1,145 +0,0 @@ - - -**Version:** Juni 2026 **Datum:** 11.06.2026 **Status:** Abgestimmt – bereit zur Integration ins Konzept-/Decision-Log **Scope:** Behandlung von Links in Presseartikeln, `rel`-Auszeichnung, Linkangabe und Linktyp-Auswahl im Editor, Abgrenzung zum verkauften Dofollow-Backlink. Präzisiert den entsprechenden Punkt im Decision-Update „Preisstruktur & Veröffentlichungs-Flow". - ---- - -## 1. Kontext & Klarstellung - -In der Preis-Abstimmung war der Punkt „verkaufte Dofollow-Backlinks ausgeschlossen" zu pauschal formuliert und konnte als „keine Links" missverstanden werden. Das ist falsch. Links in Presseartikeln gehören selbstverständlich dazu. Die Frage ist nicht _ob_, sondern _wie ausgezeichnet_ und _wie verkauft_. - -Es geht um zwei verschiedene Dinge, die beide „Backlink" heißen: - -1. **Der Link im Presseartikel zur Kundenseite** – normaler, erwarteter Bestandteil jeder PM. Erlaubt, darf hervorgehoben werden. Muss technisch korrekt ausgezeichnet sein. -2. **Den „Dofollow-Backlink für SEO-Wert" als bezahltes Upsell verkaufen** – das ist die Falle und bleibt ausgeschlossen. - ---- - -## 2. Grundregel (Google-konform) - -**Externe Links in Pressemitteilungen werden systemseitig mit `rel="sponsored"` bzw. `rel="nofollow"` ausgezeichnet.** - -Hintergrund: Google behandelt Links in Pressemitteilungen als Kategorie, die nofollow gehört – der Kunde setzt den Link selbst, es ist keine redaktionelle Empfehlung des Portals. Jeder über Bezahlung oder kommerzielle Vereinbarung entstandene Link muss entsprechend qualifiziert sein; eine fehlende Kennzeichnung von Paid-Placements ist selbst der Richtlinienverstoß. Für kombinierte Fälle (bezahlte Platzierung + kein Endorsement) ist `rel="sponsored nofollow"` zulässig. - -**Konsequenz fürs Produkt:** Die `rel`-Auszeichnung ist **nicht kundenseitig wählbar**. Sie wird vom System anhand der Platzierungs-Kategorie automatisch gesetzt. Damit ist die Domain dauerhaft sauber und es gibt keinen Hebel, über den ein Kunde „dofollow" erzwingen könnte. - ---- - -## 3. Wichtig: nofollow ≠ wertlos - -Die alte Logik „nofollow = nutzlos" gilt seit 2019 nicht mehr. Google behandelt `nofollow`/`sponsored`/`ugc` seitdem als **Hinweis**, nicht als absolute Anweisung. Praktischer Wert für den Kunden bleibt: - -- **Referral-Traffic** – direkte Klicks vom Presseartikel auf die Kundenseite -- **Marken-Assoziation & Kontext** – die Nennung selbst zählt -- **AI-/LLM-Sichtbarkeit** – Markennennungen aus Presseartikeln fließen zunehmend in Google AI Overviews und LLM-Antworten ein, wo Sichtbarkeit von Autorität abhängt, nicht nur von klassischen Backlinks - -**Das ist das ehrliche, zukunftsfeste Verkaufsargument:** Sichtbarkeit, Reichweite und Auffindbarkeit – nicht „PageRank kaufen". - ---- - -## 4. Linktypen im Überblick - -|Element|Funktion|`rel` (systemseitig)| -|---|---|---| -|Firmen-Link im PM-Fließtext|Standard, immer möglich|`sponsored` / `nofollow`| -|**Unternehmens-CTA-Box** (Website, Newsroom, Kontakt) am PM-Ende|Hervorhebung, optisch abgesetzt|`sponsored` / `nofollow`| -|Link zur **Landingpage / Produktseite** (extern)|vom Kunden gewählt|`sponsored` / `nofollow`| -|Link zum **Unternehmensprofil auf dem Portal** (intern)|redaktionelle interne Verlinkung|**follow**| - -**Der unterschätzte Punkt – die interne Verlinkung:** Ein follow-Link auf das **portaleigene** Unternehmensprofil ist regelkonform (interner, redaktioneller Link) und stärkt die **eigene** Domain-Architektur. Der Kunde bekommt eine sichtbare „Über das Unternehmen"-Verlinkung; das Portal baut gleichzeitig seine interne Linkstruktur auf, statt fremde Autorität zu verschenken. - ---- - -## 5. Linkangabe & Linktyp-Auswahl im Editor - -**Anforderung:** Beim Erstellen einer PM gibt der Kunde Links an und wählt einen Linktyp. - -**Sauberes Design (Google-konform):** Der Kunde wählt **Ziel und Zweck** des Links – das System leitet daraus die korrekte `rel`-Auszeichnung ab. Die Begriffe „follow/nofollow" tauchen im Kunden-UI **nicht** auf. - -Editor-Flow beim Hinzufügen eines Links: - -1. **Ziel-URL** eingeben -2. **Link-Art** wählen (das ist die kundenseitige „Linktyp"-Auswahl): - -|Link-Art (Auswahl im Editor)|Beispiel|Systemseitige Auszeichnung| -|---|---|---| -|Unternehmens-Website|startseite.de|extern → `sponsored`/`nofollow`| -|Spezifische Landingpage / Produktseite|aktion.startseite.de|extern → `sponsored`/`nofollow`| -|Newsroom / Unternehmensprofil auf dem Portal|(interner Profil-Link)|intern → `follow`| -|Kontakt / Social-Profil|LinkedIn etc.|extern → `sponsored`/`nofollow`| - -3. **Darstellung** (optional, ggf. tarif-/boost-abhängig): Inline-Textlink **oder** hervorgehobene CTA-Box. Das betrifft die _Präsentation_, nicht den Link-Typ. - -**Entscheidung festgehalten:** Die Linktyp-Auswahl steuert **Ziel und Darstellung**, nie das `rel`-Attribut. Das `rel` ist systemgesteuert. Damit hat der Kunde maximale Freiheit bei Ziel und Hervorhebung, ohne dass die Domain-Sicherheit kippt. - ---- - -## 6. Was Produkt ist – und was tabu bleibt - -||Status| -|---|---| -|Links in der PM (extern, korrekt ausgezeichnet)|✅ Standard, kostenlos Teil der Veröffentlichung| -|Hervorgehobene CTA-Box / Linkdarstellung|✅ als Hervorhebungs-/Boost-Feature verkaufbar| -|follow-Link auf portaleigenes Unternehmensprofil|✅ regelkonform, stärkt eigene Domain| -|Sichtbarkeit / Reichweite / Platzierung|✅ das eigentliche Verkaufsargument| -|„Dofollow-Backlink" als bezahltes Upsell|❌ Link-Scheme-Verstoß, Domain-Risiko, gegen Anti-Zombie| -|Kundenseitiger follow/nofollow-Schalter|❌ nicht im UI, `rel` bleibt systemgesteuert| - ---- - -## 7. Anti-Zombie-Check (dieser Stand) - -- ✅ Keine versteckten SEO-Versprechen – verkauft wird Sichtbarkeit, nicht PageRank -- ✅ Domain-Glaubwürdigkeit langfristig geschützt (korrekte `rel`-Auszeichnung systemseitig) -- ✅ Kunde behält volle Freiheit bei Linkziel und Hervorhebung -- ✅ Regelkonform gegenüber Google-Spam-Richtlinien, kein Graubereich -- ✅ Interne Verlinkung baut eigenes Asset statt fremde Autorität zu verschenken - ---- - -## 8. Offene / spätere Punkte - -- **Darstellungs-Stufung:** Soll die hervorgehobene CTA-Box ein eigenes Boost-/Tarif-Feature sein oder Standard? (Hängt am Boost-Konzept.) -- **Anzahl Links pro PM:** Sinnvolle Obergrenze definieren (gegen Link-Spam in der PM selbst, z. B. Profil + Website + 1–2 Kontextlinks). -- **Anchor-Text-Regeln:** Optional späterer Hinweis/Soft-Check gegen übermäßige Exact-Match-Anchors (Spam-Signal), eher Phase 2. - ---- - -## 9. Korrektur am vorherigen Decision-Update - -Im Dokument „Preisstruktur & Veröffentlichungs-Flow", Abschnitt 4, wird der Eintrag - -> „Bewusst ausgeschlossen: Verkaufte Dofollow-Backlinks." - -ersetzt durch: - -> „Verlinkung: Links zur Kundenseite sind Standard-Bestandteil jeder PM, systemseitig als `sponsored`/`nofollow` ausgezeichnet. Hervorhebung der Linkdarstellung ist als Produkt-Feature möglich. **Tabu:** Verkauf von Dofollow-Backlinks und kundenseitige `rel`-Auswahl. Details siehe Decision-Update „Verlinkung & Backlinks"." - ---- - -_SEO-/Richtlinien-Stand: Google-Spam-Policies inkl. Link-Spam-Enforcement 2024–2026; `nofollow`/`sponsored`/`ugc` als Hinweise seit September 2019. Vor produktiver Umsetzung der `rel`-Logik einmal gegen die dann aktuelle Google-Search-Central-Doku gegenprüfen._ ---- - -## 10. Umsetzungsstand (12.06.2026) - -**Umgesetzt:** - -- `PressReleaseLinkPolicy` (app/Services/PressRelease/): systemseitige - `rel`-Auszeichnung beim Rendern — extern → `sponsored nofollow noopener` - + `target="_blank"`; portalintern (konfigurierte Domains aus - `config/domains.php` inkl. www-Variante, relative Pfade) → **follow**; - `mailto:`/`tel:` → ohne `rel`/`target`. Autoren-`rel` wird immer - überschrieben (kein kundenseitiger Hebel). Greift in - `PressReleaseHtmlSanitizer::render()` und wirkt damit rückwirkend auf - alle gespeicherten Inhalte und auf jede Ausgabe (Panel-Vorschau heute, - Web-Detailseiten beim Relaunch). -- Editor-Hinweis (PM anlegen/bearbeiten): Links erwünscht, Auszeichnung - automatisch — bewusst ohne follow/nofollow-Auswahl im UI. -- §9-Korrektur im Decision-Update „Preisstruktur & Veröffentlichungs-Flow" - (Abschnitt 4) eingearbeitet. - -**Offen (wie in §8 vorgesehen):** CTA-Box/Darstellungs-Stufung (hängt am -Boost-Konzept, 9I), Link-Obergrenze pro PM, Anchor-Text-Soft-Check -(Phase 2). Die Linktyp-Auswahl im Editor ist fürs `rel` nicht nötig -(systemseitig aus der Ziel-URL abgeleitet) — sie wird relevant, sobald die -CTA-Box als Darstellungs-Option kommt.