65 lines
No EOL
4.2 KiB
Markdown
65 lines
No EOL
4.2 KiB
Markdown
|
||
**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 |