presseportale/dev/2026-09-01/umsetzung-protokoll.md

Umsetzungsprotokoll — Abarbeitung von bestandsaufnahme-code.md, Abschnitt 7

Stand: 01.09.2026 Bezug: bestandsaufnahme-code.md (Befund-Nummern H1–H4, M1–M9, P1, L1–L9)

Jeder Abschnitt hält fest: was war der Befund, was wurde geändert, wie ist es abgesichert. Abweichungen von der ursprünglich vorgeschlagenen Reihenfolge oder Lösung sind ausdrücklich vermerkt.

---

Ausgangsstand

Prüfung	vorher
php artisan test	1479 grün, 1 übersprungen
vendor/bin/pint --test	passed
vendor/bin/phpstan analyse	390 Fehler außerhalb der Baseline

---

Block A — vor dem nächsten Deploy

Schritt 1 — H1: Suchausfall im Deploy-Fenster

Befund: PressReleaseSearchIndex::isAvailable() cachte seine Antwort eine Minute. Stand dort false, während die Migration die Volltext-Indizes von press_releases entfernte, setzte der Rückfallpfad sein MATCH() weiter auf die Tabelle ab, an der es keinen Index mehr gab → MySQL-Fehler 1191, 500er auf jeder Suche der Web-Seite und der Admin-PM-Liste.

Geändert

• app/Models/PressReleaseSearchIndex.php
  • Cache-Key als Konstante AvailabilityCacheKey herausgezogen.
  • isAvailable() cacht die beiden Antworten unterschiedlich lange: true (Dauerzustand nach dem Umstieg) 60 s, false (gilt nur während des Umstiegs) 5 s. Die Prüflogik steckt jetzt in resolveAvailability().
  • Neu: forgetAvailability().
• database/migrations/…_create_press_release_search_table.php und …_drop_fulltext_indexes_from_press_releases.php rufen forgetAvailability() in up() und down() auf. Das ist der eigentliche Fix; die kurze TTL ist das Netz für einen Eingriff von Hand.

Abweichung vom Vorschlag: Der Bericht schlug zusätzlich vor, den Rückfallpfad gegen QueryException abzusichern. Nicht umgesetzt — constrain() baut die Abfrage nur auf, ausgeführt wird sie später vom Aufrufer. Ein try/catch an dieser Stelle könnte den Fehler gar nicht sehen. Die Cache-Invalidierung in der Migration deckt den Fall vollständig ab.

Abgesichert: drei neue Tests in tests/Feature/PressReleaseSearchIndexTest.php (kurze TTL bei false, lange bei true, Wirkung von forgetAvailability()).

---

Schritt 2 — H2: Cache-Flush in der Schleife

Befund: CompanyRemovalService::markGone($company, includePressReleases: true) lud alle Mitteilungen der Firma per get() und rief je Zeile PressReleaseService::markGone(), das jedes Mal sämtliche Seiten- und Sitemap-Caches verwarf. Bei 300 Meldungen: 301 Vollinvalidierungen auf einen Admin-Klick, dazu die unbegrenzte Ergebnismenge im Speicher.

Geändert

• PressReleaseService::markGone() / restoreFromGone() bekommen bool $flushPublicPages = true. Das Standardverhalten bleibt unverändert.
• CompanyRemovalService::markGone() iteriert mit chunkById(200) statt get() und übergibt flushPublicPages: false. Der eine Flush am Ende der Methode bestand bereits und genügt.

Abgesichert: GoneTombstoneTest → „cascading a newsroom removal flushes the page cache once, not per release" (drei Mitteilungen, Generations-Zähler steigt um genau 1).

---

Schritt 3 — H3 + H4: Umkehrbarkeit von gone_at

Befund: markGone() überschrieb companies.is_active (→ false) und press_releases.no_export (→ true), ohne den Vorzustand zu sichern. Das Aufheben setzte beide pauschal auf den Normalzustand zurück. Eine Firma, die schon vorher deaktiviert war, stand danach öffentlich in Newsroom-Übersicht und Sitemap; eine Mitteilung blieb dauerhaft als „kein Export" markiert. Die Oberfläche verspricht an beiden Stellen ausdrücklich Umkehrbarkeit.

Geändert

• Neue Migration 2026_09_01_090000_add_gone_restore_state_to_companies_and_press_releases_tables.php: companies.is_active_before_gone und press_releases.no_export_before_gone, beide boolean nullable. null = nicht entfernt bzw. bereits zurückgenommen. Idempotent über Schema::hasColumn().
• Company und PressRelease: $fillable + casts() ergänzt.
• CompanyRemovalService::markGone() sichert is_active, restoreFromGone() stellt es wieder her (?? true als einzige mögliche Annahme für Altfälle ohne Merker).
• PressReleaseService::markGone()/restoreFromGone() analog für no_export. Fehlt der Merker, bleibt der aktuelle Wert stehen — raten wäre schlechter als nichts zu tun.

Zur Kostenfrage der Migration: Auf press_releases ist das ADD COLUMN seit dem Entfernen der Volltext-Indizes ein ALGORITHM=INSTANT. companies trägt seinen FULLTEXT-Index weiterhin und wird kopiert — bei 70 MB wenige Sekunden, wie in CLAUDE.md als vertretbar festgehalten. Die Migration ist bewusst nach drop_fulltext_indexes_from_press_releases datiert.

Verworfene Alternative: is_active in markGone() gar nicht anzufassen und stattdessen überall auf gone_at zu filtern. Dafür hätten 12 Abfragen in app/Services/Web/, SitemapController und AuthorizesPressReleaseMediaAccess angefasst werden müssen — eine übersehene Stelle hätte einen entfernten Newsroom öffentlich gelassen. Der Merker ist die kleinere Angriffsfläche.

Abgesichert: drei neue Tests in GoneTombstoneTest (inaktive Firma bleibt nach dem Aufheben inaktiv; no_export wird zurückgesetzt; ein vorher gesetztes no_export bleibt bestehen).

---

Schritt 4 — M5: Watermark-Migration umging den AppSetting-Cache

Befund: Die Migration schrieb die Wasserstandsmarke per Query Builder, AppSetting::getValue() cacht aber dauerhaft (rememberForever). Lief der Scheduler-Task im Deploy-Fenster schon einmal, hielt der Cache die alte, niedrigere Marke — der nächste Lauf hätte die Ereignisse dazwischen ein zweites Mal auf press_releases.hits addiert.

Geändert

• AppSetting::forgetCached(string $key) als öffentliche Methode; setValue() benutzt sie jetzt selbst.
• …_seed_press_release_view_watermark.php ruft sie in up() und down() auf.

---

Block B — Werkzeug

Schritt 5 — P1: Statische Analyse wieder in Betrieb

Befund: 390 Fehler außerhalb der Baseline, davon der größte Teil Falschmeldungen: Larastan löste keinen einzigen Cast auf, weil alle 49 Models ihre Casts über die casts()-Methode deklarieren (Laravel-11-Stil) und Larastans Schalter parseModelCastsMethod per Default false ist. $pressRelease->status galt als string, jeder Enum-Vergleich als „immer falsch". Zusätzlich: Baseline seit dem 12.05.2026 unverändert, composer analyse in keiner Pipeline.

Geändert

1. phpstan.neon: parseModelCastsMethod: true, mit Begründung im Kommentar. Wirkung: 390 → 266 Meldungen.
2. 102 Relations-Annotationen in app/Models/*.php ergänzt — jede BelongsTo/HasMany/HasOne/BelongsToMany/MorphTo-Methode hat jetzt ihr @return …<Related, $this>. Das war die zweite Sammelursache: Ohne Generics landete PHPStan auf Illuminate\…\Model und meldete jede Modell-Eigenschaft und jeden Scope als unbekannt. Wirkung: 266 → 169, property.notFound von 84 auf 12. Nebeneffekt: dieselbe Verbesserung in der IDE-Vervollständigung.
3. Aufräum-Funde vorgezogen (siehe Schritt 5b).
4. Baseline neu erzeugt: 166 Einträge / 188 Meldungen (vorher 127 Einträge plus 390 ungefasste Meldungen). vendor/bin/phpstan analyse meldet jetzt No errors.
5. .github/workflows/tests.yml: neuer Schritt „Run Static Analysis" vor den Tests. Ohne Gate driftet die Baseline erneut.

Was bewusst in der Baseline bleibt und warum

Anzahl	Art	Grund
66	property.notFound	withCount-Aliasse (recent_releases_count) und Closure-Parameter, die als blankes Builder typisiert sind. Behebbar nur mit @param Builder<PressRelease> an jeder Closure — viel Rauschen für keinen Erkenntnisgewinn.
34	nullsafe.neverNull	?-> auf Werten, die seit der Cast-Auflösung nachweislich nicht null sind. Stilfrage, kein Fehler.
18	method.notFound	Eigene Scopes (forPortalValues(), visibleInArchive()) auf denselben blanken Closure-Buildern.
10	trait.unused	Falschmeldung: app/Livewire/Concerns/* wird ausschließlich aus Volt-Single-File-Komponenten in resources/views/livewire/**.blade.php eingebunden, die PHPStan nicht analysiert. Nachgeprüft, die Traits sind in Benutzung.
9	class.notFound	Legacy-Migrationsmodelle (App\Models\Legacy\…) und Laravel\Cashier\Concerns\Stripe\TaxId.
5+2+2	instanceof.alwaysTrue / property.onlyWritten / method.unused in ProcessStripeWebhook	Falschmeldungs-Kaskade: Cashier typisiert findBillable() gegen den Trait Billable. PHPStan kann den nicht mit User vereinbaren, hält deshalb if (! $user instanceof User) return; für immer wahr und alles danach für unerreichbar — inklusive der Stellen, an denen $this->activityLog und $this->numbers gelesen werden. Die Laufzeitprüfung ist richtig und bleibt.

Korrektur zur Bestandsaufnahme: Befund L6 („ProcessStripeWebhook: $numbers und $activityLog injiziert, nie gelesen") war falsch. Beide werden in den Zeilen 123, 149, 257 und 293 verwendet; die Meldung ist ein Folgefehler der oben beschriebenen Cashier-Kaskade. Nichts entfernt.

---

Schritt 5b — Aufräum-Funde L1–L5 und M7 (vorgezogen)

Warum vorgezogen: Diese Funde stammen aus der statischen Analyse. Hätte ich die Baseline vor ihrer Behebung erzeugt, wären sie zugedeckt gewesen — und ihre spätere Behebung hätte die Baseline sofort wieder ungültig gemacht (ignore.unmatched). Sie gehören deshalb vor den Baseline-Neuaufbau, nicht in Schritt 9.

Fund	Datei	Änderung
L1	ProofPdfRenderer::renderOverview()	if ($embed === null || $image === null) → if ($embed === null). $embed ist bereits null, wenn $image null ist.
L3	ManualInvoiceService::invoiceFor()	Prüfung current_period_end === null entfernt — die Spalte ist date() NOT NULL.
L4	Company::logoUrl()	if ($legacyPortal && filled($logoFilename)) → if (filled($logoFilename)). $legacyPortal fällt auf $this->portal->value zurück und ist damit immer gesetzt.
L5	RecordMailActivity::recordSent()	getTo() ?? [] → getTo(). Die Symfony-Methode liefert immer ein Array.
—	PressReleasePreviewController	$magicLink->expires_at && …->isPast() → …->isPast(). magic_links.expires_at ist NOT NULL.
—	RetireAgencyCompanyType	if (! $isNewsroom && $isProtected) → if (! $isNewsroom). Der Zweig darüber endet für den Gegenfall immer mit continue.
—	MigrateLegacyMedia::selectedTypes()	@return list<'company-logos'|'press-release-images'> ergänzt. Damit ist das match ohne default nachweislich vollständig statt nur faktisch.

M7 — Legacy-API konnte portal = null schreiben (ebenfalls vorgezogen, weil derselbe Sachverhalt):

• ResolvesRequestedPortal::resolveRequestedPortal() gibt jetzt ein nicht-nullbares Portal zurück; letzte Stufe ist Portal::Both — exakt der Default, den beide portal-Spalten ohnehin tragen. Vorher konnte die Methode null liefern, was als SQL-Fehler und damit als 500er beim Alt-Client gelandet wäre; PressReleaseController:53 hätte sogar einen Fatal Error ausgelöst, weil es das Ergebnis direkt mit ->value weiterreicht.
• LegacyPressReleaseController und LegacyCompanyController: ?->value → das Enum bzw. ->value direkt.
• PressRelease::publicPortalLinks(): der unerreichbare null =>-Arm im match entfällt.
• PressRelease::booted() und LegacyPressReleaseController weisen jetzt das Enum statt des Rohwerts zu — die Spalten sind darauf gecastet.

Bewusst NICHT geändert: ProofPdfRenderer:946 ($width < 1 || $height < 1 nach imagesx()/imagesy()). Laut PHPStan-Stub tot, zur Laufzeit eine Schutzprüfung in der Bildverarbeitung des Rechtsnachweis-PDFs. Für null funktionalen Gewinn wird dort keine Absicherung entfernt — Meldung baseliniert.

---

Block C — Voraussetzungen für die Roadmap

Schritt 6 — M9: Bounce-Suppression vervollständigt

Befund: newsletter:import-bounces erfasste ausschließlich users und protokollierte alles Übrige als „ohne User-Konto". Die zweite Empfängerliste newsletter_subscriptions — die öffentliche Anmeldung auf den Portalen, mit eigenem unsubscribed_at und eigener Synchronisierung nach außen — blieb unberührt. Die meisten Einträge dort haben gar kein Konto, wurden also gar nicht erreicht. Die Roadmap macht „Bounce-Suppression produktiv" zum Blocker für 1b.6, 1d.3 und 3.2.

Geändert (app/Console/Commands/ImportNewsletterBounces.php)

• Aufgeteilt in suppressUsers() und suppressSubscriptions(); beide melden zurück, ob die Adresse in ihrer Liste stand.
• „Ohne User-Konto" gilt jetzt erst, wenn die Adresse in keiner der beiden Listen steht.
• Anmeldungen werden scope-frei über alle Portale gesucht (der CLI-Lauf hat keinen Portal-Kontext, eine Adresse kann auf beiden Portalen stehen), bekommen unsubscribed_at, laufen durch NewsletterSyncService (damit die Abmeldung auch beim externen Versender ankommt) und landen mit method: bounce im Aktivitäts-Verlauf.
• Eigene Ergebniszeile für die Anmeldungen; --dry-run deckt beide Listen ab.
• L9 gleich mit erledigt: Der Vergleich läuft über whereRaw('LOWER(email) = ?') wie in User::findByEmail(). Bounce-Listen kommen aus dem Mailserver-Log und geben die Adresse so wieder, wie der Absender sie geschrieben hat.

Abgesichert: vier neue Tests (Anmeldung ohne Konto wird abgemeldet; Idempotenz beim zweiten Lauf; alle Portale einer Adresse; Dry-Run; Groß-/Kleinschreibung).

---

Schritt 7 — M4: Aufbewahrung press_release_events

Befund: Die Tabelle nimmt seit dem Umbau des Aufruf-Zählers jeden Seitenaufruf auf (Bestand knapp eine Million) und war als einzige Log-Tabelle des Systems ohne Bereinigung.

Geändert

• Neu config/press_releases.php: events.retention_days, Default 395 Tage (13 Monate), überschreibbar per PRESS_RELEASE_EVENTS_RETENTION_DAYS.
• Neu app/Console/Commands/PurgePressReleaseEvents.php mit --days, --chunk, --dry-run.
• Scheduler: täglich 03:20, withoutOverlapping(), mit Betriebs-Alert.
• .env.example ergänzt.

Zwei Sicherungen, beide zwingend und getestet

1. Gelöscht wird ausschließlich unterhalb der Wasserstandsmarke von press-releases:aggregate-views. Alles darüber ist noch nicht in hits verbucht und wäre sonst dauerhaft verloren. Fehlt die Marke, bricht der Lauf mit Exit-Code 1 ab, statt zu raten.
2. Gelöscht wird in Blöcken — ein DELETE über Millionen Zeilen hielte die Sperre über die gesamte Laufzeit.

⚠ Offene Entscheidung: Die 13 Monate sind meine Festlegung, nicht deine. Gewählt, weil damit der Vorjahresmonats-Vergleich möglich bleibt. Der Wert bestimmt zugleich, wie weit die Verlaufsanzeige der geplanten Absenderansicht (Roadmap 1c.1) zurückreicht — wer dort mehr Historie zeigen will, muss ihn vor dem ersten Lauf erhöhen. Einmal gelöschte Ereignisse kommen nicht zurück. Der Zusammenhang steht als Kommentar in config/press_releases.php.

Abgesichert: fünf Tests in tests/Feature/PurgePressReleaseEventsTest.php.

---

Schritt 8 — Index auf companies.email

Befund: companies hatte nur (portal, slug), (portal, is_active), (created_at, id) und einen FULLTEXT über (name, email, slug). Ein FULLTEXT-Index beantwortet kein WHERE email = ? — jede Suche über die Firmen-E-Mail war ein voller Tabellendurchlauf. Roadmap 1a schlüsselt die Newsroom-Konsolidierung ausdrücklich darüber, 1a.4 bei jeder eingehenden API-Meldung.

Geändert: Migration 2026_09_01_091000_add_email_index_to_companies_table.php.

Warum nur email und nicht (portal, email): Die Adresse ist hochselektiv, die Portal-Einschränkung kostet danach nichts mehr — und derselbe Index trägt zusätzlich die portalübergreifende Gruppierung des Trockenlauf-Berichts (1a.1), was ein zusammengesetzter Index nicht könnte.

Kosten: ADD INDEX läuft bei InnoDB auch mit vorhandenem FULLTEXT-Index INPLACE — anders als ADD COLUMN. Bei 70 MB Sekunden.

---

Block D — Schritt 9: laufende Aufräumarbeiten

M1 — Generations-Zähler prozessweit eingefroren

WebPageCache::$generation wurde mit ??= einmal je Prozess gefüllt. Unter PHP-FPM stimmt das; ein Queue-Worker lebt aber über beliebig viele Jobs hinweg und hätte dauerhaft mit dem Stand seines ersten Zugriffs gearbeitet — konkret hätte BoostService::forgetPlacementCaches() die Keys einer alten Generation gelöscht, während der aktuelle Eintrag bis zum TTL-Ablauf stehen bleibt.

• Neu: WebPageCache::resetMemo().
• AppServiceProvider::boot() registriert Queue::looping(…), verwirft die Merkung also zwischen zwei Jobs. Die Merkung selbst bleibt — sie war als Ersparnis gedacht und ist es weiterhin, nur eben mit definierter Lebensdauer. Ein späterer Octane-Betrieb bräuchte denselben Reset auf RequestReceived; das steht als Hinweis am Feld.

M2 — Zähler lag im Namensraum, den er invalidiert

web.generation → page-cache.generation. Der Zähler ist der eine Eintrag, der eine Verwerfung des web.-Namensraums überleben muss.

Deploy-Hinweis: Die Umbenennung setzt den Zähler einmalig auf 0 zurück. Unkritisch, solange sie zusammen mit dem übrigen noch nicht committeten Block ausgeliefert wird — die Generations-Nummer existiert auf dem Live-System noch gar nicht. Wird sie später einzeln nachgezogen, vorher einmal php artisan cache:clear einplanen.

M3 — Wasserstandsmarke nur chunkweise idempotent

AggregatePressReleaseViews: increment()-Schleife und AppSetting::setValue() laufen jetzt in einer DB::transaction() je Durchgang. Vorher war nur der Durchgang wiederanlaufsicher, nicht der Abbruch darin — ein Absturz mitten im Chunk hätte einen Teil der Zähler erhöht, die Marke aber nicht bewegt, und der nächste Lauf hätte genau diese Aufrufe doppelt verbucht. Der Klassenkommentar, der Idempotenz behauptete, ist präzisiert.

M6 — #[Locked] auf $companyId

resources/views/livewire/admin/companies/edit.blade.php: public int $companyId hat jetzt #[Locked], wie das Pendant $id der PM-Bearbeitung. save(), deleteCompany(), markGone() und restoreGone() arbeiten alle auf diesem Wert; ohne das Attribut konnte der Client ihn im Livewire-Payload austauschen, sodass die Aktion eine andere Firma träfe als die im Formular angezeigte.

M8 — pt-osc-Passwort nicht maskiert

OnlineSchemaChange::writeDefaultsFile() schreibt Benutzer und Passwort jetzt über quoteOptionValue() in doppelten Anführungszeichen mit escaptem \ und ". In einer my.cnf beginnt ein # sonst einen Kommentar und umschließende Leerzeichen fallen weg — ein Passwort mit Raute wäre abgeschnitten bei pt-osc angekommen und der Lauf an einem Authentifizierungsfehler gescheitert, dessen Ursache nirgends sichtbar ist.

L7 — max_allowed_packet beim Erstlauf des Reindex

ReindexPressReleaseSearch: Klassenkommentar um den Hinweis ergänzt, dass ein Durchgang --chunk vollständige Textkörper in einem upsert schreibt und beim erstmaligen Indizieren des Bestands im Zweifel --chunk=100 zu wählen ist.

L8 — Blade-Codestil

admin/press-releases/index.blade.php: fn($inner) → fn ($inner). Pint erfasst Blade-Dateien nicht, deshalb war die Abweichung durchgerutscht.

L9

Zusammen mit Schritt 6 erledigt, siehe dort.

---

Endstand

Prüfung	vorher	nachher
php artisan test	1479 grün, 1 übersprungen	1495 grün, 1 übersprungen (6517 Assertions)
vendor/bin/pint --test	passed	passed
vendor/bin/phpstan analyse	390 Fehler außerhalb der Baseline	No errors (Baseline 166 Einträge / 188 Meldungen)

16 neue Tests, verteilt auf PressReleaseSearchIndexTest (3), GoneTombstoneTest (4), ImportNewsletterBouncesTest (4) und das neue PurgePressReleaseEventsTest (5).

Neue Dateien

Datei	Zweck
app/Console/Commands/PurgePressReleaseEvents.php	Aufbewahrung des Ereignis-Logs (M4)
config/press_releases.php	Aufbewahrungszeitraum, konfigurierbar
database/migrations/2026_09_01_090000_add_gone_restore_state_…	Vorzustand der 410-Entfernung (H3/H4)
database/migrations/2026_09_01_091000_add_email_index_to_companies_table.php	Voraussetzung Roadmap 1a
tests/Feature/PurgePressReleaseEventsTest.php	Absicherung M4

Reihenfolge beim Deploy

1. php artisan migrate --force — die neuen Migrationen laufen nach drop_fulltext_indexes_from_press_releases (auf press_releases damit INSTANT, auf companies ein Kopiervorgang von wenigen Sekunden).
2. Danach einmal php artisan press-releases:aggregate-views, damit die Wasserstandsmarke gesetzt ist, bevor der neue Aufräum-Task um 03:20 das erste Mal läuft. Ohne Marke bricht er von selbst ab — es geht also nichts verloren, der erste Lauf wäre nur wirkungslos.
3. php artisan config:cache (neue Konfigurationsdatei).

Was offen bleibt

Thema	Status
Aufbewahrung des Ereignis-Logs: 395 Tage	Meine Festlegung, deine Entscheidung. Bestimmt die Tiefe von Roadmap 1c.1 und ist nur vor dem ersten Lauf frei wählbar.
Die 166 Baseline-Einträge	Kein Fehler, aber auch keine Sichtprüfung wert — Zusammensetzung und Begründung siehe Schritt 5. Wer sie weiter senken will, fängt bei den Closure-Generics in app/Services/Web/ an.
Roadmap-Entscheidungen E1–E6	Unberührt — das sind fachliche Fragen, keine Code-Befunde.

---

Teil 2 — Roadmap Block 0 (Messbarkeit)

0.1 und 0.2 — Basiswerte

Zwei Auswertungen als Artisan-Befehle, Ergebnisse und Ableitungen in basiswerte-block0.md.

php artisan press-releases:view-distribution   [--months=3] [--from=] [--to=] [--json]
php artisan press-releases:rejection-rate      [--months=3] [--from=] [--to=] [--json]

Zwei Befunde, die den Plan verändert haben:

1. Der Gesamtmedian taugt nicht als Basiswert. hits ist ein mitlaufender Zähler, und die Aufrufe wachsen nach der Veröffentlichung wochenlang weiter (⌀ 75 → 128 → 179 → 231 in den ersten vier Wochen, ohne Plateau). Über ein Drei-Monats-Fenster misst man damit die Altersmischung, nicht die Reichweite. Der Report weist deshalb zusätzlich Alterskohorten aus; der Basiswert ist die Kohorte „28–55 Tage", nicht die Gesamtzahl.
2. openPR ist keine zweite Quelle. Es ist der Presse-API-Verteiler von connektar, also derselbe Zulauf. In den Daten hat genau ein API-Token je einen Zugriff gemacht. Roadmap-Text korrigiert.

E2 ist damit entschieden: Rohzahlen. Begründung in basiswerte-block0.md. Kurzfassung: kein Bodensatz (unter 25 Aufrufen liegen 2 % bzw. 0 %), Verteilungen nahezu symmetrisch, und eine Einordnung gegen den Portaldurchschnitt wäre wegen der Wachstumskurve sogar falsch.

---

0.3 bis 0.7 — Konversionsleiter

Warum eine eigene Tabelle statt Umami

Die zu messende Strecke führt über zwei Domains und einen Magic Link. Ein cookiefreies Analytics-Tool verliert die Sitzung genau an der Stelle, an der die Konversion passiert. Claim, Registrierung und Buchung sind außerdem keine Seitenaufrufe, sondern Zustandsänderungen in der Datenbank, bei denen die Identität ohnehin bekannt ist.

Rollenteilung bleibt: Ereignistabelle für den Trichter (Block 1), Umami für Seitenaufrufe und Suchbegriffe (Block 2). Keine Vermischung.

0.3 — conversion_events

Spalten: type, source, company_id, press_release_id, created_at. Keine Personen, keine Klartextadressen, keine IP, kein User-Agent. Der rote Faden durch den Trichter ist die Firma, nicht der Mensch — für „an welcher Stufe bricht es ab" reicht das vollständig.

Die Leiter als Enum ConversionEventType, mit Stufe und Diagnose am Fall:

#	Stufe	Ein Abbruch hier bedeutet
1	Mail-Link geklickt	Betreff oder Anlass trägt nicht
2	Magic Link eingelöst	Der Verwaltungszugang wird nicht verstanden
3	Newsroom bearbeitet	Kein Anreiz, das Profil zu pflegen
4	Konto angelegt	Der Nutzen des Kontos ist nicht erkennbar
5	Erste Buchung	Preis oder Angebot passt nicht

0.4 — Herkunft auf dem Token

Neue Spalte magic_links.source (bewusst eine Spalte statt eines Eintrags in payload: Die Herkunft wird gruppiert und gefiltert, nicht nur gelesen). MagicLinkGenerator::createLoginLink() nimmt sie entgegen.

Die Mail-Links tragen ?src=<Herkunft>&pr=<Meldung>. ConversionSource::parse() fällt bei unbekannten Werten auf organic zurück statt zu scheitern — der Parameter steht in fremder Hand.

Zur Meldungs-ID im Klartext: Sie ist fälschbar. Vertretbar, weil sie nichts freischaltet, sondern ein Ereignis in der internen Statistik einer Firma zuordnet; wer sie fälscht, verfälscht nur die eigene Auswertung. Sobald der Verwaltungszugang über Magic Link steht (1b.2), tragen die Mail-Links ein Token, das Herkunft und Meldung fälschungssicher mitführt — der pr-Parameter entfällt dann.

0.5 — Schreibstellen

Stufe	Wo
1	RecordMailLinkClick — globale Middleware. Bewusst global statt je Route: Die Mail-Links zeigen auf Hub, Spokes und öffentliche Detailseiten, eine vergessene Route wäre eine unsichtbare Lücke. Nur mail_*-Herkünfte lösen aus, nur GET.
2	MagicLinkConsumeController, Herkunft vom Token
3	Enum und Auswertung stehen, Schreibstelle folgt mit 1b.3 (abgesprochen)
4	RecordAuthActivity::recordRegistered()
5	ProcessStripeWebhook an beiden Zahlungspfaden (mirrorPaidInvoice, fulfillSinglePurchase), dedupliziert über recordOnce() je Firma

Zwei Regeln für alle Schreibstellen: Fehler werden geschluckt (die Messung begleitet einen Vorgang, sie ist nicht der Vorgang) und kein Personenbezug.

0.6 — Auswertung

php artisan conversion:funnel [--months=3] [--from=] [--to=] [--json]

Zählt je Stufe die eindeutigen Firmen, nicht die Ereignisse: Ein doppelter Klick ist kein doppelter Interessent, und nur mit derselben Einheit auf allen Stufen ist ein Übergang überhaupt eine Quote. Ereignisse ohne Firmenbezug stehen in einer eigenen Spalte daneben statt im Nenner.

0.7 — Aufbewahrung

395 Tage, derselbe Horizont wie beim Aufruf-Ereignis-Log (Entscheidung 01.09.2026). config/conversion.php, Befehl conversion:purge-events, täglich 03:25 im Scheduler.

Offen und bewusst nicht von mir geschrieben: Der Absatz in der Datenschutzerklärung. Rechtstext gehört nicht aus einer Codeänderung heraus formuliert. Inhaltlich zu führen ist: Zweck (interne Reichweiten- und Konversionsstatistik), Umfang (Ereignistyp, Herkunft, Firmen- und Meldungsbezug — kein Personenbezug, keine IP), Aufbewahrung (395 Tage), Rechtsgrundlage.

Angepasster Bestandstest

EmailBrandingTest verglich die Mail-URL roh gegen das gerenderte HTML. Die Links tragen jetzt zwei Parameter, Blade escapt das trennende & korrekt zu & — der Vergleich läuft nun über e(). Verhalten unverändert richtig, nur die Erwartung war zu eng.

---

Teil 3 — Roadmap Block 1a (Newsroom-Konsolidierung)

1a.1 — Trockenlauf-Bericht

php artisan companies:merge-report [--threshold=] [--limit=15] [--json]

Live-Ergebnis vom 11.09.2026, Schwellwert 3, nach der Tippfehler-Korrektur:

Klasse	Adressen	Firmen	fällt weg	davon mit PM
Dublette	12.812	27.832	15.020	14.633
Namensvariante	1.615	4.540	2.925	1.087
Vorschlag	3.632	9.907	–	2.211
Sammeladresse	1.085	6.706	–	1.072
nie veröffentlicht	23	5.965	–	0

17.945 Firmen würden automatisch zu bestehenden Newsrooms verschmelzen — 16 % des Bestands von 111.646.

Drei Befunde aus den Live-Läufen mit Schwellwert 2, 3 und 4:

1. Die Klasse „nie veröffentlicht" fehlte im Regelwerk. 23 Adressen mit 5.965 Firmen und null Veröffentlichungen, angeführt von yahoo@yahoo.com (4.376 Firmen). Dahinter steht keine Firma und keine Agentur. Hätte 1a.3 ohne diesen Trockenlauf gebaut, wären 4.376 Unbeteiligte zu einem Newsroom verschmolzen — der teuerste Fehler dieses Blocks, nicht sauber rückabwickelbar. Die Namensanzahl allein trennt diese Adressen NICHT von großen Agenturen (pr@deutsche-stadtauskunft.ag: 133 Namen, 134 Firmen mit Meldungen); trennscharf ist erst die Veröffentlichung.
2. Tippfehler galten als verschiedene Firmen. info@js-research.de stand mit 204 Firmen an zweiter Stelle der Agenturliste — eine Firma, siebzehnmal leicht anders geschrieben. Normalisierte Namen werden jetzt zu Ähnlichkeitsclustern zusammengefasst (Levenshtein ≤ 2 bzw. 15 %, oder drei gemeinsame Anfangswörter). Namensvarianten stiegen dadurch von 730 auf 1.615 Adressen, Sammeladressen sanken von 1.430 auf 1.085.
3. „& Co. KG" passte nie. Rechtsformen wurden nach dem Entfernen der Satzzeichen abgeglichen — „gmbh & co kg" traf nie auf „gmbh co kg". Jetzt wortweise vom Ende her gestrippt.

E1 entschieden: Schwellwert 3. Bei 2 wird jede zweite Schreibweise zur „Agentur" (ProCoReX, Welcon — je eine Firma mit Rechtsformwechsel). Bei 4 wandern 768 echte Mehrkunden-Adressen wie presse@agentur-zb.de in die Handarbeit. Konfiguriert in config/newsroom.php.

Zu 3.3: 1.085 Sammeladressen mit 6.706 Firmen, davon 1.072 mit Meldungen — namentlich benannte PR-Agenturen. Das Agenturmodell ist kein Zukunftsfeature, sondern ein vorhandenes Datenproblem.

1a.2 — Persistierte Klassifizierung

php artisan companies:classify-addresses [--threshold=] [--dry-run]

Tabelle company_email_groups, eine Zeile je Adresse — die Klassifizierung ist eine Eigenschaft der Adresse, nicht der Firma. Bewusst eigene Tabelle statt Spalten auf companies (FULLTEXT → jedes ADD COLUMN ein Rebuild).

Die Klassifizierungslogik liegt in CompanyAddressClassifier und wird von Bericht und Persistierung benutzt — beide müssen dieselbe Antwort geben, sonst zeigt der Bericht etwas anderes, als die Zusammenführung später tut.

manual_classification übersteuert die berechnete Klasse und überlebt jede Neuberechnung. Nötig für Grenzfälle, die nur ein Mensch entscheiden kann: presse@pr4you.de ist eine echte Agentur, sieht in den Daten aber aus wie eine Wegwerfadresse. CompanyEmailGroup::effectiveClassification() ist die einzige Stelle, die 1a.3/1a.4 fragen dürfen. Wer über eine Adresse entscheidet, liest nie die berechnete Spalte direkt.

Wiederholbar: Adressen, unter denen nur noch eine Firma steht, fallen beim nächsten Lauf heraus — außer sie tragen eine Handentscheidung.

Laufzeit: 3,2 s über den ganzen Bestand. Die Ähnlichkeitsprüfung ist quadratisch und bei 25 Repräsentanten gedeckelt — ab da steht die Klasse fest, und yahoo@yahoo.com hätte sonst neun Millionen Levenshtein-Aufrufe gekostet.

Deploy: migrate --force, config:cache, dann einmal companies:classify-addresses. Der Befehl gehört vorerst nicht in den Scheduler — die Klassifizierung soll sich nicht über Nacht ändern, während jemand im Admin darüber entscheidet. Nach 1a.4 neu bewerten.

Live-Trockenlauf vom 11.09.2026 (nach Migration, Schwellwert 3):

Klasse	Adressen	zusammenführbar
Dublette	12 812	ja
Namensvariante	1 615	ja
Vorschlag	3 632	nein
Sammeladresse	1 085	nein
nie veröffentlicht	23	nein
gesamt	19 167

Deckungsgleich mit dem Bericht aus 1a.1 — Bericht und Persistierung rechnen dieselbe Logik. 14 427 Adressen (75 %) sind zusammenführbar; hinter ihnen stehen die 17 945 Firmen aus 1a.1. Der scharfe Lauf am selben Tag schrieb dieselben 19 167 Zeilen nach company_email_groups — die Tabelle ist auf Live gefüllt, 1a.3 kann darauf filtern.

Korrektur: „veröffentlicht" heißt „jemals veröffentlicht"

Die 23 Nie-veröffentlicht-Adressen von Live hatten alle exakt null Firmen mit Meldung — darunter pr4you (65 Firmen), Blödorn PR (35), Crossover Point (31), GCE (48). Sieben Agenturen, die nie etwas veröffentlicht haben sollen, sind kein Befund, sondern ein Messfehler.

Nachgeprüft in der Dev-DB (Kopie des Bestands):

Adresse	Meldungen	Status	davon mit Aufrufen	Zeitraum
presse@pr4you.de	199	rejected	199	2008–2011
h.ballwanz@pr4you.de	473	rejected	473	2006–2011
info@bloedorn-pr.de	194	rejected	193	2006–2011
info@gce-agency.com	328	rejected	328	2009–2011
press@crossoverpoint.de	149	rejected	148	2009–2011
yahoo@yahoo.com	5 176	rejected	0	2015–2019
hcgdietinsight4@gmail.com	73	rejected	0	2011–2012

Ursache: Das Altsystem hat 2009–2018 rund 126 000 Meldungen auf rejected gesetzt (gegenüber 31 000 published); 83 000 davon tragen Aufrufe. Eine abgelehnte Meldung wird nie aufgerufen — die waren online und sind später pauschal offline genommen worden. rejected im Altbestand bedeutet „offline", nicht „redaktionell abgelehnt". Der Importer hat den Status korrekt übernommen; nur die Deutung war falsch.

Fix in CompanyAddressClassifier::classifyAll(): eine Firma gilt als veröffentlicht, wenn sie eine Meldung mit status = published oder hits > 0 hat. Zwei Tests halten beide Seiten fest (Agentur mit alten Offline-Meldungen → Sammeladresse; abgelehnte Meldungen ohne einen Aufruf → nie veröffentlicht). Laufzeit unverändert (2,6 s).

Wirkung (Dev-DB, Stand etwas älter als Live): 23 → 7 nie veröffentlicht, 16 wandern zur Sammeladresse. Die übrigen Klassen sind unberührt — das Veröffentlichungssignal entscheidet nur zwischen „nie veröffentlicht" und Sammeladresse. Die Sieben, die bleiben: yahoo@yahoo.com, pr@getarticlesdone.com, hcgdietinsight4@gmail.com, zhangmh@itecheasy.com, andrewkarvert112@gmail.com, kontakt@pr-vertretung.de (159 Firmen, 1 mit Aufruf), bukmaier@prdienst.de (28 Firmen, keine einzige Meldung). Letztere ist die einzige mit Agentur-Namen — sie kann bei Bedarf per manual_classification umgestellt werden.

Nebenbefund für spätere Auswertungen: Jede Statistik, die status = rejected über den Altbestand als Ablehnung liest, misst falsch. Die Ablehnungsquote aus 0.2 ist nicht betroffen (sie läuft über die Statuslogs des neuen Systems).

Deploy: Nach dem Deploy companies:classify-addresses erneut laufen lassen — die 16 Adressen werden dabei umklassifiziert, Handentscheidungen bleiben.

1a.3 — Zusammenführung im Bestand

php artisan companies:merge   [--dry-run] [--limit=] [--email=] [--json]
php artisan companies:unmerge --merge=ID | --batch=UUID | --email=  [--dry-run]

Der Fakt, der den Entwurf bestimmt hat

Die meisten „Dubletten" sind dieselbe Firma auf zwei Portalen: Das Altsystem hat jede Firma je Portal einmal angelegt.

	Gruppen
Adressgruppen gesamt (Dev-DB)	18 860
davon mit Firmen auf beiden Portalen	14 519 (77 %)
Zweiergruppen	15 754
davon exakt PE + B24	12 605
davon zusätzlich mit identischem Slug	12 037

Portal::Both existiert im Code — Newsroom-Controller, PortalScope und Slug-Auflösung behandeln es —, aber keine Firma trug es. Die Zusammenführung ist also weniger „Dubletten löschen" als „zwei Portalhälften zu einer Firma machen": Der Überlebende bekommt both, die Meldungen behalten ihr Portal, der Newsroom zeigt auf jedem Portal die Meldungen dieses Portals.

Entscheidungen (15.09.2026, A/A/A + both)

1. Es bleibt die Firma mit den meisten jemals veröffentlichten Meldungen (published oder hits > 0), bei Gleichstand die ältere. Leere Stammdatenfelder (Website, Telefon, Fax, Adresse, Land, Logo, Boilerplate, Inhaber) füllt sie aus den wegfallenden Firmen; belegte bleiben. Ist der Überlebende inaktiv und eine wegfallende Firma aktiv, wird er aktiv.
2. Meldungen, Kontakte, KI-Erklärungen, Konversionsereignisse wandern per company_id. company_user und Zahlungsoptionen werden zur Vereinigung; ein Nutzer, der schon am Überlebenden stand, wird nicht doppelt — sein alter Eintrag fällt weg und ist als dropped mit Rolle protokolliert. Jede Bewegung steht in company_merge_moves; der Vorgang in company_merges (Batch-ID, Überlebender, sein Portal vorher).
3. Die wegfallende Firma wird soft-deleted. Ihr alter Slug führt per 301 zum Überlebenden (NewsroomDetailPageData::mergedInto()), sofern der Slug abweicht — bei gleichem Slug findet die Auflösung den both- Überlebenden direkt. Kein 410: Die Firma gibt es noch, nur woanders.

Slug-Kollision: Wird der Überlebende both, muss sein Slug auf dem anderen Portal frei sein (die öffentliche Auflösung fragt portal IN (eigenes, both)). Ist der Erstkandidat blockiert, kommt der nächste dran; ist keiner frei, wird die Adresse übersprungen und aufgelistet. Nicht umbenannt — die URL ist öffentlich. Vorab geschätzt 664 Gruppen, tatsächlich 5 — die Kollisionen sind fast immer einseitig (Alt-Slugs sind je Portal durchnummeriert), und die andere Hälfte ist frei.

410-entfernte Firmen bleiben außen vor: Ihre Meldungen in den Überlebenden zu heben, würde bewusst entfernte Inhalte wieder sichtbar machen.

Keine Schema-Änderung an bestehenden Tabellen. Kein merged_from_company_id auf press_releases (1 GB, einmaliger Vorgang), kein merged_into_company_id auf companies (FULLTEXT) — beides kommt aus den zwei neuen Tabellen. press_release_search enthält keine Firmendaten; das Umhängen per Query-Builder braucht keinen Reindex.

Nebenbefund und Fix: Slug-Eindeutigkeit kannte both nicht

HasUniqueSlug prüft bei Firmen nur portal = X. Eine neue PE-Firma hätte denselben Slug wie eine both-Firma bekommen können — und die Newsroom-URL hätte zwei Firmen gefunden. Company::slugExists() prüft jetzt portal IN (X, both), und eine both-Firma braucht den Slug überall frei. Test in HasUniqueSlugTest.

Lauf auf der Dev-DB (Kopie des Bestands)

Adressen zusammengeführt	14 142
Firmen im Überlebenden aufgegangen	16 194
Meldungen gewandert	13 297
Firmen jetzt both	12 926
Kontakte gewandert	8 038
Nutzer-Verknüpfungen weggefallen (schon am Überlebenden)	15 467
Stammdatenfelder aufgefüllt	1 819
übersprungen (Slug-Kollision)	5
Laufzeit merge / unmerge	2:00 min / 1:15 min

Nach companies:unmerge --batch=… stimmten Portalverteilung (42 287 / 66 892), company_user (107 663) und Soft-Deletes (2 155) wieder exakt mit dem Stand davor überein. Die Rückabwicklung ist verifiziert.

Zwei Performance-Punkte beim Bau: Die Kollisionsprüfung mit portal != ? kostete 24 ms je Adresse (kein Index) — mit portal IN (…) greift der Unique-Index (portal, slug), 0 ms. Und wegfallende Firmen werden per Query-Builder soft-deleted, nicht per $company->delete(): Der Observer würde je Firma den Admin-Cache leeren; der Lauf leert einmal am Ende.

Prüfen: companies:merges --batch=<ID> listet je Vorgang den Überlebenden mit seinen Newsroom-URLs auf beiden Portalen, die aufgegangenen Firmen und deren alte URLs, die per 301 weiterführen. Nachgerüstet nach dem ersten Live-Lauf mit --limit=50 — der scharfe Lauf zeigte nur die Batch-ID, und die Frage „welche 50 sind das?" war berechtigt. Der scharfe Lauf zeigt seither auch die ersten 30 Vorgänge als Tabelle.

Deploy: migrate --force, dann companies:merge --dry-run, dann companies:merge --limit=50 und die 50 im Admin ansehen, dann ohne Limit. Erledigte Adressen zählen beim zweiten Lauf nicht gegen das Limit. Danach companies:classify-addresses — die zusammengeführten Adressen fallen aus company_email_groups, weil nur noch eine Firma darunter steht.

Live-Trockenlauf vom 15.09.2026 (nach Migration): 14 422 Adressen, 18 096 Firmen gehen auf, 14 545 Meldungen wandern, 13 296 Firmen werden both, 7 Slug-Kollisionen übersprungen (pizza.de, x84.de, 2× eposso-energy, anzeiger24, togev, afan.academy). Gegenüber der Dev-DB rund 280 Adressen mehr — der laufende API-Zulauf: Unter 301@seo-manager.info stehen vier Firmen mit IDs ab 111 999, alle aus September, je Meldung eine. Genau das, was 1a.4 abstellt.

Auffällig: Bei 1@schlotterimmobilienplus.de bleibt #112132, eine dieser neuen API-Kopien, weil die drei älteren Firmen keine veröffentlichte Meldung tragen — Regel 1 greift wie entschieden, die alte URL führt per 301 auf die neue. Wer den alten Slug behalten will, entscheidet das vor dem Lauf von Hand (--email= einzeln, oder die Gruppe per manual_classification aussparen).

Live-Läufe vom 15.09.2026: Batch 4e1a7235… (--limit=50, 60 Firmen, 33 Meldungen, 48× both), danach Batch af3fb304… über den Rest — die 50 erledigten Adressen wurden dabei als „nichts zusammenzuführen" übersprungen, wie vorgesehen. Zwei Beobachtungen aus der Tabelle:

• a.hezel@serviceplan.com: Es bleibt #52565 „serviveplan public relations" (Tippfehler im Namen), weil sie mehr Meldungen trägt als #18934 „serviceplan public relations". Regel 1 entscheidet nach Inhalt, nicht nach Schreibweise — der Name wird im Admin korrigiert, die URL bleibt.
• a.helf@ubc-collection.com: acht Firmen, sieben davon mit IDs ab 112 698 aus den letzten Tagen, je eine Meldung — der API-Zulauf, den 1a.4 abstellt.

Kompletter Live-Lauf, 15.09.2026 (Batch a0e38bbd…): 14 356 Adressen, 18 013 Firmen aufgegangen, 14 496 Meldungen gewandert, 13 236 Firmen jetzt both, 6 Slug-Kollisionen übersprungen. Zusammen mit den beiden 50er-Batches davor: ~14 450 Adressen, ~18 100 Firmen, ~14 550 Meldungen.

companies:classify-addresses danach: 4 749 Adressen — Dublette 4, Namensvariante 3 (die Slug-Kollisionen plus API-Zulauf seit dem Lauf), Vorschlag 3 633, Sammeladresse 1 102, nie veröffentlicht 7. Der Bestand ist konsolidiert; was jetzt noch zusammenführbar ist, entsteht laufend neu — das ist 1a.4.

Offen: die 6 Slug-Kollisionen einzeln ansehen (pizza.de, x84.de, 2× eposso-energy, anzeiger24, togev). Möglich ist, die fremde Firma mit dem blockierenden Slug zu prüfen — oft ist das dieselbe Firma unter anderer Adresse (Vorschlag-Klasse) — und danach mit --email= nachzuziehen.

1a.4 — Laufende Zuordnung neuer API-Meldungen

Der Alt-Vertrag der API legt vor jeder Meldung eine Firma an: connektar schickt je Meldung POST /service/users/me/companies und dann die Meldung mit der zurückgegebenen ID. Deshalb entstand je Meldung ein Newsroom — a.helf@ubc-collection.com hatte sieben aus einer Woche.

ApiNewsroomAssignment prüft jetzt VOR dem Anlegen, ob unter derselben Firmen-E-Mail schon eine Firma mit demselben Namen steht — „derselbe Name" ist CompanyAddressClassifier::namesMatch(), also exakt die Regel der Klassifizierung (Rechtsform, Tippfehler, gemeinsamer Anfang). Bei Treffer bekommt der Aufrufer deren ID zurück. Der Vertrag bleibt: 201 + Location. connektar merkt nichts davon, außer dass die ID eine alte ist.

Regeln:

• Kein Treffer bei abweichendem Namen → neue Firma wie bisher. Das ist der Agenturfall: neuer Kunde unter der Sammeladresse.
• Nie-veröffentlicht-Adresse (company_email_groups, Handentscheidung übersteuert) → nie zuordnen.
• 410-entfernte und aufgegangene (soft-deleted) Firmen werden nicht getroffen — der Überlebende schon.
• Anderes Portal: Die Firma wird both, die neue Meldung bekommt das angefragte Portal, die alten behalten ihres. Ist der Slug auf dem anderen Portal fremd belegt, bleibt es beim alten Verhalten (neue Firma) — dieselbe Kollisionsregel wie in 1a.3, jetzt als Company::slugTakenOnOtherPortals() an einer Stelle.
• Der API-Nutzer wird als member an die Firma gehängt, sonst dürfte er dort keine Meldung anlegen. Jede Zuordnung steht im Aktivitätsverlauf („API-Firma … dem bestehenden Newsroom #… zugeordnet").

Folgeänderung in LegacyPressReleaseController: both ist kein Ziel-Portal für eine Meldung. Fällt die Portal-Auflösung auf das Portal der Firma zurück und das ist both, entscheidet das Portal des API-Nutzers. Vorher hätte eine Meldung ohne Parameter und Domain-Kontext both bekommen.

Tests: tests/Feature/Api/ApiNewsroomAssignmentTest.php (9).

Messung: companies:classify-addresses nach ein, zwei Wochen — Dublette und Namensvariante müssen bei den 7 aus den Slug-Kollisionen bleiben. Steigt die Zahl, trifft die Zuordnung nicht; companies:merges und der Aktivitätsverlauf zeigen, was zugeordnet wurde.

---

Teil 4 — Block 1b: Newsroom als Produkt (15.09.2026)

1b.1 / 1b.5 — Sichtbarkeitsregel und Rückbau

Die Regel bestand bereits: Detailseite 404 ohne veröffentlichte Meldung, Verzeichnis, Sitemap und Hub-Zähler nur mit einer. Der Rückbau war aber unvollständig: depublish() und markGone() leerten den Seiten-Cache, archive(), changeStatusFromAdmin() (weg von published) und deleteFromAdmin() einer veröffentlichten Meldung nicht — der Newsroom stand nach der letzten Meldung bis zu eine Stunde weiter im Cache. Jetzt leeren alle fünf Wege. Drei Tests in NewsroomPageTest halten den Rückbau fest.

1b.2 — Verwaltungszugang über Magic Link

GET/POST  /{edition}/newsroom/{slug}/verwalten

Der allgemeine Anmeldelink (/anmeldelink auf pressekonto, WS-2) bestand: Wer eine E-Mail eingibt, die an einer Firma oder einem Pressekontakt steht, bekommt lazy ein Konto mit Firmen-Scope. Was fehlte, war der Weg vom Newsroom aus, ohne dass der Besucher eine Adresse kennt oder eingibt — und unabhängig davon, ob der Newsroom überhaupt schon öffentlich ist.

NewsroomClaimService + NewsroomClaimController:

• Die Seite zeigt Firmenname und die maskierte Empfängeradresse (i***@muster.de). Ein Klick schickt den Anmeldelink dorthin. Kein Eingabefeld → kein Enumerationsproblem, keine fremde Adresse.
• Empfänger: die Firmen-E-Mail; fehlt sie, die Pressekontakte. Bewusst nicht beides — ein Klick eines Fremden soll nicht fünf Postfächer treffen.
• Erreichbar für jede Firma mit Slug, auch ohne veröffentlichte Meldung und auch deaktiviert (das ist der Punkt von 1b.2). 410-entfernte bleiben Tombstone, aufgegangene (1a.3) führen per 301 zum Überlebenden — dieselbe Auflösung wie die Newsroom-Seite, jetzt in MergedNewsroomLookup.
• Konto, Zuordnung (responsible) und Versand laufen durch ContactAccessService::requestMagicAccess() — kein zweites Zugangssystem. Neu dort: Herkunft und Ziel-Firma werden durchgereicht.
• Herkunft profile_claim auf dem Token — Stufe 2 der Konversionsleiter misst damit, wie viele Newsrooms über diesen Weg beansprucht werden.
• Landung: Der Login führt direkt auf die Firmenseite im Kundenbereich (me.press-kits.show), nicht aufs Dashboard — company_id liegt im payload des Tokens, kein Schema-Eingriff.
• Drosselung: 3 Links je Newsroom und Tag (config/newsroom.php, NEWSROOM_CLAIM_LINKS_PER_DAY), 15 je IP und Stunde, Honeypot.

Tests: tests/Feature/Web/NewsroomClaimTest.php (7).

Noch nicht verlinkt. Die Seite existiert, aber weder die Newsroom-Seite noch die Veröffentlichungsmail zeigen darauf — das ist 1b.4 und hängt an E4 (ein Element pro Mail: Magic-Link-Hinweis oder Infoseite).

Zu 1b.3 vorab: Die Firmenseite im Kundenbereich kann heute Name, Adresse, E-Mail, Telefon, Website, Land, Logo und Pressekontakte pflegen. Was 1b.3 ergänzt: Beschreibungstext (durch die Rot-Ebene), Bilder (mit KI-Deklaration und Audit-Log), und die Leitplanke, dass Links im Profiltext systemseitig gesetzt werden.

1b.4 — Hinweise (E4 entschieden 15.09.2026)

E4: Die Veröffentlichungsmail trägt den Magic-Link-Hinweis — am Ende, als Hinweis, nicht als Angebot. Damit bekommt der Link auf die Infoseite (1d.2) keinen Platz in dieser Mail (ein Element pro Mail).

• Newsroom-Seite: eine Zeile unter dem Firmenprofil („Sie vertreten …? Profil, Logo und Pressekontakte lassen sich kostenlos pflegen. Diesen Newsroom verwalten"), rel="nofollow", 12 px, ink-3.
• Veröffentlichungsmail: ein Absatz vor dem Hilfe-Hinweis, in derselben grauen Kleinschrift wie der bestehende Login-Hinweis. Link auf /newsroom/{slug}/verwalten des Portals, auf dem die Meldung erschien (bei beiden: presseecho), getaggt mit src=mail_publish&pr=. Kein Hinweis ohne Firma oder bei 410-entfernter Firma.
• Herkunft läuft durch: Die Claim-Seite reicht src aus dem Mail-Link per verstecktem Feld weiter; das Token trägt dann mail_publish statt profile_claim. Stufe 1 (Klick) zeichnet die globale Middleware beim Aufruf der Claim-Seite ohnehin auf. So unterscheidet die Leiter „aus der Mail beansprucht" von „auf der Seite entdeckt".

Tests: drei weitere in NewsroomClaimTest (Seite, Mail, Herkunft).

1b.3 — Kostenlose Profilpflege (Entscheidung 15.09.2026: Bilder zurückgestellt)

Die Firmenseite im Kundenbereich konnte Name, Adresse, Kontakt, Website, Land, Logo und Pressekontakte. Neu:

• Beschreibung (companies.boilerplate, max. 2 000 Zeichen) als Textarea. Erscheint im Newsroom und unter jeder Meldung als „Über das Unternehmen". Beim Speichern wird der Seiten-Cache geleert.
• Rot-Ebene: Der Text läuft durch dieselbe Klassifikation wie eine Meldung (CompanyProfileCheck: KI-Treiber, bei Ausfall deterministische Blacklist — das Muster der Spur-D-Vorprüfung). Rot → Validierungsfehler, nichts wird gespeichert. Gelb ist für ein Firmenprofil kein Grund.
• Leitplanke Links: Reiner Text. strip_tags beim Speichern, escaped beim Rendern — es gibt im Profiltext keine Links, die man auszeichnen müsste. Die Website ist das eine Link-Feld und trägt bereits nofollow. Damit ist die Leitplanke durch Weglassen erfüllt statt durch eine Policy.
• Bilder: zurückgestellt, bis die Bild-Kennzeichnung angepasst ist. Im Formular als „Bilder im Newsroom — BALD — Funktion folgt" sichtbar, nicht weggelassen (Roadmap-Leitplanke).
• Stufe 3 der Konversionsleiter (newsroom_edited) wird hier geschrieben — die letzte offene Schreibstelle aus Block 0. Einmal je Firma; Herkunft ist die des zuletzt eingelösten Magic Links des Kontos (so zählt „aus der Mail beansprucht, dann Beschreibung geschrieben" für die Mail), sonst organic.

Tests: tests/Feature/NewsroomProfileTest.php (4).

1b.6 — Bounce-Suppression (Schritte 1 und 2, 15.09.2026)

Grundlage ist das Konzept bounce-mails-2026-09-15.md (eigenes Postfach als Return-Path, X-Pk-Ref-Header, IMAP-Abholung mit eigenem DSN-Parser, SMTP-Ablehnung als zweiter Pfad, Circuit Breaker). Zwei Korrekturen daran: Der Return-Path muss auf der From-Domain liegen (bounce@pressekonto.com, nicht presseecho.de — SPF-Ausrichtung für DMARC), und nicht jede 5xx ist ein Empfängerproblem: 554-Spam-Pattern des Relays sperrt sonst gesunde Adressen.

Schritt 1 — Liste und Gate

• email_bounces (Ereignis-Log, idempotent über message_id) und email_suppressions (Zustand je Adresse: Grund, Zähler, suppressed_at, released_at). Hart → sofort gesperrt; weich → ab dem dritten in sieben Tagen (config/bounces.php). Freigabe setzt released_at, der nächste Bounce löscht sie wieder.
• EmailSuppressionService — die eine Stelle, die „nicht erreichbar" heißt.
• GateOutgoingMail am MessageSending-Event: streicht gesperrte Empfänger aus jeder ausgehenden Mail, verwirft sie ganz, wenn keiner bleibt (mit Eintrag im Aktivitätsverlauf, Typ „Mail-Sperre"), setzt den Return-Path (MAIL_RETURN_PATH). Eine Stelle für Magic Links, Benachrichtigungen, Newsletter und alles Künftige.
• X-Pk-Ref auf Veröffentlichungs-, Ablehnungs- und Magic-Link-Mail (pm:ID:company:ID, user:ID).
• API-Meldungen: Ist der Pressekontakt gesperrt, geht die Mail an die Firmen-E-Mail; ist die auch gesperrt, an niemanden — nie an den API-Einlieferer.
• newsletter:import-bounces schreibt jetzt zuerst in die zentrale Liste — damit erreicht die Handliste auch Pressekontakte und Firmen ohne Konto.

Schritt 2 — SMTP-Pfad und Circuit Breaker

• RecordSmtpFailure am JobFailed-Event: SmtpFailureClassifier deutet die TransportException. 5.1.x mit Adresse → harter Bounce, 4.x.x → weicher, alles andere (5.7.x, 554, Verbindung) → Relay-Ablehnung.
• MailCircuitBreaker: ab 5 Relay-Ablehnungen in 15 Minuten wird der Versand 30 Minuten angehalten, ein Betriebs-Alert. Im Worker schlagen Mails dann fehl (nachholbar mit queue:retry all), im Web-Kontext werden sie verworfen und protokolliert; Betriebs-Alerts gehen immer durch. php artisan mail:circuit [--reset] zeigt bzw. hebt die Pause auf.

Tests: tests/Feature/EmailSuppressionTest.php (11).

Deploy: migrate --force, config:cache, dann in der .env MAIL_RETURN_PATH=bounce@pressekonto.com — erst, wenn das Postfach existiert. Danach einmal newsletter:import-bounces laufen lassen, damit die bisherige Handliste in die zentrale Sperre kommt.

Offen: Schritt 3 (IMAP-Abholung, webklex/laravel-imap, freigegeben 15.09.2026) und Schritt 4 (Markierung im Admin, Claim-Seite, Freigabe).

Schritt 3 — Abholung aus dem Postfach (15.09.2026)

• Abhängigkeit webklex/laravel-imap ^6.2 (freigegeben 15.09.2026). Bringt ein eigenes IMAP-Protokoll mit — keine PHP-Extension nötig.
• DsnParser: eigener Leser für RFC-3464-Zustellberichte auf der rohen Nachricht. Zerlegt MIME (auch verschachtelt), nimmt aus dem message/delivery-status-Teil je Empfänger Final-Recipient, Action, Status, Diagnostic-Code, aus dem Original-Teil unseren X-Pk-Ref. Maßgeblich ist Action: failed → hart (bei 4.x.x weich), delayed → weich, delivered/relayed → ignoriert. Kein message/delivery-status → null, kein Raten.
• BounceMailProcessor: entscheidet je Mail den Zielordner — Processed, Ignored (Zustellbestätigung, Abwesenheitsnotiz per Auto-Submitted/ Betreff) oder Unparsed (Freitext-Rückläufer; Eintrag im Aktivitätslog, damit ein Mensch ihn ansieht). Testbar mit .eml-Fixtures in tests/Fixtures/bounces/.
• mail:fetch-bounces [--account=bounces] [--limit=200] [--dry-run]: alle zehn Minuten im Scheduler, liest UNSEEN aus INBOX, verschiebt jede Mail in ihren Ordner (legt ihn an, falls er fehlt). Verschieben statt Flag: Bricht der Lauf ab, liest der nächste dieselbe Mail erneut — dank Message-ID-Unique ohne Doppelzählung. Ohne konfiguriertes Konto beendet sich der Befehl sofort; Verbindungsfehler lösen einen Betriebs-Alert aus.
• config/imap.php (Paketvorlage, Konto bounces aus BOUNCE_IMAP_*).

Tests: tests/Feature/BounceMailProcessingTest.php (6) mit fünf Fixtures (Postfix-Hardbounce mit Fortsetzungszeilen und Kleinschreibung, delayed, Zustellbestätigung, Freitext, Abwesenheit).

Deploy Schritt 3: composer install, config:cache, dann in der .env BOUNCE_IMAP_HOST=w01eb4f6.kasserver.com, BOUNCE_IMAP_USERNAME/PASSWORD des Postfachs bounce@pressekonto.com, MAIL_RETURN_PATH=bounce@pressekonto.com. Erster Lauf von Hand: php artisan mail:fetch-bounces --dry-run.

Schritt 4 — 1b.6 selbst (15.09.2026)

• Admin ▸ Mail-Sperrliste (/admin/mail/sperrliste, Recht users:manage): gesperrte/freigegebene Adressen mit Grund, Quelle, Zählern; Freigabe mit Rückfrage; manuelle Sperre; die letzten nicht lesbaren Rückläufer (liegen im Postfach unter „Unparsed"); Zustand des Circuit Breakers und ob Return-Path/Postfach konfiguriert sind.
• Firmenseite im Admin: Badge „E-Mail nicht erreichbar" im Kopf (verlinkt in die Sperrliste), Markierung an der Firmen-E-Mail und an jedem gesperrten Pressekontakt.
• Claim-Seite: Gesperrte Adressen sind keine Empfänger mehr. Gibt es Adressen, aber alle sind gesperrt, sagt die Seite, dass die hinterlegte Adresse nicht erreichbar ist, und verschickt nichts. Die Meldungsseite zeigt dieselben Empfänger (gleiche Quelle).
• Aus allen Mailstrecken ausgenommen sind gesperrte Adressen bereits seit Schritt 1 über das Versand-Gate.

Tests: tests/Feature/MailSuppressionAdminTest.php (3).

Damit ist 1b.6 komplett — und Block 1b. Offen bleibt nur das Anlegen des Postfachs und die Live-Konfiguration (siehe Deploy-Hinweise zu Schritt 1 und 3).

Zwischenschritt — Paket-Update (15.09.2026)

Anlass: Auf Live war composer require webklex/laravel-imap samt composer update von Hand gelaufen. Das hob dort alle Pakete an, die composer.lock wich vom Repo ab, und die im Mai veröffentlichten Livewire-Assets (public/vendor/livewire, gitignored) passten nicht mehr zum neuen Livewire — Konsolen-Warnung „published assets are out of date" und verschobene Formatierung, weil der Portal-Build noch gegen die alte Flux-CSS gebaut war.

Entscheidung: Das Update wird hier nachgezogen und versioniert, statt Live zurückzusetzen.

• composer update innerhalb der Constraints: 71 Pakete. Wesentlich: Laravel 12.63 → 12.69, Livewire 4.2.4 → 4.4.5, Flux/Flux Pro 2.14 → 2.20, Volt 1.10 → 1.11, Fortify 1.36 → 1.39, Cashier 16.5 → 16.8 (zieht stripe/stripe-php 17 → 21 nach, API-Version bleibt über Cashier gepinnt), Larastan 3.9 → 3.12, Pint 1.29 → 1.32. Majors (Laravel 13, Pest 5, spatie/permission 8) bewusst nicht.
• npm update + npm audit fix: Vite 6.4.0 → 6.4.3, Tailwind 4.1 → 4.3, Alpine 3.15 → 3.17; vorher 13 gemeldete Schwachstellen (Build-Tooling), danach 0.
• Larastan 3.12 versteht Query-Scopes jetzt selbst → drei Baseline-Einträge (visibleInArchive, forPortalValues) waren tot und sind raus. Drei neue Befunde behoben: PressReleaseService::notifyAuthor() wählt die Mailable jetzt über den Benachrichtigungstyp statt über ein zweites match; PressReleaseMediaPrivatizer prüft vor fclose() nicht mehr auf is_resource; FixApiPortalDuplicates iteriert über ein Array statt über Collection-Offsets. phpstan: No errors, Pint sauber.
• Flux-Changelog 2.15–2.20 gesichtet: keine Breaking Changes, aber Feinkorrekturen an Icon-Buttons (Inset/Padding), Navbar-Abständen, Sidebar-Tooltips und Tabellen-Padding. Die auf Live gesehenen Sprünge kamen aus dem alten Build; nach frischem npm run build bleiben allenfalls diese kleinen Anpassungen.
• Tests: 1612 passed.

Deploy: composer install, npm run build, php artisan livewire:publish --assets (gehört dauerhaft ins Ploi-Skript, sonst läuft public/vendor/livewire bei jedem Livewire-Update wieder aus dem Takt), optimize:clear, config:cache, view:cache, queue:restart. Vorher auf dem Server git checkout composer.lock, damit der Pull nicht an der handgeänderten Datei hängen bleibt.

1b.6 — Erster Blick ins echte Postfach (15.09.2026)

Zugang zu bounce@pressekonto.com steht; 151 Rückläufer aus service@ hinübergeschoben. Der Trockenlauf meldete zunächst 0, weil alle das Gelesen-Flag mitgebracht hatten und der Abruf nur UNSEEN holte.

Befund über alle 151 (Dry-Run mit dem Parser):

• 147 klassische DSNs (Postfix/All-Inkl, Exchange, Gmail) — sauber gelesen.
• 2 × message/global-delivery-status (RFC 6533, SmarterMail) — bisher „nicht lesbar".
• 2 × Freitext des eigenen All-Inkl-Relays („anti spam system … list of non existent recipients", Header X-KASMail-Error) — mit Auto-Submitted: auto-replied und deshalb bisher als Abwesenheit ignoriert. Genau die Adressen wären nie gesperrt worden.
• Statuscodes: 74 × 5.4.4 (Domain ohne MX, davon 66 × dieselbe Adresse), 24 × 5.0.0, 13 × 5.1.1, 8 × 5.1.10, 8 × 5.7.1, Rest 5.2.x/4.x.
• 37 eindeutige Adressen.

Vier Änderungen (Commit im Anschluss):

1. Abruf holt alles in der INBOX, nicht nur Ungelesenes — das Verschieben in Processed/Ignored/Unparsed ist ohnehin die Zustandsmarke.
2. Parser versteht RFC 6533 (message/global-delivery-status, message/global-headers).
3. Parser liest das All-Inkl-Freitextformat — nur bei X-KASMail-Error und dem wörtlichen Einleitungssatz. MAILER-DAEMON/„Undelivered" wird nie mehr als Abwesenheitsnotiz gewertet.
4. Einstufung: failed mit 5.7.x (Policy, „Relay access denied"), 5.2.2/ 5.2.5 (Postfach voll) oder SMTP 552 im Diagnosetext zählt weich statt hart — die Adresse existiert, ihr Server nimmt nur nichts an. 16 von 147 im Bestand.

Danach: 151/151 gelesen, 0 ignoriert, 0 nicht lesbar. Nicht scharf von hier gelaufen — das würde die Mails im Live-Postfach verschieben und die Sperren nur in die Dev-DB schreiben. Der scharfe Lauf gehört auf den Server nach dem Deploy (php artisan mail:fetch-bounces), der Scheduler holt danach alle zehn Minuten nach.

Fixtures: global-delivery-status.eml, kas-antispam.eml, policy-5.7.1.eml; Tests in BounceMailProcessingTest (+3, 9).

Nebenbefund: Dev-DB von der Testsuite geleert

Um 15:16 lag ein bootstrap/cache/config.php; der überlagert die phpunit.xml-Umgebung (SQLite :memory:), und die Suite um 15:20 lief mit RefreshDatabase gegen die MySQL-Dev-DB pressekonto — die Bestandskopie ist weg (alle Tabellen neu angelegt 15:21:58–15:22:11). composer run test räumt den Cache vorher weg, php artisan test direkt nicht. tests/TestCase.php bricht jetzt hart ab, wenn die Verbindung nicht SQLite :memory: ist. Die Kopie muss neu eingespielt werden.

Kontakterreichbarkeit — Umsetzung der Punkte 1–4 (16.09.2026)

Grundlage: dev/2026-09-11-audit/kontakterreichbarkeit-mx-bounces-2026-09-15.md. Vor der Entscheidung gemessen (Dev-DB, echtes DNS):

• 877 Firmen-Domains aus sechs Monaten API-Einlieferung: 870 mit MX, 1 nur A (zulässiger Fallback), 6 ohne Zustellweg, 0 Null MX, 0 Resolver-Fehler. Die sechs stehen für 75 Meldungen; sdmediapr.com allein für 68 Meldungen einer Firma und 66 der 151 Rückläufer.
• Pressekontakte an Meldungen: 401 im Gesamtbestand, 21 in sechs Monaten — Benachrichtigungen gehen praktisch immer an die Firmenadresse. Grenze 2 des Dokuments (erster Kontakt verdeckt zweiten) ist damit ohne praktische Bedeutung und wurde nicht angefasst.
• Mit Kontakten dazu (voller Lauf, 1 200 Domains): 10 Domains ohne Zustellweg, darunter kaeser-stroebelde (Punkt verloren) und bester-immobilienmakler-neustadt-am-ruebenber (bei 45 Zeichen abgeschnitten) — Datenqualität beim Einlieferer, nicht bei uns.

Entscheidung mit dem Nutzer: Punkte 1–4 jetzt, keine Veröffentlichungssperre (Abschnitt 6 / Stufe 3 des Dokuments) — ein bis zwei Fälle im Monat rechtfertigen die Zustandsmaschine nicht, die Sperrliste verhindert Wiederholungsmails bereits. Nach Beobachtung neu entscheiden.

1. Formprüfung beim Einreichen — App\Rules\PlausibleEmailDomain, deterministisch, ohne Netz: Domain braucht eine Endung, gültige Labels, alphabetische TLD (oder xn--), kurze Liste beweisbarer Tippfehler-TLDs (.ded, .cmo …). IDN wird per Punycode normalisiert. Greift an company.email und contact.email der Legacy-API; 422 mit klarem Grund. info@hoerwelt-basel bestand Laravels email-Regel bisher.

2. Domainprüfung als Beobachtung — email_domain_checks je Domain mit Zustand (EmailDomainState: Deliverable, ImplicitMx, NullMx, NoMailPath, DomainMissing, BrokenMx, Unresolved), Grund, Prüfzeit, Ablauf. MailDomainChecker über die Schnittstelle DnsResolver (SystemDnsResolver produktiv, FakeDnsResolver im Test — kein Test fragt echtes DNS). Regeln aus dem Dokument umgesetzt: A/AAAA-Fallback nur ohne MX, Null MX schlägt A, ein nutzbares MX-Ziel genügt, Timeout/SERVFAIL ist kein Befund und wird mit wachsendem Abstand wiederholt, positive Befunde gelten 30 Tage, negative 3. Anstoß über EmailDomainObserver an Company und Contact (Job CheckEmailDomain nach Commit, alle Strecken gleich), Auffrischung täglich 04:20 via mail:check-domains --stale, Bestandsaufnahme mit mail:check-domains --months=. Aus einem DNS-Befund entsteht nie eine Adresssperre — im Test verankert. Firmenseite im Admin zeigt den Befund als Badge.

3. Einlieferer-Bericht — Admin ▸ Reports ▸ Einlieferer-Bericht (/admin/reports/einlieferer), Auswahl Einlieferer und Zeitraum. Drei Quellen, in der Anzeige vereint: nicht erreichbare Adressen (Sperrliste und Domainbefund, letzterer als schärfere Aussage bevorzugt) mit Firma und Zahl betroffener Meldungen; automatisch abgelehnte Meldungen mit der Begründung aus dem Status-Log (source = ki); Richtlinien-Ablehnungen als Hinweis. Bericht als Text zum Kopieren und zwei CSV-Downloads. Versendet wird nichts — der Nutzer entscheidet, was er an connektar weitergibt. Service SubmitterContactReport, Wertobjekte SubmitterSummary, BrokenContact, RejectedRelease.

4. Richtlinien-Ablehnungen zählen nicht — neue Art EmailBounceKind::Policy (5.7.x, „Relay access denied", Transportregel, Spamfilter der Gegenseite): protokolliert und im Bericht sichtbar, aber ohne Wirkung auf den Schwellwert. Reihenfolge im Prozessor: Statuscode vor Diagnosetext — 5.1.x bleibt hart, auch wenn im Text „spam" steht (Freitext des eigenen Relays). Volles Postfach bleibt weich.

Tests: MailDomainCheckTest (11), PlausibleEmailDomainTest (5), SubmitterContactReportTest (8), BounceMailProcessingTest (+1, 10); zwei bestehende Tests von assertNothingPushed auf assertNotPushed(ClassifyPressRelease) verengt, weil der Observer jetzt einen Job anstößt.

Deploy: migrate --force, dann einmal php artisan mail:check-domains --months=6 --limit=1500 (≈ 2 Minuten, nur DNS-Lesen). Danach ist der Bericht gefüllt.

---

Teil 5 — Block 1c: Sichtbarkeit belegen (16.09.2026)

Befunde vor dem Bau

• press_release_events trägt seit 17.07.2026 je Aufruf einen Zeitstempel, Index (press_release_id, type, created_at), Tagesreihe je Meldung 4 ms, Aufbewahrung 13 Monate (Teil 2). Davor nur die Summe hits. Beginn steht in config/press_releases.php (events.recorded_since).
• E2 bleibt: Rohzahlen, keine Einordnung.
• Leerlauf nach dem Claim: Die Firmenseite im Kundenbereich filterte Meldungen nach user_id. Ein Beansprucher sah „Keine Pressemitteilungen für diese Firma", obwohl connektar 68 eingereicht hatte — die Policy erlaubte das Ansehen längst. Das Statistik-Panel war ein Platzhalter.
• Keine Suchmaschinen-Anbindung im Code. Entscheidung mit dem Nutzer: Indexierung Variante B (ohne Fremddienst), Search Console (A) später als Abgleich, „ganz nach hinten".

1c.3 — Newsroom-Übersicht

VisibilityStats::companySummary() (Meldungen, veröffentlicht, Aufrufe gesamt aus hits, Aufrufe 30 Tage aus Ereignissen, zuletzt veröffentlicht) und recentViewsFor() für die Liste. Firmenseite: alle Meldungen der Firma nach coalesce(published_at, created_at), Spalten Aufrufe und 30 Tage, Fremdeinreichungen als „eingereicht über Partner" markiert; Statistik-Panel „Sichtbarkeit" echt.

1c.1 — Absenderansicht je Meldung

Panel „Sichtbarkeit" auf me.press-releases.show, nur für Meldungen, die je online waren: Aufrufe gesamt (seit Veröffentlichung), Aufrufe im Zeitraum (30/90 Tage umschaltbar, ?verlauf=), Teilungen je Kanal, Tagesbalken als reines SVG ohne Bibliothek. Tage vor Beginn der Zählung oder vor der Veröffentlichung sind null, nicht 0 — blass gezeichnet mit Fußnote, damit die Summe nicht der Grafik widerspricht. Auffindbarkeit: „In der Sitemap für Suchmaschinen seit <published_at>" (Aussage über uns) plus Schaltfläche „Bei Google prüfen" (site:-Suche). Die alten Kacheln Aufrufe/Geteilt im Status-Panel sind darin aufgegangen.

1c.2 — Zugang über Magic Link

War durch 1b.2 fast fertig (Konto, Firmenzuordnung, Policy). Ergänzt: Der Mail-Link trug schon pr=<id>; die Claim-Seite reicht ihn als verstecktes Feld durch, der Controller prüft die Zugehörigkeit zur Firma, das Token bekommt press_release_id, der Login landet auf der Meldung (MagicLinkConsumeController), sonst wie bisher auf der Firma. Wortlaut in der Veröffentlichungsmail: „Diesen Newsroom verwalten und Aufrufe einsehen" — weiterhin ein Element (E4).

Tests: VisibilityStatsTest (6), NewsroomClaimTest (+1, 11). Gesamt 1680 grün, phpstan für die neuen Dateien sauber.

Nebenbefund: phpstan meldet acht Punkte in SettleUnpaidLegacyInvoices und ManualInvoicePdfRenderer aus dem parallel entwickelten Projekt dev/lagacy-rechnungen/ (Commit 36691a5) — nullsafe-Zugriffe auf nicht nullbare Werte, eine immer-falsche Negation. Nicht angefasst.

Deploy: kein migrate, nur Code; view:cache neu. Kein Backfill nötig.

---

Teil 6 — Block 1d: Infoseite und Prüfkreislauf (16.09.2026)

Entscheidungen mit dem Nutzer

• E3: keine Credits für Prüfläufe. Die Prüfung ist Teil des Freigebens; ein eigenständiges Werkzeug zum Textreinkopieren gibt es nicht (wäre der Weg, das Gate auszutesten). Automatische Prüfung je Meldung scoring.classification.max_automatic_attempts (Vorgabe 3); danach geblockt in die Admin-Queue; Freischalten oder Kommentar; ab dann ist die Automatik für diese Meldung aus.
• Gelb geht weiter automatisch online. Der Schalter yellow_to_manual_queue war im Code nie ausgewertet (1 288 gelbe Meldungen in sechs Monaten ohne Blick); jetzt ausgewertet, Vorgabe false, im Admin sichtbar (Filter „KI: Gelb" bestand schon).

Befund vorab

84 KI-Ablehnungen in sechs Monaten, jede Meldung genau einmal, eine davon später veröffentlicht — heute loopt niemand. Der Zähler schützt vor einem Verhalten, das erst mit 1d.1/1d.2 entsteht.

1d.1 / 1d.2 / 1d.6 (Commit c08c9e5)

Hilfeseite /{edition}/gute-pressemitteilung (DE/EN): Anlass, Aufbau, Sprache, Prüfablauf mit Versuchszahl aus der Konfiguration, die sieben Dimensionen des Content-Scores offen (Pressestil, Struktur, Lesbarkeit, Vollständigkeit, Quellen, Überschrift, Eigenständigkeit) — Gewichtung und Schwellen nicht (Offenlegungsgrenze), Pressebilder, Partner als BALD. Kein Preis-, Tarif- oder Credit-Link im Seiteninhalt (Test prüft den Prosa-Block). Sitemap, Hilfe-Center. Ablehnungsmail verlinkt die Seite auf dem Portal der Meldung mit src=mail_reject&pr=<id>.

E3 — begrenzter Prüfkreislauf

• Spalten auto_check_attempts, manual_review_required_at an press_releases (INSTANT, keine Volltext-Indizes mehr).
• submitForReview(): zählt den Lauf; ist die Automatik erschöpft, geht die Freigabe ohne ClassifyPressRelease direkt in review mit Status-Log „wartet auf manuelle Entscheidung". Content-Score läuft weiter.
• routeByClassification(): Rot beim N-ten Lauf → holdForManualReview() statt Ablehnung (bleibt review, Log „Automatische Prüfung erschöpft (N von N): ", ActivityLog). Gelb → Schalter. Der Autor bekommt beim Block die Mail „Ihre Pressemitteilung wird persönlich geprüft" (Nachtrag unten).
• Admin ▸ Pressemitteilungen: Ansicht „Prüfung nötig" (Zähler rot, wenn > 0), Filteroption, Badges „Prüfung nötig" / „nur manuell" in der Liste; Detailseite zeigt alle KI-Begründungen chronologisch und beschriftet die Aktionen „Freischalten" / „Mit Kommentar zurück" (bestehende publish/reject-Aktionen, Kommentar geht per Ablehnungsmail an den Autor).
• Kundenseite: Button „Zur Prüfung freigeben" (statt „einreichen", überall vereinheitlicht), Modal erklärt in drei Schritten, was nach der Freigabe passiert; abgelehnte Meldung zeigt „Automatische Prüfung X von N genutzt" mit Link auf 1d.1; geblockte Meldung: „wird von einem Menschen geprüft".
• Nebenbefund Blade: ein inline @php(...) wird bis zum nächsten @php … @endphp als Rohblock gelesen — vier Stellen auf Blockform umgestellt, eine davon Bestand (Modal). Seit dem Nachtrag unten durch einen Test abgesichert.

Tests: ManualReviewGateTest (5), StaticPagesTest (+2), ConversionFunnelTest (erweitert). 1d.5 ist mit 1c.2 erledigt (der Beansprucher sieht Ablehnungsgrund, KI-Stufe, Content-Score).

Deploy: migrate --force (Millisekunden), view:cache, queue:restart. Kein Backfill — bestehende Meldungen starten mit 0 Versuchen.

1d.3 — Abmeldung für Empfänger ohne Konto

Befund: Die Benachrichtigungen zu API-Meldungen gehen an Pressekontakt oder Firmen-E-Mail — der Abmeldelink darin war aber für das Konto des Einlieferers signiert (configureUnsubscribe($user, …)). Ein Klick des Pressekontakts hätte connektar abgemeldet, nicht sich selbst.

Umsetzung: EmailSuppressionReason::Unsubscribed als dritter Zustand in der Sperrliste. Mailables bekommen den tatsächlichen Empfänger ($recipientEmail); weicht er vom Konto ab, trägt der Link die Adresse (/e-mail-benachrichtigungen/abmelden-adresse?email=…&type=…, signiert, One-Click-POST ohne CSRF wie bisher). Die Abmeldung gilt für alle Benachrichtigungen an die Adresse; Rücknahme von der Bestätigungsseite. Eine bestehende Zustellsperre wird nicht zur Abmeldung herabgestuft, und eine Abmeldung löst nur der Empfänger selbst.

Ausnahme im Gate: GateOutgoingMail lässt MagicLoginLink an abgemeldete Adressen durch (suppressedAmong(…, includeUnsubscribed: false)), die Claim-Seite behandelt sie als erreichbar — den Anmeldelink fordert die Person selbst an. Harte Bounces sperren weiterhin alles.

Tests: AddressUnsubscribeTest (5). Admin ▸ Mail-Sperrliste zeigt den Grund „abgemeldet" ohne weitere Änderung.

Nachtrag 1d (16.09.2026) — Mail beim Block, Blade-Guard

Beide offenen Punkte aus dem Block auf Wunsch des Nutzers umgesetzt.

Mail „ein Mensch prüft jetzt". Neue Mailable PressReleaseHeldForReview, ausgelöst aus holdForManualReview() über denselben notifyAuthor()-Pfad wie Veröffentlichung und Ablehnung — also mit der API-Regel (Pressekontakt → Firmen-E-Mail → sonst gar nicht, nie an connektar), Sperrliste, adressbezogener Abmeldung (1d.3) und Bounce-Referenz. Zwei Textvarianten: Automatik erschöpft („auch im N. Durchlauf nicht freigeben … statt einer weiteren Ablehnung sieht sich jetzt ein Mensch die Mitteilung an") und Gelb-Queue („zur Sicherheit zurückgehalten"). Kern der Mail: Sie müssen nichts tun, die Meldung ist nicht öffentlich, das Ergebnis kommt als Veröffentlichungs- oder Ablehnungsmail. Ein Button „Stand der Prüfung ansehen" führt ins Konto (src=mail_review, neue ConversionSource::MailReview, damit der Klick im Funnel unterscheidbar bleibt). Kein Ablehnungsgrund in der Mail — die KI-Begründungen stehen im Konto, und die Mail soll beruhigen, nicht nachtreten.

Opt-out: kein neuer Präferenz-Typ. Der Zwischenstand hängt am Typ „abgelehnt" — wer keine Prüfergebnisse will, will auch den nicht. Die drei Texte des Typs (Einstellung, Footer-Begründung, Abmelde-Label) sprechen jetzt von „Prüfergebnis" statt nur „Ablehnung".

Blade-Guard. BladePhpBlockGuardTest läuft über alle Views und wendet exakt das Compiler-Muster an (/(?<!@)@php(.*?)@endphp/s, BladeCompiler::storePhpBlocks): Jeder Treffer, dessen Inhalt mit ( beginnt, ist ein inline @php(, das einen späteren Block verschluckt. Der Test fand sofort eine Stelle: den eigenen Erklär-Kommentar im Modal, der @php( und @endphp wörtlich enthielt. Blade liest die Rohblöcke vor den Kommentaren — die Stelle funktionierte nur, weil der Kommentar den Platzhalter anschließend mit entfernte. Kommentar umformuliert; Regel in CLAUDE.md festgehalten.

Tests: ManualReviewGateTest (+1 → 6, Mail beim Block, Textvarianten, Opt-out), BladePhpBlockGuardTest (1).

Damit ist Block 1d komplett, ohne offene Punkte.

Nachtrag 17.09.2026 — Profil-Kurzfelder sind keine Werbefläche

Anlass: Frage des Nutzers nach der Live-Sichtung von 1d, ob beim Speichern des Profils auf Spam geprüft wird.

Stand vorher: Die Beschreibung („Über das Unternehmen") lief seit 1b.3 durch die Rot-Ebene (CompanyProfileCheck, KI mit Blacklist-Fallback). Nicht geprüft waren die Kurzfelder, die ebenfalls öffentlich bzw. in Mails erscheinen: Firmenname, Adresse, Pressekontakt (Name, Zuständigkeit).

Umsetzung: Regel App\Rules\NoPromotionalText — deterministisch, ohne KI: keine Links (Schema, www., nackte Domain mit Pfad), keine E-Mail-Adressen, keine Zeichenketten (!!!, Emoji-Reihen), kein Blacklist-Treffer; jeweils mit eigener Fehlermeldung am Feld. Nackte Domains ohne Pfad („meinshop.de GmbH") bleiben bewusst erlaubt — Marke, nicht Link. Angewendet in Firmen ▸ Stammdaten (Name, Adresse), Firma anlegen (Name, Adresse) und Pressekontakt (Vorname, Nachname, Zuständigkeit). Die Adresse läuft zusätzlich wie die Beschreibung durch die Rot-Ebene, nur bei Änderung.

Befund im Bestand (Dev-DB = Live-Kopie):

• 4.390 aktive Firmen tragen bbcode-/HTML-Linkspam in der Adresse (Moncler, Chanel-Outlet …), 4.381 davon mit website = "180" — ein Legacy-Importfehler; keine davon hat je eine Meldung veröffentlicht, und ohne veröffentlichte Meldung gibt es keine Newsroom-Seite (NewsroomDetailPageData). Nicht öffentlich, aber Datenmüll.
• 38 öffentliche Firmen (mit Meldungen, jüngste 09.09.2026) haben eine URL im Namen („Steinreinigungsuntermehmen - https://www.bgn.at/…"), überwiegend über die API eingeliefert. Diese Namen stehen auf der Newsroom-Seite und in der Übersicht.
• Kontakte: 0 Treffer. Beschreibungen: 0 Treffer.

Tests: NoPromotionalTextTest (20 inkl. Datensätze).

Entscheidung (17.09.2026): Links im Firmennamen normalisieren, nicht ablehnen — am API-Eingang und einmalig im Bestand. Die 4.390 bbcode- Leichen bleiben vorerst unangetastet (nicht öffentlich).

CompanyNameNormalizer::normalize(name, website): URLs (Schema, www., Domain mit Pfad) aus dem Namen ziehen, verwaiste Trenner aufräumen, erste entfernte URL ins leere Website-Feld; besteht der Name nur aus der URL, wird der Host zum Namen („ak-autos.de"). Bestehende Website bleibt.

• LegacyCompanyController::store: normalisiert vor der Zuordnung (1a.4), damit bereinigter Name und bereinigter Bestand zusammenfinden; Slug aus dem sauberen Namen; ActivityLog „Korrektur" mit Vorher/Nachher.
• companies:strip-links-from-names {--dry-run} {--all}: ohne --all nur aktive Firmen mit veröffentlichter Meldung (die 38 öffentlichen); Slugs bleiben (Newsroom-URLs sind draußen verlinkt); ActivityLog je Firma; Seiten-Cache geleert. Dry-Run auf der Dev-DB: 38 Treffer, Vorher/Nachher geprüft (z. B. „Steinreinigungsuntermehmen - https://www.bgn.at/…" → „Steinreinigungsuntermehmen", „www.hobelmesser.shop - Turmfalke Sägen …" → „Turmfalke Sägen & Messer Inh. Ugur Özmen e.K.").

Tests: CompanyNameNormalizerTest (11). Live: companies:strip-links-from-names --dry-run, Liste ansehen, dann ohne Flag.

bbcode-Leichen (Nachtrag, auf Wunsch): companies:retire-link-spam {--dry-run} deaktiviert aktive Firmen mit [url= oder <a href in Adresse, Beschreibung oder Name, die nie eine Meldung veröffentlicht haben — kein Löschen, is_active = false, IDs in storage/app/companies-link- spam-<zeitstempel>.txt, ein ActivityLog-Eintrag mit Zahl. Vorher geprüft: Die 1.302 davon mit Meldungen haben nur rejected (bis 2019) und archived (bis 2022), nichts Öffentliches. Die 44 Besitzerkonten bleiben unangetastet — 24 führen auch saubere Firmen. Dry-Run Dev-DB: 4.391. Test: RetireLinkSpamCompaniesTest.

---

Teil 7 — Block 2: Organische Sichtbarkeit (ab 17.09.2026)

Block 1 ist komplett und live (17.09.2026). Block 2 beginnt mit dem technischen Teil (2.1, 2.2, 2.7); die Inhalts- und Marketing-Pakete (2.3, 2.4, 2.6) folgen, 2.5 hängt an E5.

2.1 — NewsArticle und Organization (17.09.2026)

Stand vorher: Das Grundgerüst gab es seit Juli (Commit 379688f): NewsArticle + BreadcrumbList auf jeder öffentlichen Meldung, Organization auf dem Newsroom, WebSite + Organization auf den Portal-Startseiten, BreadcrumbList auf Kategorien; Ausgabe über x-web.structured-data (JSON_HEX_TAG gegen </script>-Ausbruch). Die Vorschau bleibt ohne Markup.

Was fehlte: Die Entitäten hingen nicht zusammen. NewsArticle.author und die Organization der Newsroom-Seite waren zwei namensgleiche Objekte ohne gemeinsame @id; der Publisher hatte kein Logo (Google empfiehlt es für Article-Rich-Results) und ebenfalls keine @id.

Umsetzung: App\Support\StructuredData bündelt die Entitäten:

• publisher($portalBase) — Organization des Portals mit @id = {portal}/#organization, Name aus config/domains.php, Logo als ImageObject (/images/presseecho-logo.svg bzw. businessportal-logo.svg, 600×200). Verwendet auf Meldung (publisher) und Startseite.
• newsroomUrl() / newsroomId() — @id = {newsroom-url}#organization. Die Newsroom-Seite trägt sie, NewsArticle.author verweist darauf.
• Bewusst nicht ins Organization-Markup: Adresse, E-Mail, Telefon. Die Newsroom-Seite zeigt sie nicht, und Markup ohne sichtbares Gegenstück ist gegen Googles Richtlinien.

Tests: StructuredDataTest erweitert (Publisher-@id, Logo, Author-@id, Newsroom-@id).

2.2 — Google News, technischer Teil (17.09.2026)

Umsetzung: News-Sitemap je Spoke: /sitemap-news.xml (NewsSitemapController) — nur im Archiv sichtbare Meldungen der letzten 48 Stunden, höchstens 1.000, news:publication mit Portalname und Sprache (language der Meldung, Fallback de), news:publication_date, news:title. 15 Minuten gecacht je Host, wird mit den anderen Sitemaps über WebCaches::forgetSitemaps() geleert. robots.txt der Spokes nennt sie; der Hub liefert eine leere Liste und nennt sie nicht.

Was jetzt beim Betreiber liegt (nicht im Code):

1. Search Console: beide Spokes als Property bestätigt haben.
2. Publisher Center (publishercenter.google.com): je Portal eine Publikation anlegen — Name exakt wie in news:name („presseecho", „businessportal24"), Sprache Deutsch, Standort DE, Website-URL des Portals; Logo (quadratisch und rechteckig) hochladen.
3. In der Publikation den Bereich „Google News" einrichten: Abschnitte (z. B. die Kategorien) als Feed oder Web-Bereich anlegen; die News-Sitemap wird nicht dort, sondern in der Search Console eingereicht (Sitemaps → /sitemap-news.xml).
4. Erwartung ehrlich halten: Google News nimmt Presseportale nicht verlässlich auf („Pressemitteilungen" sind laut Inhaltsrichtlinien zulässig, aber kein bevorzugter Inhalt). Die Sitemap ist die Voraussetzung, keine Zusage. Ergebnis nach 4–6 Wochen in der Search Console unter „Leistung → Google News" ablesen.

Tests: NewsSitemapTest (3).

2.7 — Auffindbarkeit für KI-Systeme (17.09.2026)

Umsetzung: /llms.txt je Host (LlmsTxtController, 1 h gecacht): Titel, Kurzbeschreibung (Tagline aus config/domains.php), sachlicher Absatz zu Urheberschaft (Unternehmen = Urheber, Portal = Herausgeber) und zu den strukturierten Daten, URL-Aufbau (Meldung, Newsroom, Kategorie, Sitemaps), aktive Kategorien mit Links, Seiten für Unternehmen, Rechtliches. Der Hub verweist auf beide Portale und die OpenAPI-Datei. Formulierungsgrenze eingehalten: keine Aussage darüber, ob oder wie KI-Systeme die Inhalte verwenden. Die Entitätszuordnung aus 2.1 (@id zwischen Meldung und Newsroom) ist der zweite Teil von 2.7.

Tests: LlmsTxtTest (2).

2.3 — Branchen-Landingpages aus dem Archivbestand (17.09.2026)

Befund (Dev-DB = Live-Kopie): 34.597 sichtbare Meldungen seit 2008 (presseecho 12.587, businessportal24 22.010), 14 Hauptkategorien ohne Unterkategorien. Die Branchenseiten (/de/category/{slug}) existieren seit Juli mit Lead/Top/Feed, Statistik, Newsrooms — zeigen aber nur die jüngsten ~15 Meldungen. Der Bestand hing nur an der Sitemap, nicht an internen Links. Dazu: 0 von 14 Kategorien haben eine Beschreibung, alle Branchenseiten zeigten denselben Standardsatz (14 gleich aussehende Seiten); und der Seitentitel hieß auf beiden Spokes „– pressekonto" (config('app.name') statt Portalname) — behoben. „Sonstiges" trägt 9.607 Meldungen (28 %), ist also keine Branche, sondern der Sammelposten; das ist ein Einlieferungs-Thema, kein Seitenthema.

Umsetzung:

1. Jahresarchiv je Branche — /de/category/{slug}/archiv/{jahr} (CategoryArchivePageData, CategoryArchiveController, View kategorie-archiv): 30 Meldungen je Seite, neueste zuerst, Datum mit Jahr, Firma, Rubrik; Jahresleiste mit Zahlen; ohne Jahr das jüngste Jahr mit Meldungen. Jahr statt fortlaufender Seitennummer, weil eine Jahresseite ihren Inhalt behält, während ?page=2 bei jeder neuen Meldung verrutscht. Canonical mit ?page=N auf Folgeseiten (der Layout-Default hätte auf Seite 1 kanonisiert), hreflang nur auf Seite 1, CollectionPage + BreadcrumbList als JSON-LD. Gecacht bis Seite 3 je Jahr (Schutz gegen Cache-Aufblähung wie bei den Newsrooms). Leere Jahre, unbekannte Kategorien und leere Folgeseiten sind 404.
2. Jahresleiste auf der Branchenseite unter dem Feed (archiveYears, eine gruppierte Query), und alle Jahresarchive in der Sitemap (14 × ~18 Jahre ≈ 250 URLs).
3. Beschreibungen: categories:seed-descriptions {--dry-run} {--force} füllt leere DE/EN-Beschreibungen aus database/seeders/data/category-descriptions.php (je 2–3 Sätze: Themenumfang und wer dort veröffentlicht, ohne Werbeaussagen). Nur leere Felder, danach in Admin ▸ Kategorien änderbar. Dry-Run auf der Dev-DB: alle 14 Kategorien gefunden.

Tests: CategoryArchiveTest (5), SeedCategoryDescriptionsTest (2); tests/Feature/Web komplett grün (305).

Live: php artisan categories:seed-descriptions --dry-run, dann ohne Flag. Bewusst nicht gebaut: Landingpages unterhalb der Kategorien („Branchen" im engeren Sinn) — dafür gibt es keine Unterkategorien und keine Daten; die Meldungen tragen nur die 14 Hauptkategorien.

2.4 — Transparenzseiten (17.09.2026, nach Briefing)

Zuschnitt aus dem Briefing: kein Preisvergleich Anbieter gegen Anbieter, sondern (a) Modellvergleich ohne Namen und fremde Preise und (b) ein internes Rechenbeispiel mit den eigenen Optionen. Aus dem einen Roadmap-Punkt wurden drei Seiten mit unterschiedlicher Suchintention, alle auf Hub und Spokes, DE und EN:

URL	Sucht danach
/{edition}/was-kostet-eine-pressemitteilung	Preis, Vergleich, Budget
/{edition}/pressemitteilung-veroeffentlichen-ohne-abo	Ablehnung eines Modells
/{edition}/pressemitteilung-loeschen-oder-aendern-lassen	akutes Problem, oft bei einem anderen Portal

Umsetzung: TransparencyPageController + PricingTransparencyData — alle Zahlen aus config/billing, config/credits, config/legal und dem Starter-Tarif (19 € Einzel, 29 €/3 Meldungen Starter, 15 € Extra-PM, 10 € Änderung, 35 € Depublikation, USt.), damit die Seiten nie einen anderen Preis nennen als die Preisübersicht. Texte in lang/{de,en}/static.php (cost, no_subscription, change_delete). Tabellen-Typografie für .pm-body ergänzt (Asset-Build nötig).

Seite 1, Aufbau wie im Briefing: kurze Antwort im ersten Bildschirm → vier Abrechnungsmodelle und was sie bei seltener Nutzung kosten → sechs Prüffragen für Folgekosten → „Was bei uns gilt" (dieselben sechs Fragen beantwortet plus eine siebte: abgelehnte Meldungen kosten nichts) → Rechenbeispiel Einzelabrechnung gegen bei Bedarf gebuchte Starter-Monate: 1 Meldung 19 vs. 29 (Einzel), 3 im selben Monat 57 vs. 29 (Starter), 3 verteilt 57 vs. 87 (Einzel), 12 monatlich 228 vs. 348 (Einzel), 12 in 4 Monaten 228 vs. 116 (Starter). Der Test TransparencyPagesTest erzwingt, dass beide Modelle Zeilen gewinnen.

Seite 2: Ablauf in vier Schritten, was enthalten ist, was nicht (kein Versand an Redaktionen, keine Platzierungsgarantie, keine Zusage über Rankings oder KI-Nennungen — Formulierungsgrenze 2.7), nichts verfällt, wann sich ein Tarif trotzdem lohnt.

Seite 3: fünf Wege als Tabelle (Anliegen / Wer / Kosten / Ergebnis), Antragsweg über /melden/pm mit Bestätigungslink an die hinterlegte Pressekontaktadresse, „Korrektur statt Löschung", und der Absatz für fremde Portale: Impressum des Betreibers, DSA-Meldeweg und DSGVO-Anspruch gelten überall und sind kostenlos, Dienstleister ist Ansprechpartner für weitere Kopien — ohne Namen, ohne Zusagen über Dritte (docs/legal/Entscheidung.md).

Verlinkung: Preisübersicht (Zeile unter dem USt-Hinweis), Hilfe-Center („Korrekturen nach Veröffentlichung" zeigt jetzt auf Seite 3 statt FAQ), Sitemaps Hub + Spokes, llms.txt, untereinander.

Bitte gegenlesen — drei Tatsachenbehauptungen, die ich aus Code und Konzept abgeleitet habe: (1) „Kein Versand an Redaktionen" (Seite 2), (2) „Konto anlegen ohne Zahlungsdaten" (Seite 2), (3) „Kunden mit Konto erledigen kleine Korrekturen direkt im Publisher-Bereich" (Seite 3, Selbstbedienungskorrektur legal.corrections_per_week). Die „sieben Zusagen" haben keine kanonische Liste in den Konzepten; die Fassung auf Seite 1 ist aus Preisseite, AGB-Hinweisen und Decision-Update Preisstruktur zusammengesetzt.

Tests: TransparencyPagesTest (9). Nicht gebaut: fremde Zahlen, auch nicht als datierte Erhebung (Empfehlung im Briefing: lassen).

Befund zu 2.5 / E5

Die alte Ratgeber-Strecke /de/presse/*.html leitet seit dem Rückbau (R3.2) per 301 auf /de/faq. Es gibt also keine Ratgeberseiten mehr, die zu konsolidieren wären — die Frage E5 reduziert sich darauf, ob die Alt-URLs zum Schreiben von Pressemitteilungen künftig auf die Hilfeseite /de/gute-pressemitteilung (1d.1) statt auf die FAQ zeigen sollen. Empfehlung: ja für Slugs, die erkennbar das Schreiben betreffen, sonst FAQ. Braucht die Liste der Alt-Slugs aus dem Webserver-Log oder der Search Console; ohne die bleibt es bei FAQ.

Deploy (2.1–2.4/2.7): kein migrate, Asset-Build (npm run build, neue Tabellen-Styles), view:cache/route:cache wie üblich, dann categories:seed-descriptions. Danach /sitemap-news.xml, /llms.txt, /de/category/handel/archiv/2019 und eine Meldung im Rich-Results-Test (search.google.com/test/rich-results) prüfen.

Teil 8 — Anhang 1 zur Roadmap (17.09.2026)

Grundlage: roadmap-anhang1-2026.md. 2.6 (Zuschriften an Betreiber) bewusst ausgelassen — übernimmt der Betreiber an anderer Stelle. 2.7 war mit Teil 7 bereits gebaut; die Formulierungsgrenze (Abruf belegbar, Nennung nicht) gilt in allen neuen Texten.

1c.0 Crawler-Abruf-Protokoll

Tabelle press_release_crawler_hits (Meldung, Dienst, User-Agent auf 255 Zeichen gekürzt, Zeitpunkt — keine IP). Erkennung über config/crawlers.php: 15 Dienste mit User-Agent-Mustern und Art (Suche/KI) — OpenAI, Anthropic, Perplexity, Google-Extended (Gemini), Google Suche, Bing/Copilot, Apple, Meta, Amazon, Mistral, Cohere, DuckDuckGo, ByteDance, Common Crawl, Yandex. Die Liste ist Konfiguration, neue Dienste kommen ohne Code dazu. Aufzeichnung in ReleaseDetailPageData neben dem Aufruf-Zähler, per defer() nach der Antwort und fehlertolerant (PressRelease::recordDeferredCrawlerHit). Bereinigung hängt an press-releases:purge-events (gleiche Aufbewahrung, keine Wasserstandsmarke nötig). crawlers.recorded_since (Vorgabe 18.09.2026, per CRAWLER_HITS_RECORDED_SINCE auf den Deploy-Tag setzen) sagt der Absenderansicht, ab wann es Daten geben kann.

Dev-Probe: Abruf mit GPTBot-User-Agent → eine Zeile openai; Browser → nichts.

1c.1 Stufe 1 — Panel umgebaut

Panel heißt jetzt „Auslieferung", nicht mehr „Sichtbarkeit". Der Google-Button (Variante B, site:-Suche) ist raus — er lieferte ein unvollständiges Ergebnis ohne Einordnung. Geblieben: Aufrufe gesamt, Aufrufe im Zeitraum, Geteilt, Tagesbalken, „Sitemap für Suchmaschinen: gelistet seit". Feeds gibt es auf den Portalen nicht (kein RSS), deshalb kein Feed-Eintrag.

1c.6 Abrufe durch Such- und KI-Dienste

Block im Panel: je Dienst Bezeichnung, Art (Suche/KI), letzter Abruf, Anzahl. Darunter der Satz „Ein Abruf belegt, dass der Crawler des Dienstes die Seite geholt hat — nicht, dass sie dort angezeigt oder zitiert wird." Ohne Abrufe: „Noch kein Abruf protokolliert" plus Datum, ab dem erfasst wird.

1c.4 Indexierungsstatus (Search Console), intern

• config/search_console.php: GSC_ENABLED, GSC_SERVICE_ACCOUNT_FILE (JSON-Schlüssel eines Service-Kontos, außerhalb public/), GSC_PROPERTY_PRESSEECHO / GSC_PROPERTY_BUSINESSPORTAL24 (Vorgabe sc-domain:…), GSC_DAILY_BUDGET (300 je Portal, Quote 2.000), GSC_CUSTOMER_VISIBLE (false, E8).
• SearchConsoleClient: Service-Konto-JWT (RS256 per openssl_sign), Token 50 Minuten gecacht, ein Endpunkt (urlInspection/index:inspect). Bewusst ohne Google-SDK — keine neue Abhängigkeit.
• Tabelle press_release_index_checks: jede Antwort eine Zeile mit Zeitstempel (Momentaufnahme, kein Verlauf nachträglich), Google-Felder einzeln plus raw, dazu der reduzierte Befund IndexState: indexiert / gecrawlt, nicht indexiert / noch nicht gecrawlt / ausgeschlossen / unbekannt. „Noch nicht gecrawlt" = kein lastCrawlTime.
• press-releases:check-index-status täglich 05:10, je Portal ein Kontingent, nach Alter gestaffelt (recheck_days: ≤14 Tage alle 3, ≤90 alle 14, ≤365 alle 45, älter alle 180), nie geprüfte zuerst, dann jüngste zuerst. Abbruch nach fünf Fehlern ohne Treffer (Quote/Auth). --dry-run listet, --portal=, --budget=.
• Admin ▸ Reports ▸ Indexierung (/admin/reports/indexierung): je Portal Verteilung der Befunde, getrennt nach Direkteinreichung und Syndikation (Marker: Status-Log source = api), Ungeprüfte, jüngste 100 Prüfungen, CSV (2.000). Einschränkung: Der Altbestand hat keine Status-Logs und zählt als „direkt" — die Trennung ist nur für Meldungen seit dem neuen System belastbar (Dev: presseecho 10.971 direkt / 1.616 API, businessportal24 20.349 / …).
• Kundenansicht (E8, mitgebaut, zu): Block „Google-Index" im Panel erscheint nur mit GSC_CUSTOMER_VISIBLE=true, zeigt je Portal den jüngsten Befund mit Datum und „zuletzt gecrawlt". Test erzwingt, dass der Block ohne Freigabe nicht ausgeliefert wird.

Live seit 17.09.2026. Service-Konto angelegt, Schlüsseldatei unter config/files/ (per .gitignore ausgeschlossen, liegt nur auf dem Server), GSC_ENABLED=true, Kontingent 300. Zugang gegen die Live-Property geprüft (https://www.presseecho.de/ → „Page with redirect", zuletzt gecrawlt 16.09.2026).

Nachtrag (Commit b44fded): Die API übersetzt coverageState in die angefragte Sprache; mit de-DE kam „Seite mit Weiterleitung" zurück und IndexState::fromIndexStatus() griff ins Leere. Abfrage jetzt immer en-US; die Enum-Felder (verdict, indexingState, robotsTxtState, pageFetchState) sind sprachunabhängig.

Zum Kontingent: GSC_DAILY_BUDGET = Abfragen je Lauf und je Portal (300 → 600 Calls/Tag, Quote 2.000 je Property). Bei ~31.000 sichtbaren Meldungen ist der Bestand nach rund 100 Tagen einmal durch; die jungen Meldungen, um die es bei 1c.5 geht, sind nach Tagen drin. Schneller: vorübergehend 1.000, oder einmalig von Hand press-releases:check-index-status --budget=1500.

1d Erstquelle gegen Kopie

Absatz in der Veröffentlichungsmail, nur bei Meldungen, die über die API eingegangen sind (PressReleasePublished::$viaSyndication, Marker wie beim Empfängerwechsel): Verteiler-Text liegt gleichlautend auf vielen Portalen und hat keine erkennbare Erstquelle; eine direkt eingereichte Meldung erscheint als Erstquelle mit strukturierten Daten, geprüften Angaben, stabiler Adresse. Kein Preis, kein Angebot, kein Link — der Test prüft, dass kein Euro-Zeichen im Absatz steht und direkte Meldungen den Absatz nicht bekommen.

2.4 Vierte Seite: /pressemitteilung-kostenlos-veroeffentlichen

Aufbau nach Anhang: kurze Antwort (Preis, kein kostenloser Weg, E7 als Grundsatz), was kostenlose Portale leisten und was nicht, warum Links aus Presseportalen kaum tragen (inklusive der Aussage, dass unsere externen Links ebenfalls sponsored nofollow tragen — Link-Policy seit 11.06.2026, sonst wäre der Abschnitt unehrlich), warum kostenfreie Annahme und Prüfung sich ausschließen, wer am Ende zahlt, CTA ohne Verkaufsdruck auf „Ohne Abo veröffentlichen".

Liste kostenloser Portale: vorbereitet, leer. Jeder Eintrag ist eine Tatsachenbehauptung über einen Dritten; ich habe keine geprüfte Liste. config/transparency.php (free_portals als Name/URL/Notiz, TRANSPARENCY_FREE_PORTALS_CHECKED_AT = Prüfdatum). Der Abschnitt erscheint nur, wenn beides gesetzt ist, Links dort rel="nofollow", mit dem Hinweis, dass kein Eintrag eine Empfehlung ist.

Unter-Navigation hat jetzt fünf Punkte; Modelltabelle auf Seite 1 verlinkt bei „Kostenlos mit Auflagen" auf die neue Seite; Hilfe-Center, Sitemaps, llms.txt, Legacy-Slug-Liste ergänzt.

E7

Keine Stelle im Web-Auftritt verspricht kostenlose Veröffentlichung (geprüft: lang/*, resources/views/web). „Kostenlos" steht nur bei Konto, Newsroom-Zugang, Meldeverfahren und kleinen Korrekturen — alles zutreffend.

Tests / Qualität

CrawlerHitLogTest (4), VisibilityStatsTest (umgebaut, 7), IndexStatusCheckTest (11, API per Http::fake), AddressUnsubscribeTest (+1), TransparencyPagesTest (11). Pint, Larastan Level 4 ohne Befund.

Deploy: migrate (zwei neue Tabellen, keine Änderung an press_releases), npm run build, view:cache/route:cache, CRAWLER_HITS_RECORDED_SINCE auf den Deploy-Tag setzen. Search Console erst nach Einrichtung des Service-Kontos einschalten.

2.5 / E5 geschlossen (17.09.2026)

Entscheidung: bleibt bei der 301 auf /faq, kein Slug-Mapping. Die Inhalte trägt das Hilfe-Center. Dafür steht Hilfe jetzt in der Topleiste der Portale neben FAQ (Desktop) und im Burger-Menü unter den Service-Links (Mobile); der Hub hatte den Link bereits.

Teil 9 — Anhang 2: Doppelveröffentlichung und Quellenauskunft (17.09.2026)

Grundlage: roadmap-anhang2-2026.md. Commits siehe unten. Der Mechanismus ist gebaut und getestet, aber ausgeschaltet (CANONICAL_ASSIGNMENT_ENABLED=false), weil E9 — welche Kategorie auf welches Portal — eine Betreiberentscheidung ist. Der Vorschlag steht in config/canonical.php.

Befund (Dev-Kopie, Stand 17.09.2026)

• 34.597 sichtbare Meldungen, davon 9.092 Paare gleichen Textes derselben Firma auf beiden Portalen = 18.184 URLs, 53 % des Archivs. Seit dem neuen System (07/2026): 1.338 Paare — die API reicht praktisch jede Meldung zweimal ein, je Portal eine eigene Zeile mit gleichem Slug.
• portal = both wird bei Meldungen nicht genutzt (0), nur bei Firmen und Kategorien (alle 14 Kategorien sind both, Paare teilen die category_id).
• Je Hauptkategorie: sonstiges 3.087, it 1.190, politik 1.117, haus 739, handel 572, reisen 419, kultur 404, sport 356, mode 323, motor-verkehr 319, finanzen 170, medizin 149, wissenschaft-forschung 142, recht 105.
• Bisher: jede Fassung self-canonical je Host, beide in beiden Sitemaps — Google wählt.

1c.7 Prüfsumme

press_releases.content_hash (SHA-256 über Titel + Text ohne Markup, Leerraum zusammengezogen, Kleinschreibung — App\Support\ContentFingerprint), gesetzt im Model beim Speichern; Bestand per press-releases:hash-content (Query-Builder, Blöcke, keine Model-Events; Dev: 179.242 Zeilen in 8:47 min). Migration in zwei Statements: ADD COLUMN INSTANT, ADD INDEX INPLACE — kein Rebuild der 1-GB-Tabelle (MySQL 8.0.45). press-releases:duplicates-report liefert die Zahlen oben.

1c.8 Kanonische Zuordnung

press_releases.canonical_press_release_id (kein FK, siehe Migration). CanonicalAssigner: Paar = gleicher Hash, gleiche Firma, verschiedene Portale, beide veröffentlicht. Erstquelle = Fassung auf dem Kategorie-Portal (portal_by_category, DE-Slug der Hauptkategorie), sonst fallback (first = zuerst veröffentlicht; oder ein Portalname). Die zweite Fassung bekommt den Verweis, die erste wird geleert. Läuft bei jeder Veröffentlichung (PressReleaseService::publish, fehlertolerant) und über den Bestand mit press-releases:assign-canonicals (Dev: 9.092 Paare in Sekunden; --dry-run zeigt die Wirkung auch bei ausgeschaltetem Flag).

Wirkung bei eingeschaltetem Flag: Detailseite der Kopie trägt rel=canonical und mainEntityOfPage auf die Erstquelle; Sitemap und News-Sitemap nennen nur die Erstquelle; Leser, Feeds, Newsroom und interne Suche sehen weiterhin beide. portal = both-Meldungen folgen derselben Zuordnung beim Rendern (Canonical auf das Kategorie-Portal), obwohl es derzeit keine gibt.

E9-Vorschlag (in config/canonical.php): businessportal24 für finanzen, handel, it, recht, wissenschaft-forschung, motor-verkehr; presseecho für haus, kultur, medizin, mode, politik, reisen, sport, sonstiges. Damit gehen ~6.600 Erstquellen an presseecho und ~2.500 an businessportal24 — „sonstiges" (3.087) ist der Hebel; wer es auf businessportal24 legt, dreht das Verhältnis.

1c.9 Quellenauskunft

press_release_index_checks.user_canonical wird seit diesem Stand mitgespeichert. IndexStatusChecker::sourceVerdict() unterscheidet: Google führt diese Adresse / die eigene Fassung auf dem anderen Portal / ein fremdes Portal / keine Angabe. Anzeige im Block „Google-Index" der Absenderansicht — hinter GSC_CUSTOMER_VISIBLE, also zu, mit dem Satz, dass das Warum nicht bekannt ist. Reihenfolge aus Abschnitt 4 ist damit eingehalten: erst Zuordnung (Flag), dann Auskunft (Flag).

Abschnitt 5 — Beschreibung des Angebots

Geprüft: Preisseite, Transparenzseiten, FAQ, Veröffentlichungsmail. Alle Stellen sagen „erscheint auf beiden Portalen" — Fundstellen für Leser, nirgends „zweimal in der Suche". Keine Korrektur nötig. Ergänzt: Abschnitt „Warum eine Meldung mehrfach im Netz steht und nur einmal in den Suchergebnissen" auf /gute-pressemitteilung (Verteiler → viele Kopien, eine Quelle; eigene Website zuerst; keine Garantie). Der Satz „bei uns verweist die zweite Fassung auf die erste" erscheint erst mit eingeschaltetem Flag.

Abschnitt 7 — pressekonto.com

<meta name="robots" content="noindex, nofollow"> jetzt in allen Portal-Layouts (Admin, Kundenbereich unter /admin/me, Login/ Registrierung). robots.txt hatte /admin, /login, /register schon ausgeschlossen — Disallow allein verhindert keine Aufnahme über Links.

E10 (offen), mit Befund: Die Transparenzseiten und alle anderen statischen Seiten (faq, hilfe, agb, …) existieren auf drei Hosts mit je eigenem Self-Canonical — dieselbe Doppelung wie bei den Meldungen, nur dreifach. Empfehlung: Canonical der Transparenzseiten auf die Portale (ältere Domains), der Hub verweist; welches Portal, hängt an E9-Logik nicht, hier reicht presseecho als Standard. Nicht umgesetzt, wartet auf die Entscheidung.

Tests / Deploy

CanonicalAssignmentTest (9), UmamiSnippetTest von der lokalen .env entkoppelt. Pint, Larastan ohne Befund.

Deploy: migrate (INSTANT/INPLACE auf press_releases, trotzdem DB_LOCK_WAIT_TIMEOUT=300 mitgeben), danach php artisan press-releases:hash-content (läuft ~10 min, kann im Hintergrund), dann press-releases:duplicates-report. Erst nach E9: CANONICAL_ASSIGNMENT_ENABLED=true, press-releases:assign-canonicals --dry-run, dann ohne Flag, view:cache, Sitemaps prüfen.

Teil 10 — E9 und E10 entschieden, Hub-Erreichbarkeit geprüft (18.09.2026)

E9 — kanonische Zuordnung aktiv

Zuordnung wie vorgeschlagen übernommen (config/canonical.php): businessportal24 führt finanzen, handel, it, recht, wissenschaft-forschung, motor-verkehr; presseecho führt haus, kultur, medizin, mode, politik, reisen, sport, sonstiges. CANONICAL_ASSIGNMENT_ENABLED steht jetzt standardmäßig auf true — ohne .env-Eintrag ist die Zuordnung an.

Auf der Dev-Kopie verifiziert: 9.092 Paare zugeordnet, die Kopie trägt rel=canonical auf die Erstquelle, steht nicht mehr in der Sitemap ihres Portals, die Erstquelle schon.

E10 — eine Adresse je Text, Rechtstexte ausgenommen

Befund: faq, hilfe, gute-pressemitteilung, die vier Transparenzseiten, api und alle Rechtstexte liegen auf allen drei Hosts mit identischem Text (nur Markenname getauscht, per Prüfsumme bestätigt) und trugen je einen eigenen Self-Canonical.

Umgesetzt (config/canonical.static_page_host, App\Support\StaticPageCanonical):

Seiten	Führender Host
faq, hilfe, gute-pressemitteilung, 4 Transparenzseiten	presseecho
api (Doku des Publisher-Bereichs)	pressekonto
impressum, datenschutz, agb, richtlinien, melden, kuendigung	je Host selbst

Rechtstexte bewusst ausgenommen — das ist eine Abweichung von „alles auf die Portale". Jede Domain ist ein eigenes Angebot mit eigener Anbieterkennzeichnung und eigenem Meldeweg; wer auf businessportal24.com das Impressum aufruft, muss das Impressum dieser Domain bekommen, und es muss für sich auffindbar bleiben. Ein Canonical auf eine fremde Domain würde dem widersprechen. Inhaltlich sind die Texte identisch — das ist bei Pflichtangaben unkritisch.

Mitgezogen: Sitemap listet je Seite nur noch den führenden Host (Hub behält api + Rechtstexte), llms.txt nennt die führende Adresse, og:url folgt dem Canonical.

Erreichbarkeit pressekonto.com — geprüft, drei Befunde

Alle 24 Hub-Adressen und jeder Link der Hub-Startseite geprüft: alles 200, unbekannte Pfade 404, sitemap.xml, sitemap-news.xml, llms.txt, robots.txt, /docs/api/v1 in Ordnung.

1. Portalseiten unter pressekonto.com (behoben): /de/preise, /de/veroeffentlichen, /de/newsrooms, /de/suche wurden auf dem Hub ausgeliefert — mit dem Branding und Titel von businessportal24, weil WebPortalContext::fromRequest() auf dem Hub auf dieses Portal zurückfällt. Jetzt 301 auf presseecho (RedirectPortalOnlyPagesFromHub, web-Gruppe). Die Transparenz-Navigation verlinkt „Tarife & Preise" auf dem Hub direkt auf presseecho, ohne Umweg über die Weiterleitung.

2. Weiterleitungskette (behoben): /de/kontakt und /de/ueber-uns zeigten auf /de, das auf dem Hub selbst auf / weiterleitet — zwei Sprünge. Jetzt direkt auf die Startseite des jeweiligen Hosts.

3. Portal-Inhalte unter pressekonto.com (behoben am 18.09.2026 nach Freigabe): /de/category/{slug}, /de/category/{slug}/archiv/{jahr}, /de/press-release/{slug}, /de/newsroom/{slug} und /de/newsroom/{slug}/verwalten waren auf dem Hub erreichbar und renderten das Portal, weil die Ausgabe-Routen für alle Hosts gelten. Jetzt 301 (canonical.portal_only_content_routes):

   • Meldung und Newsroom folgen ihrem eigenen Portal, nicht einer festen Vorgabe. Bei Doppelveröffentlichung tragen beide Fassungen denselben Slug — dann gewinnt die Erstquelle (canonical_press_release_id is null), sonst landete die Weiterleitung auf der Kopie.
   • Kategorie, Jahresarchiv und Suche gibt es auf beiden Portalen: dort entscheidet portal_only_host (presseecho).
   • Unbekannter Slug wird nicht weitergeleitet — sonst entstünde eine 301-Kette in ein 404 auf dem Portal. Der Hub antwortet wie bisher 404.
   • Nur GET. Ein 301 auf POST würde die Anfrage verlieren; Newsroom beanspruchen und Share-Zählung laufen weiter.
   • Query-Parameter bleiben erhalten (/de/suche?q=…).

Technischer Nebeneffekt: Der Self-Canonical kommt jetzt aus dem tatsächlich aufgerufenen Host (StaticPageCanonical::selfBase()) statt aus der geteilten Domain-Config. Portal-Inhalte behalten ihr Portal — WebPortalContext::fromRequest() setzt dafür den Merker webPortalContextApplied.

Tests / Deploy

HubPortalPageRedirectTest (19), angepasste Sitemap-Erwartungen in StaticPagesTest und TransparencyPagesTest. Gesamtlauf 1.804 grün (eine Ausnahme: ManualInvoicePdfTest schlägt unabhängig von diesen Änderungen fehl — mit und ohne Stash reproduziert, Anrede „Frau Erika Muster" fehlt; gehört zum Rechnungs-Paket).

Deploy: view:cache/route:cache neu, php artisan cache:clear für die Sitemap-Caches (1 h TTL). E9 ist ohne .env-Eintrag aktiv — davor müssen press-releases:hash-content und press-releases:assign-canonicals gelaufen sein, sonst passiert schlicht nichts.

Nachtrag 18.09.2026 — Admin-Bericht „Indexierung & Abrufe"

Fehler auf Live: Bericht meldete „nicht konfiguriert", obwohl der Lauf Daten holte. Ursache: GSC_SERVICE_ACCOUNT_FILE relativ (config/files/…), is_readable() hing am Arbeitsverzeichnis — Cron in der Projektwurzel lesbar, Web-Request in public/ nicht. Relative Pfade werden jetzt ab base_path() aufgelöst.

Bericht erweitert (/admin/reports/indexierung):

• Verteilung je Portal jetzt nach Herkunft und Rolle (Erstquelle / Kopie mit Verweis, 1c.8). Seit E9 aktiv ist, ist „ausgeschlossen" bei Kopien der erwartete Befund und kein Problem; ohne die Trennung wäre die Quote unlesbar. Erwarteter Befund je Zeile fett.
• Quellenbefund (1c.9) über Erstquellen: Google führt diese Adresse / eigene Fassung auf dem anderen Portal / fremdes Portal (mit Top-Hosts) / keine Angabe. In den jüngsten Prüfungen als Spalte „Google führt".
• Abrufe durch Such- und KI-Dienste (1c.0): je Dienst Abrufe und Meldungen im Zeitraum (7/30/90 Tage), gesamt, letzter Abruf; Tagesbalken 14 Tage getrennt Suche/KI; meistabgerufene Meldungen; CSV. App\Services\PressRelease\CrawlerHitReport.
• Herkunftsmarker als Join statt korreliertem EXISTS (2,6 s → 0,3 s je Portal), Verteilung und Quellenbefund 15 min gecacht. Seite warm 0,5 s.

Dev-Verteilung presseecho (Bestand): direkt 8.845 Erstquellen / 2.126 Kopien, API 1.308 / 308.

Teil 11 — Abschluss Block 0–2, Block 3.1 RSS-Feeds (18.09.2026)

Sichtung des Ordners (18.09.2026)

Alle Dokumente in dev/2026-09-01/ gegen Code und Git-Stand abgeglichen. Befunde und was daraus wurde:

Befund	Erledigt
GSC_PROPERTY_BUSINESSPORTAL24 hatte als Vorgabe sc-domain:businessportal24.de, die Property ist .com	Vorgabe in config/search_console.php und .env.example korrigiert (live ist der Wert explizit gesetzt)
Anhang 1: Tippfehler in der Übersicht, 1c.2/1c.3/2.7 nicht abgehakt	angeglichen
Protokoll: „Teil 5" und „Teil 6" doppelt vergeben	zweite Serie ist jetzt Teil 7–10, Verweise in Roadmap und Anhang 2 nachgezogen
Log-Aufteilung je Thema lag uncommittet auf dem Branch	Commit 2ec6169 (billing, ki, monitoring, market als Tagesdateien; Suite loggt nur nach testing-*.log)
docs/weiteres: Decision-Update Duplicate-Content gelöscht, Verlinkung & Backlinks wieder da	Duplicate-Content ist durch Anhang 2 überholt (entfernt, README-Index nachgezogen); Verlinkung bleibt als Referenz für die Link-Policy
E6 stand offen, ist aber in 1d.1/1d.2 umgesetzt	als entschieden geführt
2.6 Zuschriften	extern, in Arbeit beim Betreiber — nicht Teil der Umsetzung
1c.5/E8	Indexierungsprüfung läuft täglich; Entscheidung, sobald die Verteilung belastbar ist

Bleibt offen, bewusst nicht aus dem Code heraus erledigt:

• 0.7: Absatz zur Ereignistabelle (Zweck, Umfang, 395 Tage, Rechtsgrundlage) in der Datenschutzerklärung — Rechtstext, Betreiber.
• 0.1: Kohortenwerte „28–55 Tage" vom Live-System (Fenster 01.06.–01.09.) einmal erheben und ablegen: php artisan press-releases:view-distribution --from=2026-06-01 --to=2026-09-01 --json > dev/2026-09-01/basiswert-0.1.json.
• Abbruchbedingungen der Blöcke 1–3 tragen weiter Platzhalter für Zeitraum und Schwellwert; Block 1 läuft seit 17.09. ohne festen Vergleichspunkt.
• 2.2 Publisher Center (Betreiber), Ergebnis nach 4–6 Wochen in der Search Console.

3.1 — RSS-Feeds je Branche

Stand vorher: keine Feeds (siehe 1c.1: „keine Feeds vorhanden, daher kein Feed-Eintrag").

Umsetzung (FeedController, web.feed-View):

• /{edition}/feed — alle Meldungen der Ausgabe (Portal × Sprache); /{edition}/category/{slug}/feed — Branche inklusive aktiver Unterkategorien, wie die Branchenseite. Jeweils die jüngsten 50, neueste zuerst, nur visibleInArchive (kein Termin in der Zukunft, kein 410).
• RSS 2.0 mit atom:link rel="self", dc:creator = Firmenname, category = lokalisierter Branchenname, guid = Permalink, Teaser 300 Zeichen ohne Markup. Kanaltitel „Pressemitteilungen {Branche} – {Portal}", Beschreibung aus der Kategoriebeschreibung (2.3), sonst Tagline.
• Bei Doppelveröffentlichung führt jedes Portal seine eigene Fassung — Leser und Feeds sehen beide (Anhang 2, Abschnitt 1); nur die Suchmaschine bekommt die Erstquelle. Kein Canonical-Filter im Feed.
• Cache wie die Seitendaten (WebPageCache, 5 min frisch, bis 1 h stale mit Neuaufbau nach der Antwort); WebCaches::forgetPublicPages() leert ihn mit. Eine Korrektur (nur forgetSitemaps()) erscheint im Feed nach spätestens fünf Minuten — hingenommen.
• Hub: feed und kategorie.feed in canonical.portal_only_content_routes → 301 auf presseecho, wie Kategorie und Archiv.
• Autodiscovery: @yield('feed_links') im Web-Layout; Startseiten nennen den Portal-Feed, Branchenseite Branchen- und Portal-Feed, Jahresarchiv den Branchen-Feed — Adressen aus der Portal-Basis, nicht aus url() (das liefert wegen forceRootUrl den Hub). Sichtbarer Link „RSS-Feed" in der Archiv-Leiste der Branchenseite; llms.txt nennt beide Muster.
• Absenderansicht: Block „RSS-Feeds" im Panel „Auslieferung" mit Branchen- und Portal-Feed je Portal der Meldung, plus dem Satz, dass Abonnenten uns nicht bekannt sind (VisibilityStats::feedLinks()).
• Übersetzungen unter web.rss — web.feed war schon die Meldungsliste der Startseite.

Nicht gebaut: Feeds je Newsroom (kein Arbeitspaket), Bild-Enclosures (zusätzliche Queries je Item, kein Bedarf benannt), Feed-Einträge in der Sitemap (Feeds gehören nicht hinein).

Tests: FeedTest (7 — Branche mit Kindern und Fremdportal, Portal-Feed, 404, englische Ausgabe, Autodiscovery + llms.txt, Hub-301, Cache), VisibilityStatsTest (+Feed-Links im Summary und im Panel). Pint, Larastan ohne Befund.

Deploy: view:cache/route:cache neu; kein migrate, kein cache:clear (neue Cache-Keys).

Nachtrag 21.09.2026 — Newsroom-Feeds, RSS-Seite, Topleiste

Auf Wunsch des Betreibers ergänzt:

• Feed je Newsroom: /{edition}/newsroom/{slug}/feed (FeedController::newsroom). Gleiche Sichtbarkeitsregel wie die Newsroom-Seite: aktive Firma, nicht entfernt, mindestens eine veröffentlichte Meldung — sonst 404. Die Sichtbarkeitsprüfung läuft vor dem Cache, damit Deaktivierung und Entfernung sofort greifen; eine in einer Zusammenführung aufgegangene Firma führt per 301 zum Feed des bleibenden Newsrooms (1a.3). Kanalbeschreibung aus dem Boilerplate. Newsroom-Seite: Autodiscovery (Newsroom- und Portal-Feed) und sichtbarer Link „RSS-Feed" in der Kopfzeile neben „Newsroom seit". Hub: 301 auf das Portal der Firma (RedirectPortalOnlyPagesFromHub).
• RSS-Übersichtsseite /{edition}/rss (RssPageController, web.rss, Texte static.rss.* DE/EN): Was RSS ist, wie ein Reader funktioniert (drei Schritte, Beispiele Feedly/Inoreader/NetNewsWire/ Thunderbird/Outlook), dann Hauptfeed, alle aktiven Top-Level-Branchen mit Feed-Adresse, Muster des Newsroom-Feeds mit Link auf die Newsroom-Übersicht, Hinweise (Ausgaben DE/EN, Schwesterportal, Anriss statt Volltext, keine Weiterverwendung). Portalseite wie Preise: Portal-Kontext angewendet (eine Route::view hätte auf presseecho das Branding von businessportal24 gezeigt), auf dem Hub 301 auf presseecho (portal_only_pages), in der Portal-Sitemap, in llms.txt.
• Topleiste: „RSS" neben FAQ · Hilfe · API (Desktop), im Burger-Menü unter den Service-Links und im Footer. Der Hub-Header hat die drei Links nicht und bekommt deshalb auch kein RSS.
• Panel „Auslieferung": je Portal jetzt Branchen-, Newsroom- und Portal-Feed.

Tests: FeedTest (+3: Newsroom-Feed mit Sichtbarkeit, Hub-301 aufs Firmenportal, Autodiscovery auf der Newsroom-Seite), RssPageTest (4), StaticPagesTest-Datensatz, VisibilityStatsTest. Pint, Larastan ohne Befund. Deploy unverändert: view:cache/route:cache.