audit — 분기별 크롤링
analysis는 저장소를 보고, audit는 방문자와 크롤러가 보는 것을 봅니다: 라이브 HTML, 실제 상태 코드, 리디렉션, 제공되는 사이트맵. 발견된 모든 것은 fix 스킬이 기계적으로 실행할 수 있는 백로그 항목이 되거나, 어떤 스킬도 건드려서는 안 되는 항목(탐색, 레이아웃, 가격 및 법적 페이지, 호스팅)에 대한 소유자 목록의 한 줄이 됩니다. 아티클을 편집하거나 PR을 열지 않습니다.
스크립트: ${CLAUDE_PLUGIN_ROOT}/scripts/{crawl,inventory,sitecheck}.js. P=${CLAUDE_PLUGIN_ROOT}를 설정하세요.
인자: --origin <url> (기본값: seo/brand.json의 https://<domain>, 또는 Preview 줄의 호스트), --max <n> 페이지 (500), --external <n> 확인할 외부 링크 수 (200), --cwv (홈페이지 및 클러스터 허브에 대해 PageSpeed Insights 요청, googleapis.com에 대한 네트워크 필요, PAGESPEED_API_KEY 선택 사항), --no-items (보고서만 생성, 백로그에 아무것도 쓰지 않음), --dry-run (크롤링 및 보고, 커밋하지 않음).
0. 전제 조건
제품 저장소 루트; git status --porcelain 비어 있음; 기본 브랜치에 있음; seo/strategy.md 및 ## SEO agent 블록이 존재함. 먼저 node $P/scripts/inventory.js --root .를 실행하여 크롤링이 경로를 파일 및 종류에 매핑할 수 있도록 합니다. gh는 필요하지 않습니다.
1. 크롤링
PREV=$(ls seo/data/crawl/*.json 2>/dev/null | sort | tail -1)
node $P/scripts/crawl.js --root . --origin <origin> --max <n> --external <n> [--cwv] --save seo/data/crawl ${PREV:+--diff $PREV} --quiet
JSON을 읽습니다: summary (페이지, 코드별 발견사항, truncated), findings[] (code, severity fix|report, path, file, msg, to), sitemap (count, error, missing), external[], cwv[], diff (new, resolved 이전 감사 이후). 최상위 또는 sitemap.error에 error 키가 있으면 → 이를 말하고 중단합니다; 다운된 사이트는 백로그 항목이 아닌 소유자의 문제입니다. truncated: true → 크롤링이 --max에 도달했으며 어떤 경로가 여전히 대기 중인지 말합니다.
그런 다음 node $P/scripts/sitecheck.js --root .도 실행합니다: 라이브 HTML이 숨기는 소스(Blade 인자, 라우트, 프레임)를 보며, 둘을 합친 것이 전체 그림입니다.
2. 분류
세 개의 버킷, 다음 순서로:
fix항목 — 인벤토리 항목에 guide, article 또는 tool 종류의file이 있는 페이지에서severity: fix(코드title,description,canonical,alt,link,sitemap)인 발견사항. 페이지당 하나의 항목,analysis§1c가 작성하는 방식과 정확히 동일하지만 두 가지 차이점이 있습니다:- evidence: audit <date>: <n> findings및 모든fixes:줄이(audit <date>)로 끝나므로fix가 sitecheck 대신 라이브 사이트에 대해 확인해야 함을 알 수 있습니다:
이미 열려있거나(open) 클레임되었거나(claimed) 검토 중(in-review)인### [B-nnn] fix: <path> - type: fix - target: <path> - score: <n> (potential <p> × ease 10 × fit <f>) ← potential 3, 또는 최신 seo/data/gsc 스냅샷의 페이지 gsc_potential; fit은 클러스터 우선순위에서 가져옴 - evidence: audit <date>: <n> findings - status: open - fixes: link: internal link /old-path redirects to /new-path: link the final URL (audit <date>) description: no meta description (audit <date>)fix항목이 있는 페이지 → 새fixes:줄을 해당 항목에 추가합니다(이미 코드 +to로 존재하는 줄은 건너뜁니다). 열린refresh항목이 소유한 페이지 →owned by B-nnn, fix 항목 없음. sitecheck도 보고하는 발견사항(동일 페이지, 동일 코드)은 audit에서 한 번만 나열되며(audit <date>)태그가 붙습니다.link항목 — 아티클 페이지의orphan발견사항: 클러스터당 하나의link항목 ($P/skills/analysis/SKILL.md§1c 형식,- links:줄/hub → /orphan (orphan, audit <date>)); 열린link항목이 있는 클러스터는 쌍이 추가됩니다. 클러스터가 없는 고아(일치하는 허브 없음)는 소유자 목록으로 이동합니다.- 소유자 목록 — 그 외 모든 것:
broken-external,redirect-chain,duplicate-title/duplicate-description,noindex-in-sitemap,sitemap-404,thin,h1,mixed-content,slow,server-error, 비아티클 페이지(홈, 가격, 법적, 레이아웃)의 모든 발견사항,sitemap.missing, CWV 행. 코드별로 그룹화, 가장 심각한 것부터, 코드당 최대 3개의 예시 경로; 인벤토리가 알고 있을 때 파일 이름을 지정합니다. 아티클의thin은 fix가 아닌 새로고침(refresh) 신호입니다: 그렇게 말하고analysis에 맡깁니다.
--no-items → 버킷 3만, 있었을 항목의 개수와 함께.
3. 커밋
--dry-run이 아닌 경우: git add seo/data/crawl/<date>.json seo/backlog.md하고 기본 브랜치에 seo: audit <date> — <pages> pages, <findings> findings, <k> fix items, <m> link items로 커밋합니다(계획 파일은 직접 커밋); 브랜치에 업스트림이 있으면 푸시합니다. PR은 없습니다.
4. 보고서 (≤ 15줄)
audit <date>: <pages> pages crawled (<html> html, <truncated?>), <findings> findings (<fixable> fixable); 사이트맵<count>URL,<missing>누락 또는 실패- 코드별 발견사항, 한 줄, 개수
<previous>대비 차이:<new>새 항목,<resolved>해결됨 (5개 이하이면 새 항목 이름 지정)- 항목: 경로가 포함된
fixID; 클러스터가 포함된linkID;owned by/already open메모 - 소유자 목록: ≤ 8줄, 가장 심각한 것부터 (긴 설명보다 탐색의 5xx 또는 리디렉션 체인이 먼저)
--cwv인 경우 CWV 표: 경로, LCP, CLS, INP, perf, 소스- 다음 단계:
fix는 금요일에 항목을 실행합니다 (또는 지금/seo-agent:fix); 다음 감사는 3개월 후입니다
엄격한 규칙
- 사이트에 대해 읽기 전용:
seo-agent-audit사용자 에이전트로 GET/HEAD, 하나의 오리진,--max페이지, 요청 간--delay; 절대 양식을 제출하거나, 로그인하거나, 다른 호스트를 크롤링하지 않음 - 아티클, 레이아웃 또는 사이트맵을 절대 편집하지 않음; PR을 절대 열지 않음;
seo/data/crawl/및seo/backlog.md에만 기록 - 백로그 항목은
fix스킬이 편집할 수 있는 아티클 페이지에 대해서만; 그 외 모든 것은 소유자의 몫 - 결정론적: 발견사항은
crawl.js에서 비롯됨; HTML을 눈으로 읽어 발견사항이 추가되지 않음 thin은 절대 fix 항목이 아님