4.2 KiB
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)
- 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.
- Canonical-Tags sauber setzen. Rein technisch, keine laufenden Kosten. Jede PM erhält ihre eigene kanonische URL – saubere SEO-Hygiene statt aktivem Prüfprozess.
- 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