betrieb: Logs je Thema in Tagesdateien (billing, ki, monitoring, market); Doku: Duplicate-Content-Decision durch Anhang 2 abgelöst
- config/logging.php: Themen-Channels billing, ki, monitoring, market als daily-Dateien mit gemeinsamer Aufbewahrung (LOG_DAILY_DAYS), Stack-Default auf daily; Channel `testing` für die Suite. - Fachliche Log-Aufrufe in Billing, KI-Jobs, OperationalAlert und Kursdaten auf Log::channel() umgestellt. - phpunit.xml + TestCase: Suite schreibt ausschließlich nach testing-YYYY-MM-DD.log; LogChannelsTest sichert die Konfiguration. - docs/weiteres: Decision-Update Duplicate-Content entfernt (überholt durch Roadmap-Anhang 2), Decision-Update Verlinkung & Backlinks als Referenz wieder abgelegt, README-Index nachgezogen. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
parent
b8c6af5f10
commit
2ec61697b0
21 changed files with 338 additions and 107 deletions
|
|
@ -41,10 +41,10 @@ Sie verlinkt die zentralen Dokumente und sortiert sie nach „Was ist der aktuel
|
|||
### `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 „Duplicate-Content & Duplicate-Checking" (12.06.2026, „nichts bauen, nur Canonical-Hygiene") ist überholt und entfernt (18.09.2026): Die API reicht dieselbe Meldung auf beiden Portalen ein, deshalb gibt es seit Anhang 2 der Roadmap (`dev/2026-09-01/roadmap-anhang2-2026.md`) Textprüfsumme, kanonische Zuordnung je Kategorie und Quellenauskunft.
|
||||
- [`Detailplan Umsetzung Launch-Slice (Magic-Link, Compliance, Bestandsschutz, Auth).md`](./weiteres/Detailplan%20Umsetzung%20Launch-Slice%20%28Magic-Link%2C%20Compliance%2C%20Bestandsschutz%2C%20Auth%29.md) — konkreter Umsetzungsplan (WS-1 bis WS-8) aus den beiden Decision-Updates + Merkliste; verbindliche Entscheidungen vom 15.06.2026 (Legacy-Posten bleiben, Pflicht-E-Mail-Verifizierung, Socialite freigegeben). **In Umsetzung** (WS-1, WS-6 ohne Google, WS-2 erledigt).
|
||||
- [`Sicherheit & Deployment-Hinweise (Auth, Rollen, Verifizierung).md`](./weiteres/Sicherheit%20%26%20Deployment-Hinweise%20%28Auth%2C%20Rollen%2C%20Verifizierung%29.md) — **deployment-kritisch:** Reihenfolge der Migrationen (Verifizierungs-Backfill, Legacy-Rollen-Downgrade), der Sicherheits-Fix der Editor-Überberechtigung, Firmen-Scope-Verhaltensänderung und der Magic-Link-Kontaktzugang. Feed für die Live-Deployment-Checkliste (WS-7).
|
||||
- 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.
|
||||
- [`Decision-Update Verlinkung & Backlinks in Pressemitteilungen.md`](./weiteres/Decision-Update%20Verlinkung%20&%20Backlinks%20in%20Pressemitteilungen.md) — systemseitige `rel`-Auszeichnung (`sponsored nofollow`), kein Verkauf von Dofollow-Backlinks. **Umgesetzt** (`PressReleaseLinkPolicy`, 12.06.2026); Kurzfassung in §4 des Preisstruktur-Decision-Updates. Als Referenz wieder abgelegt (18.09.2026), weil die Transparenzseite „kostenlos veröffentlichen" die Link-Policy erklärt.
|
||||
|
||||
### `user-admin/` — User-/Admin-Backend
|
||||
|
||||
|
|
|
|||
|
|
@ -1,65 +0,0 @@
|
|||
|
||||
**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
|
||||
|
|
@ -0,0 +1,145 @@
|
|||
|
||||
|
||||
**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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue