Golems `…-2607-211258.html` hat drei Seiten; gespeichert wurde bisher
Seite 1 — 911 von rund 2400 Wörtern. Serverseitig ist da nichts zu holen:
Seite 2 liegt hinter derselben Zustimmungs-Wand wie Seite 1. Ein `fetch`
aus dem Tab bekommt sie (gemessen: 200, kein Redirect). Also sammelt der
Tab sie.
- `page-collector.js` (`collectPageta`) findet Folgeseiten ohne
quellenspezifische Selektoren: Zähler-Adressen (`-2.html`, `?page=2`,
`/seite/2/`), sonst die `rel="next"`-Kette. Deckel 20 Seiten / 6 MB,
300 ms Pause je Abruf. Läuft im Bookmarklet (Quelltext in der
`javascript:`-Adresse) und in der Erweiterung (`executeScript`) —
eine Quelle, zeichengleiche Kopie, von `check.mjs` erzwungen.
- Weiches Strippen vor dem Senden: `<style>/<noscript>/<template>` raus,
Skript-Inhalte geleert, Tags/Attribute und JSON-LD bleiben. Sonst
verlören `siteNameFromJsonLd` und die CMP-Signaturen ihre Grundlage.
Extraktions-Ergebnis nachweislich unverändert (the-decoder, winfuture).
- API nimmt `pages` (max 20) zusätzlich zu `html` und antwortet mit
`pageCount`; `merge-pages.ts` fügt in Lese-Reihenfolge zusammen.
`html` bleibt gültig — Bookmarklets werden nicht mitdeployt.
- Fehlt eine erkannte Seite, springt die add-Seite nicht weiter, sondern
sagt „x von y Seiten".
Am Golem-Artikel verifiziert: 3 Seiten, 0 fehlend, 298 KB statt ~1,2 MB.
Wer ein Bookmarklet installiert hat, muss es einmal neu ablegen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3dbd6611f2