web: Doppelveröffentlichung — Prüfsumme, kanonische Zuordnung (aus bis E9), Quellenauskunft, noindex im Portal (Anhang 2)

Ü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>
This commit is contained in:
Kevin Adametz 2026-09-17 16:09:16 +00:00
parent 87558aba4f
commit 4edb915a9a
28 changed files with 1231 additions and 11 deletions

View file

@ -159,6 +159,12 @@ return [
'images_format' => 'Format',
'images_format_text' => 'JPG, PNG or WebP, large enough for third-party use; landscape works best in most layouts.',
'source_heading' => 'Why a release appears many times on the web and only once in search results',
'source_p1' => 'Anyone who sends a press release through a distribution service will find it word for word on many portals afterwards. For readers, that is many places to find it. For a search engine it is one text, and it picks one address as the authoritative one — the others do not appear in the results. That is a selection, not a penalty. Which version is chosen is decided by the algorithm; portals and senders only see the outcome, not the reason.',
'source_p2' => 'The same applies between presseecho and businessportal24: if a release appears on both portals, that is two places for readers, not two places in search.',
'source_p2_assigned' => 'So that chance does not decide, the second version here points to the first — the original source follows the subject area of the release.',
'source_p3' => 'The most stable source a company has is its own website. Publishing a release there first and then on portals keeps the original version under your own control. That takes nothing away from what portals do: nobody gets distribution through their own website.',
'source_p4' => 'A directly submitted, reviewed release with structured data and a stable address has better prerequisites to be treated as the source than a distributed copy. That cannot be guaranteed — by anyone.',
'more_heading' => 'Further reading',
'more_guidelines' => 'Publishing guidelines — the categories we check against',
'more_publish' => 'Publishing — from draft to release',