Kevin Adametz
4edb915a9a
Über die API kommt praktisch jede Meldung zweimal, je Portal eine Zeile mit gleichem Text: 9.092 Paare, 53 % des Archivs, bisher jede Fassung self-canonical und in beiden Sitemaps — Google wählte. 1c.7: press_releases.content_hash (SHA-256 über Titel + Text ohne Markup), gesetzt beim Speichern, Bestand per press-releases:hash-content (Query-Builder, Blöcke). Migration in zwei Statements — ADD COLUMN INSTANT, ADD INDEX INPLACE, kein Rebuild. press-releases:duplicates-report zählt Paare je Hauptkategorie. 1c.8: canonical_press_release_id + CanonicalAssigner. Erstquelle folgt der Kategorie (config/canonical.php, Vorschlag zu E9), sonst die zuerst veröffentlichte Fassung. Zuordnung bei jeder Veröffentlichung und über den Bestand (press-releases:assign-canonicals). Die Kopie trägt rel=canonical und mainEntityOfPage auf die Erstquelle; Sitemap und News-Sitemap nennen nur sie; Leser sehen weiterhin beide. Alles hinter CANONICAL_ASSIGNMENT_ENABLED (false), bis E9 entschieden ist. 1c.9: user_canonical in den Index-Prüfungen, sourceVerdict() unterscheidet eigene Adresse / andere eigene Fassung / fremdes Portal; Anzeige im Block „Google-Index" hinter GSC_CUSTOMER_VISIBLE, ohne Aussage über das Warum. Dazu: Abschnitt zur einen Quelle auf /gute-pressemitteilung (Verteiler → viele Kopien, eigene Website zuerst, keine Garantie), noindex in Admin-, Kunden- und Auth-Layouts, UmamiSnippetTest von der lokalen .env gelöst. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| 2026-09-01 | ||
| archive | ||
| betrieb | ||
| lagacy-rechnungen | ||
| README.md | ||
| roadmap.md | ||
dev/ — Projekt- und Betriebsdokumentation
Stand: 20.07.2026 — das System ist live (pressekonto.com, presseecho.de, businessportal24.com). Die Struktur trennt aktive Betriebs-/Planungsdoku von abgeschlossenen Phasen (Archiv).
Aktiv
| Pfad | Inhalt |
|---|---|
betrieb/deploy-runbook.md |
Deploy- und Betriebs-Runbook (SFTP-Deploy-Checkliste, Worker, Scheduler, Stripe-Webhook, Rollback) — erste Anlaufstelle für alles Operative |
betrieb/api-legacy-paritaet.md |
Verhaltens-Referenz der Legacy-API-Kompatibilitätsschicht (/service/…) — lebendes Dokument, solange Alt-Integrationen (Connektar) die Pfade nutzen |
betrieb/umami.md |
Umami-Analytics-Snippets je Domain |
roadmap.md |
Offene Punkte und nächste Entwicklungen/Optimierungen |
Lokal / gitignored (bleiben liegen, nicht committen)
| Pfad | Inhalt |
|---|---|
migration/ |
Medien-Staging der Legacy-Migration (~7 GB Uploads beider Altportale) — Quelle für legacy:migrate-media; behalten, bis das Alt-System endgültig abgeschaltet und ein Server-Backup gezogen ist |
api/ |
Postman-Collection (enthält API-Keys!) und Activity-Log-Auswertungen der Alt-APIs |
archive/migration-2026/sql/ |
Legacy-DB-Dumps (Snapshots vom 23.04.2026) |
Archiv (archive/)
Abgeschlossene Phasen, als Historie/Referenz erhalten:
optimize/— System-Optimierungsphasen 0–6 und das Cutover-Runbook der Legacy-Migration (erledigt 20.07.2026; enthält weiterhin die Anleitung für--since-Delta-Läufe, falls das Alt-System noch einmal Daten liefert)release/— Release-Entwicklungsplan, manuelle QA-Checkliste, Boost-Platzierungs-Entscheidungmigration-2026/— Analyse- und Planungsdoku der Legacy-Migration (Datenmodell, Merge-Strategie, API-Kunden, Fortschritt)frontend/+frontend-audits/— Frontend-Konzepte und die Responsive-/Mobile-Audits vom 16.07.agentur-attribution/,legacy_logging/,legacy_performance/,_old/— ältere Einzelthemen bzw. Altsystem-Reste