Kevin Adametz eb658020e5 press-releases: assign-canonicals leert Seiten- und Sitemap-Caches; dev: Live-Lauf 21.09.2026 protokolliert (9.221 Paare)

Der Nachlauf über den Bestand änderte rel=canonical und die Sitemap-Auswahl,
ließ aber gecachte Meldungsseiten (1 h stale) und Sitemap-Caches (1 h)
stehen. Nach einem Lauf mit Änderungen wird WebCaches::forgetPublicPages()
aufgerufen; der Test prüft das über den vorher gecachten Sitemap-Stand.

Protokoll Teil 11: Nachtrag Live-Deploy (hash-content 179.619,
duplicates-report 9.221 Paare / 1.468 seit 07/2026, assign-canonicals
9.223/9.221, basiswert-0.1.json auf dem Server), Anhang 2 1c.7/1c.8 mit
Live-Zahlen, Basiswerte 0.1 mit Hinweis auf die noch zu holende Datei.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

2026-09-21 13:05:43 +00:00

7.6 KiB

Raw Blame History

Anhang 2 zur Roadmap Nutzergewinnung — Doppelveröffentlichung und Quellenauskunft

Stand: 17.09.2026 Ergänzt: Block 1c und 1d Anlass: Über die API wird für beide Portale eingereicht, häufig dieselbe Meldung. Die Search-Console-Properties sind seit 17.09.2026 für presseecho.de, businessportal24.com und pressekonto.com bestätigt; damit wird der Effekt erstmals messbar.

1. Sachlage

Liegt derselbe Text auf zwei Adressen, wählt Google eine davon als maßgeblich und filtert die andere aus dem Index. Das ist kein Nachteil im Sinne einer Abwertung, sondern eine Auswahl. Die Folge betrifft zwei Seiten unterschiedlich stark:

Betroffen	Auswirkung
Die Portale	Crawl-Aufwand für Seiten, die nicht erscheinen; über den Bestand ein hoher Anteil ausgefilterter URLs
Die einreichende Firma	Die Meldung existiert in der Suche einmal statt zweimal, ohne Einfluss darauf, welche Fundstelle das ist

Für Leser, Feeds, interne Suche und Newsroom zählen weiterhin beide Fassungen. Nur in der Suchmaschine zählt eine.

Derzeitiger Zustand: Die Auswahl trifft der Algorithmus. Das Portal erfährt nicht, wie sie ausgefallen ist.

2. Sichtbar wird es über zwei Felder

Die URL-Prüfung der Search Console liefert:

Feld	Bedeutung
`userCanonical`	die Adresse, die das Portal als maßgeblich angibt
`googleCanonical`	die Adresse, die Google als maßgeblich behandelt

Weichen beide voneinander ab, hat Google eine andere Quelle gewählt. Das kann die eigene zweite Fassung sein oder ein fremdes Portal aus derselben Verteilerausspielung.

Schneller als über die API geht es zunächst über eine Bestandsabfrage nach identischen Titeln oder Textprüfsummen auf beiden Portalen. Das beantwortet die Mengenfrage, ohne auf Crawl-Daten zu warten.

3. Neue Arbeitspakete in 1c

Nr.	Arbeitspaket	Aufwand	Abhängigkeit
~~1c.7~~	Doppelveröffentlichung erheben — gebaut 17.09.2026: `content_hash`, `press-releases:hash-content`, `press-releases:duplicates-report`. Befund Dev: 9.092 Paare = 53 % des Archivs (Protokoll Teil 9); Live 21.09.2026: 9.221 Paare = 18.442 URLs, 1.468 davon seit 07/2026	S	keine
~~1c.8~~	Kanonische Zuordnung — gebaut 17.09.2026, seit E9 aktiv, Bestand live zugeordnet 21.09.2026 (9.221 Paare; Protokoll Teil 11, Nachtrag Live-Deploy): `CanonicalAssigner`, `canonical_press_release_id`, Zuordnung bei Veröffentlichung + `press-releases:assign-canonicals`; rel=canonical, mainEntityOfPage, Sitemaps nur Erstquelle. Schalter `CANONICAL_ASSIGNMENT_ENABLED`	M	1c.7
~~1c.9~~	Quellenauskunft — gebaut 17.09.2026, hinter `GSC_CUSTOMER_VISIBLE`: `user_canonical` gespeichert, `sourceVerdict()` (eigene / andere eigene Fassung / fremdes Portal), Text im Block „Google-Index"	S	1c.4, 1c.8

Zur Auswahl in 1c.8

Weg	Wirkung	Preis
Nur ein Portal je Meldung, Zuordnung über die Kategorie	nichts wird ausgefiltert	eine Veröffentlichung weniger
Beide Portale, zweite Fassung mit `rel=canonical`	Portal bestimmt die Erstquelle, Leser sehen weiterhin beide	Umsetzungsaufwand
So lassen	Google entscheidet, ohne Rückmeldung	Kontrollverlust

Empfohlen ist der mittlere Weg. Die Zuordnung folgt der Kategorie: Wirtschafts- und Unternehmensthemen kanonisch auf businessportal24.com, breite Themen auf presseecho.de, die jeweils andere Fassung verweist darauf.

Technisch am Import ansetzen: Prüfsumme über den Text bilden, bei Treffer wird die zweite Fassung mit Verweis angelegt. Wirkt auch rückwirkend über den Bestand.

Offene Entscheidung E9: welche Kategorie welchem Portal kanonisch zugeordnet wird. Vorschlag in config/canonical.php; „sonstiges" (3.087 Paare) entscheidet das Verhältnis.

4. Reihenfolge ist nicht verhandelbar

1c.8 steht vor 1c.9 und vor jeder Auskunft an Kunden. Solange im eigenen Haus zwei identische Fassungen ohne Zuordnung stehen, kann kein Hinweis an Einreicher gegeben werden, ohne unglaubwürdig zu wirken.

5. Folge für die Beschreibung des Angebots

Zwei Portale bedeuten zwei Fundstellen für Leser, nicht zwei Fundstellen in der Suche. Wo das bisher anders dargestellt ist — Preisseite, Leistungsbeschreibung, Benachrichtigungstexte —, gehört es korrigiert, bevor die Quellenauskunft live geht.

6. Die Auskunft als Service (Ergänzung zu 1d)

Quellenauskunft als Service: Der Abgleich von googleCanonical und userCanonical zeigt nicht nur, welche der eigenen Fassungen gewonnen hat, sondern auch, wenn ein fremdes Portal als Quelle geführt wird. Diese Auskunft gibt sonst niemand und beantwortet die Frage, warum eine Meldung trotz vieler Fundstellen nicht auffindbar ist.

Wo sie steht

Ort	Inhalt
Absenderansicht	welche Adresse Google als maßgeblich führt, mit Datum
Hilfeseite (1d.1)	Abschnitt: warum eine Meldung mehrfach im Netz steht und nur einmal in den Ergebnissen
Benachrichtigungsmail	nichts davon, sonst kippt der Charakter der Mail

Die Empfehlung, die dazugehört: Die Erstveröffentlichung gehört auf die eigene Website des Unternehmens; die eigene Domain ist die stabilste Quelle, die eine Firma hat. Portale kommen danach. Das schmälert das eigene Geschäft nicht, weil über die eigene Website niemand Verbreitung bekommt.

Grenze der Auskunft

Keine Aussage darüber, warum Google eine bestimmte Fassung gewählt hat. Das ist nicht bekannt.
Keine Formulierung, die nahelegt, dass eine Direktveröffentlichung das Problem löst. Sie verbessert die Ausgangslage, weil eine geprüfte Erstfassung mit strukturierten Daten und stabiler Adresse bessere Voraussetzungen hat als eine Verteilerkopie. Garantiert ist nichts.
Der offene Satz, dass sich das nicht garantieren lässt, macht die Auskunft glaubwürdiger, nicht schwächer.

7. Nebenbefund: pressekonto.com

Die Property ist angelegt, wird für die Indexierungsprüfung aus 1c.4 aber nicht gebraucht — das Tageskontingent geht an die beiden Portale. Zwei Dinge sind dort trotzdem zu prüfen:

~~Stehen Konto- und Login-Bereiche auf noindex?~~ 17.09.2026: ja, jetzt per Meta-Tag in allen Portal-Layouts. Die Indexierungsübersicht der neuen Property zeigt, was Google von dort erfasst hat.
~~Offene Entscheidung E10~~ Entschieden 18.09.2026: Portale führen, presseecho als Standard; die API-Doku bleibt beim Hub, Rechtstexte je Host. Dabei aufgefallen und behoben: /de/preise, /de/veroeffentlichen, /de/newsrooms und /de/suche wurden unter pressekonto.com mit dem Branding von businessportal24 ausgeliefert — jetzt 301 auf presseecho. ~~Offen: Kategorie-, Archiv- und Meldungsadressen sind auf dem Hub weiterhin erreichbar~~ — erledigt 18.09.2026 nach Freigabe (Commit 24c1bbf): 301 aufs Portal des Eintrags, bei gleichem Slug auf die Erstquelle, unbekannter Slug bleibt 404, nur GET (Protokoll Teil 10). Feeds (3.1) leiten genauso.

8. Neue offene Entscheidungen

Nr.	Frage	Betrifft
E9	Entschieden 18.09.2026: Zuordnung wie vorgeschlagen (businessportal24: finanzen, handel, it, recht, wissenschaft-forschung, motor-verkehr; presseecho: alle übrigen inkl. sonstiges). Zuordnung ist aktiv, `CANONICAL_ASSIGNMENT_ENABLED` steht standardmäßig auf true	1c.8
~~E10~~	Entschieden 18.09.2026: Portale führen — presseecho für faq, hilfe, gute-pressemitteilung und die vier Transparenzseiten, pressekonto für die API-Doku. Rechtstexte bleiben bewusst je Host (eigene Anbieterkennzeichnung, eigener Meldeweg). Sitemap und llms.txt nennen nur die führende Adresse (Protokoll Teil 10)	2.4

7.6 KiB Raw Blame History