capture-site

Speichert alles, was die Live-Seite ausliefert, einmalig, sodass jeder spätere Schritt auf der Erfassung basiert.

Die goldene Regel

Die Live-Seite ist schreibgeschützt, und die Erfassung ist danach ebenfalls schreibgeschützt. Die Skripte führen nur getaktete GET- und HEAD-Anfragen durch; sie senden niemals ein Formular ab, loggen sich nicht ein und holen nichts von Hand nach, um eine Lücke zu füllen. Sobald die Notizen geschrieben sind, wird unter capture/ nichts mehr bearbeitet: Es ist der Beweis, den jedes Gate liest.

Wann verwenden

Schritt 2 einer Konvertierung (convert-site führt ihn aus) oder immer dann, wenn eine Live-Seite inventarisiert werden muss (eine Staging- oder neue Seite ist Aufgabe von launch-audit). Eine Erfassung, die mit Exit 3 beendet wurde, wird wie unten beschrieben fortgesetzt.

Taktung

Jedes Skript sendet einen Desktop-Chrome-User-Agent. Die Erfassungsskripte (capture, media, assets, fingerprint) teilen sich einen Host-Limiter: Standardmäßig haben Anfragen einen Abstand von 400 ms bei bis zu 4 gleichzeitigen Anfragen (media: 6), sodass ein Host, der schnell antwortet, in Minuten gelesen ist. Die Chromium-Schritte (shoot, css-coverage, styles) laden jeweils eine Seite mit 500 ms Abstand, und launch-audit und pre-launch haben ihre eigene Taktung. Der Limiter passt sich selbstständig an:

ein 429 oder 503 verdoppelt die Verzögerung dieses Hosts (bis zum 32-fachen) und reduziert sie auf eine Anfrage gleichzeitig; nach jeweils 30 s sauberer Antworten wird eine Stufe zurückgesetzt (halbe Verzögerung, eine weitere gleichzeitige Anfrage), bis die Standardwerte wieder erreicht sind;
eine Antwort, die länger als 5 s dauert, halbiert die gleichzeitigen Anfragen auf diesem Host (nicht erneut, solange sie halbiert sind), und sie erholt sich auf die gleiche Weise, eine weitere gleichzeitige Anfrage pro 30 s sauberer Antworten;
ein 403 oder ein Netzwerkfehler zählt wie zuvor zu den 3 aufeinanderfolgenden Stopps unten.

--polite ist das alte Tempo: eine Anfrage gleichzeitig, 2500 ms Abstand (capture, media, assets). Verwenden Sie es von Anfang an bei Shared Hosting mit einer Bot-Wand (SiteGrounds /.well-known/sgcaptcha/, Hosts, die auf ein paar schnelle Anfragen mit 429 oder 503 antworten) oder wenn ein Lauf aufgrund von Blöcken gestoppt wurde: Setzen Sie ihn mit --polite fort. --delay <ms> und --concurrency <n> überschreiben die Standardeinstellungen oder --polite. Behalten Sie die Standardeinstellungen oder --polite gegen eine Live-Seite bei (--delay 0 ist nur für lokale Testdaten), und ändern Sie niemals --ua, um eine Blockierung zu umgehen.

capture holt bis zu --concurrency in der Warteschlange befindliche URLs voraus und zeichnet sie in der Warteschlangenreihenfolge auf, sodass die Erfassung mit einem Einzelseiten-Crawl identisch ist. Jede URL wird 3 Mal versucht. Eine nach diesen Versuchen weiterhin blockierte URL (403, 429, 503 oder ein Netzwerkfehler) wird mit ihrem Status und attempts in inventory.json aufgezeichnet (eine Sitemap oder REST-Liste in meta.json discoveryErrors) und der Crawl wird fortgesetzt. Er stoppt erst, nachdem 3 verschiedene URLs hintereinander ihre Versuche aufgebraucht haben, ohne dazwischen Erfolg zu haben, speichert den Zustand und stellt diese drei mit neuen Versuchen erneut in die Warteschlange. Er fordert niemals wp-admin, wp-login, xmlrpc.php oder ?s=-Suchen an.
media versucht jede Datei 3 Mal: Ein anhaltender 429 oder 503 stoppt es sofort; ein 403 oder Netzwerkfehler wird als Status dieser Datei aufgezeichnet, und 3 solcher Dateien hintereinander (in der Reihenfolge, in der die Antworten eintreffen) stoppen es. Dateien, die zum Zeitpunkt des Stopps bereits heruntergeladen werden, werden abgeschlossen. Es speichert media.json alle 100 Dateien, sodass ein abgebrochener Lauf nahe seiner Position fortgesetzt werden kann.
fingerprint wiederholt nicht: Eine blockierte Startseite oder eine Bot-Herausforderung führt zu Exit 3. assets und shoot gehen zurück und stoppen nach 3 blockierten Antworten hintereinander.

Die Befehlssequenz

Führen Sie es aus dem Ordner aus, der capture/ enthalten wird (dem Stammverzeichnis des Site-Repositorys). <skill-dir> ist der absolute Pfad des Ordners dieses Skills in einer Kopie des Kits, in der npm install ausgeführt wurde (die Skripte importieren dessen Pakete). Jedes Skript druckt --help; führen Sie es aus, anstatt den Quelltext zu lesen. Führen Sie jeden Schritt als eigenen Befehl in dieser Reihenfolge aus:

Fingerabdruck, dann lesen Sie die Plattformreferenz für das, was es benennt (Tabelle unten):
```
node <skill-dir>/scripts/fingerprint.mjs https://www.example.com
```
Erfassung. Die Erkennung erfolgt über die Sitemaps (jede Sitemap:-Zeile in robots.txt, plus den Standardindex der Plattform), die REST-Listen (WordPress, wenn der Fingerabdruck REST findet; --no-rest überspringt), den Link-Crawl und --seed <path> oder --seed-file <datei> (ein Pfad oder eine URL pro Zeile, #-Kommentare) für Pfade, die der Crawl nicht erreichen kann (alte URLs, eine alte .htaccess). Nach dem Crawl werden nicht gefundene Wayback-Pfade in wayback-unverified.txt abgelegt (--no-wayback überspringt; bei fehlgeschlagener Auflistung wird 10 s später erneut gefragt, bevor meta.json wayback den Status failed aufzeichnet). ?p=-Shortlinks werden unverifiziert aufgezeichnet und niemals abgerufen, es sei denn, Sie übergeben --verify-shortlinks. Nach dem Crawl fordert er einmal einen Pfad an, der nicht existieren kann (/<32 hex>/), sodass die eigene 404-Seite der Site als pages/404.html gespeichert wird (meta.json notFound; eine Site, die dort mit 200 antwortet oder weiterleitet, wird ohne Seite aufgezeichnet), und fragt einmal nach /favicon.ico und /apple-touch-icon.png, Redirects werden gefolgt (meta.json icons: Pfad zu { status, file, contentType, bytes }); eine, die mit 200 antwortet, wird Byte für Byte als assets/root-favicon.ico oder assets/root-apple-touch-icon.png gespeichert (eine HTML-Antwort wird nicht gespeichert und hat einen note; eine über 5 MB hat den Status "too-large"), und assets.mjs listet sie in assets/index.json als Typ "root-icon" mit ihrem path auf, sodass der Build sie dorthin versendet. URLs werden mit Großbuchstaben-Prozent-Codierung referenziert (%c3%a9 und %C3%A9 sind eine URL), sodass eine Seite, die mit beiden Schreibweisen verlinkt ist, einmal erfasst wird. Eine von robots.txt benannte Sitemap, die mit 404 (oder einem anderen Nicht-200) antwortet, wird in sitemaps/index.json mit ihrem Status und in meta.json discoveryErrors aufgeführt. Eine Sitemap auf einem anderen Host (robots.txt benennt eine einer Schwester-Site, oder ein Index listet eine auf; www und Root zählen als ein Host) wird dort als { url, host, skipped: "other host" } aufgeführt und niemals abgerufen, sodass keine ihrer URLs in den Crawl gelangt. Zwei Sitemap-URLs mit demselben Dateinamen überschreiben sich nie: Die zweite wird mit einem Suffix aus ihrem Verzeichnispfad gespeichert (page-sitemap-es.xml). --exclude <präfix>[,<präfix>...] lässt Teile des Hosts aus (die Sub-Sites eines WordPress-Multisite wie /president/ oder ein vom Eigentümer gepflegter Abschnitt): Eine URL, deren Pfad mit einem davon beginnt, wird nie angefordert, egal ob eine Sitemap, die REST-Listen, ein Link oder ein Redirect dorthin führt. Eine Sitemap unter einem solchen Präfix wird in sitemaps/index.json als { url, skipped: "excluded" } aufgeführt; ein Redirect in einen solchen Bereich wird mit diesem Ziel aufgezeichnet, ohne angefordert zu werden; Links zu einem solchen Bereich bleiben im gespeicherten HTML und werden in links.json als excluded, nicht internal aufgeführt; meta.json excluded nennt die Präfixe und die Basislinie führt sie mit. Präfixe und Pfade werden in einer Form verglichen, sodass /présidence/, /pr%c3%a9sidence/ und /pr%C3%A9sidence/ das gleiche Präfix sind. Ein Stylesheet oder Root-Icon, das unter ein solches Präfix weiterleitet, wird dort nicht verfolgt (das Blatt wird mit Status "excluded" aufgeführt). --resume behält sie bei; ein bei --resume hinzugefügtes Präfix entfernt, was bereits darunter erfasst wurde (seine Seiten mit ihren pages/- und text/-Dateien, Redirects davon, Feeds und Sitemaps darunter sowie Stylesheets und Skripte, die nur diese Seiten verwendet haben) und gibt aus, was entfernt wurde. media.mjs und assets.mjs überspringen ebenfalls Dateien darunter.
```
node <skill-dir>/scripts/capture.mjs https://www.example.com --out capture
```
Dann der zweite Wayback-Durchlauf, wenn wayback-unverified.txt nicht leer ist: Jeder archivierte Pfad wird einmal angefordert, sodass diejenigen, die noch weiterleiten, in capture/redirects.json mit der Quelle seed landen (die Basislinie nimmt sie auf) und die restlichen mit ihrem Status in inventory.json aufgezeichnet werden. --seed, --seed-file und --include-query gelten alle für --resume, und die Wayback Machine wird nicht erneut gefragt:
```
node <skill-dir>/scripts/capture.mjs https://www.example.com --out capture --resume --seed-file capture/wayback-unverified.txt
```
Medien. Listet jede Mediendatei in capture/media.json auf und speichert sie unter .conversion/media-cache/, dem Arbeitsverzeichnis der Konvertierung, das außerhalb von Git bleibt:
```
node <skill-dir>/scripts/media.mjs --capture capture --download .conversion/media-cache
```
Es lädt sechs Dateien gleichzeitig herunter. Standardmäßig (--sizes referenced) werden die Originale und jede von der Site verwendete Größe abgerufen: eine, auf die eine Seite, ein Stylesheet, ein srcset, ein og-Tag oder eine Sitemap verweist, oder deren Dateiname irgendwo in den erfassten Seiten, Stylesheets oder Skripten vorkommt (data-thumb, data-bg, JSON-Einstellungen, Slider-Skripte). Eine WordPress-Größe, die nur die REST-Medienliste nennt, wird als downloaded: false, reason: "unreferenced size" aufgeführt und nicht angefordert. Es gibt die Aufteilung aus, z.B. 920 originals + referenced sizes (downloaded), 4,520 unreferenced sizes (listed only): wiederholen Sie diese Zeile gegenüber der Person. Verwenden Sie --sizes all, wenn der Eigentümer sagt, dass alte E-Mails oder andere Sites auf diese Größen verlinken könnten.

Hosts, die per Query-String skalieren (WordPress VIP, Jetpack Photon: photo.jpg?w=1024, ?resize=300,200) liefern jede Größe unter dem gleichen Pfad aus. Das Original ist der bloße Pfad, daher wird dieser angefordert und gespeichert; jeder gesehene Query-String wird unter variants aufgeführt (nicht angefordert; --sizes all speichert sie als <path>%3F<query> in einem Geschwisterordner, .conversion/media-cache-variants/, sodass der Medien-Cache, der hochgeladen oder in das Repo kopiert wird, nur bloße Pfade enthält). Wenn der bloße Pfad mit einem Fehler antwortet (4xx oder 5xx; ein Redirect wird mit seinem Ziel aufgezeichnet, und eine zu große Datei wird erneut angefordert, sobald die Grenze erhöht wurde), wird eine Variante an seiner Stelle gespeichert und der downloadedFrom-Eintrag ist die URL, von der sie stammt. Ein Cache-Busting-Query (kein w-, h-, resize-, crop-, fit-, quality-, format- oder s-Parameter, z.B. ?ver=3) ist dieselbe Datei, daher wird sie bevorzugt und nichts anderes markiert; andernfalls wird die breiteste Variante gespeichert und der Eintrag enthält auch resized: true. Der Lauf gibt eine Zeile pro Datei und eine Anzahl aus (2 originals unavailable (resized: true) ...), baseline/media.json behält beide Felder, und das Medien-Gate wiederholt die Anzahl als N resized (original unavailable on live), ohne zu scheitern, da es mit den tatsächlich gespeicherten Bytes vergleicht. Wiederholen Sie diese Anzahl gegenüber der Person und listen Sie diese Dateien im Plan und Runbook als Originale auf, die die Live-Site nicht mehr ausliefert.
Vorlagen. Gruppiert die Seiten, die mit 200 geantwortet haben, in capture/templates.json. Bei WordPress gruppieren Seiten zuerst nach der Vorlagen-Body-Klasse (home, page, single-post, archive, Vorlagenklassen), und eine Seite, deren Markup sich deutlich unterscheidet (Jaccard unter 0,5), wird als page-2 abgespalten; andere Plattformen führen bei Jaccard 0,6 als template-<n> zusammen:
```
node <skill-dir>/scripts/templates.mjs --capture capture
```
Assets. Logo, Favicon, Apple-Touch-Icon, das <link rel=manifest> Web-Manifest und jede @font-face-Schriftart in capture/assets/, plus das Root /favicon.ico und /apple-touch-icon.png (root-favicon.*, root-apple-touch-icon.*), wenn meta.json icons sie mit 200 aufgezeichnet hat:
```
node <skill-dir>/scripts/assets.mjs --capture capture
```
Das Logo wird zuerst auf der Startseite im <header> gesucht, dann in jedem anderen Element, dessen Klasse oder ID ein Logo benennt (.logo, .site-logo, #logo-wrap). In jedem: ein <img>, dessen src, alt, class oder id das Wort "logo" enthält (nicht "logout"), dann ein Inline-<svg> mit "logo" in seiner class, id, aria-label oder <title> (gespeichert als logo.svg, url: null in assets/index.json; sein Hinweis sagt dies, wenn es nur ein <use>-Symbol verwendet, das woanders auf der Seite definiert ist, was allein leer erscheint), dann das erste <img> in einem Link zur Homepage, dann das erste <img>. Überprüfen Sie assets/logo.* visuell: Ein Konto-Avatar oder ein Sponsoren-Zeichen kann bei einem ungewöhnlichen Header dennoch gewinnen. Favicon und Apple-Touch-Icon werden so gespeichert, wie sie von ihrem <link>-href ausgeliefert werden, einschließlich Query-String, sodass eines, das auf eine Größenänderung (?w=32, ?w=180) einer Upload-Datei verweist, sich in Bytes von diesem Eintrag in media.json unterscheidet: Behalten Sie das gespeicherte Icon, nicht das Original.

Live-Screenshots, eine pro Vorlage bei 390, 768 und 1440, mit dem Shooter für die visuelle Überprüfung:

node <skill-dir>/../visual-review/scripts/shoot.mjs --base https://www.example.com --routes capture/templates.json --widths 390,768,1440 --out capture/screens/live

Lighthouse (optional). Nur wenn npx --no-install lighthouse --version antwortet; installieren Sie es niemals ungefragt; wenn es fehlt, erwähnen Sie dies in den Notizen (ein Übersprung, kein Bestehen). Führen Sie mkdir -p capture/lighthouse-live aus, dann einen Lauf pro representative in templates.json, nacheinander:
```
npx --no-install lighthouse https://www.example.com/ --quiet --chrome-flags="--headless=new" --output json --output html --output-path capture/lighthouse-live/home
```
README. Fasst die Erfassung in capture/README.md zusammen; sein ## Notes öffnet mit generierten Zeilen, die bei jedem Lauf neu geschrieben werden (wie viele Wayback-Pfade der zweite Durchlauf verifiziert hat und was jede geantwortet hat: Status, Redirect-Ziel; eine Wayback-Liste, die fehlgeschlagen ist oder aufgrund der Größe abgelehnt wurde; jede URL, die nach ihren Wiederholungen immer noch fehlschlägt). Führen Sie es zuletzt und nach jedem erneuten Lauf aus:
```
node <skill-dir>/scripts/readme.mjs --capture capture
```

Skript	Exit
`fingerprint`	0 erledigt, 2 Verwendung oder nicht erreichbar, 3 Blockierung oder Bot-Herausforderung
`capture`	0 erledigt, 2 Verwendung, 3 gestoppt wegen Blockierung, nicht erreichbar, Bot-Herausforderung (alle fortsetzbar) oder keine Seite mit 200 geantwortet
`media`	0 erledigt (fehlende Dateien eingeschlossen), 2 Verwendung, keine Erfassung oder keine Seite mit 200 geantwortet, 3 gestoppt wegen Blockierung
`assets`	0 erledigt (fehlende Dateien eingeschlossen), 2 Verwendung oder keine Erfassung, 3 gestoppt wegen Blockierung
`templates`	0 erledigt, 2 Verwendung, keine `inventory.json` oder "keine erfassten Seiten" (keine mit 200 geantwortet)
`readme`	0 erledigt, 2 Verwendung oder keine `inventory.json`
`shoot`	0 alle geschossen, 1 eine Route fehlgeschlagen, 2 Verwendung, 3 gestoppt wegen Blockierung

Bei Exit 3

Die Site blockiert Anfragen oder ist nicht erreichbar. Warten Sie (Minuten, nicht Sekunden), dann:

fingerprint: Führen Sie es erneut aus.
capture: Führen Sie denselben Befehl mit --resume aus. Die noch in der Warteschlange befindlichen URLs werden erneut versucht.

ethanplusai/astro-conversion-kit

Was ist astro-conversion-kit?

In Ihrer bevorzugten KI fragen