런북
게시물은 라이브 상태이지만 파이프라인이 아직 완료되지 않았습니다. 이 런북은 사이트별 링크 데이터를 기록하고 문제가 있을 때만 사람에게 알려주는 스케줄된 감사를 추가합니다.
SEOBlogBot 연구팀 ·
게이트는 초안만 확인합니다. 감사는 라이브 사이트가 실제로 어떻게 작동하는지 확인합니다. 플러그인은 링크를 다시 작성하고, 편집자는 깔끔한 URL 위에 제휴사 리디렉트를 붙여넣으며, CDN 마이그레이션은 하나의 호스트를 다른 호스트로 바꿀 수 있습니다. 이러한 변화는 초안 단계에는 존재하지 않으므로, 게시 후 실행은 이러한 문제가 처음 나타날 수 있는 지점입니다.
유용한 감사는 본질적으로 지루합니다. 정기적으로 실행되고 한 줄만 기록하며 예외가 발생하지 않는 한 조용합니다. 조용함이 목표입니다. 한 달 동안 조용한 로그는 작업이 유휴 상태인 것이 아니라 제대로 작동하고 있음을 의미합니다.
일반적으로 사용할 수 있는 공식 Google 백링크 체커 API는 없으므로 팀은 서드파티 링크 인덱스를 호출합니다. 이는 자체 크롤러입니다. Search Console은 자체 링크에 대한 Google의 시각을 보여주며, 감사는 이를 대체하기보다 보완합니다.
트리거를 기록하세요. 대부분의 팀을 위한 세 가지 설정이 있으며, 각각 동일한 호출을 실행합니다. 트리거보다 로그가 중요한 이유는 날짜, URL 및 사용된 크레딧이 매번 기록되어야 하기 때문입니다.
사이트가 저장소에서 빌드되는 경우, 스케줄된 워크플로우는 최소한의 마찰을 추가합니다. 작업은 코드 옆에 위치하며, 키는 저장소의 비밀 저장소에 있습니다. 하단의 워크플로우 파일은 필요한 최소한의 내용입니다. 다른 코드처럼 검토하여 저장소에 보관하고, 의존하는 액션 버전을 고정하세요.
빌드용 머신을 이미 관리하는 팀은 동일한 명령을 해당 머신에 스케줄할 수 있습니다. n8n과 같은 도구를 사용하여 Execute Command 단계로 실행하거나, crontab 줄을 통해 직접 실행할 수 있습니다. 어쨌든 작업은 키를 읽고 다른 것은 읽지 않는 사용자 권한으로 실행되어야 합니다.
일부 CMS 설정은 게시물이 라이브로 전환될 때 웹훅을 발생시키며, 이 이벤트로 감사를 시작할 수 있습니다. 그러면 게시물이 공개되는 즉시 검사가 실행됩니다. 단일 웹훅 누락으로 게시물이 검사되지 않을 수 있으므로 정기 실행도 유지하세요.
게시물이 라이브로 전환된 직후의 한 번의 실행은 아웃바운드 호스트를 확인합니다. 한 달 후의 두 번째 실행은 인덱스가 대략 월별로 새로고침되므로 이전 읽기에서는 새로운 것이 표시되지 않을 수 있으므로 사이트의 refdomains를 읽습니다.
action=overview는 비용 없이 사이트의 주요 숫자를 반환합니다. 날짜와 함께 이 실행의 기준선 행으로 저장하세요.
개요가 지난달과 다른 경우 refdomains(2 크레딧) 및 anchors(2 크레딧)를 호출하고 저장된 목록과 비교하세요.
날짜, 게시물 URL, 호출 횟수, _credits 잔액. 비공개 저장소에 커밋된 일반 CSV면 충분합니다.
HTTP 401, HTTP 402, 지난달에 행이 있던 사이트에 대한 빈 결과, 또는 10점 이상의 평점 하락.
게스트 호스트인 도메인으로 시작하세요. 그런 다음 벤치마킹하려는 두세 개의 피어 사이트에 동일한 감사를 실행하세요. 이를 위해 compare를 사용하세요. 최대 20개 도메인을 1 크레딧로 처리하므로 피어 체크 비용은 거의 들지 않습니다.
긴 꼬리 데이터는 건너뛰세요. 추가되는 모든 사이트는 사람이 읽어야 하는 로그에 노이즈를 추가합니다. 20개의 관련 없는 도메인을 벤치마킹해도 자체 사이트에 대해 매우 적은 정보만 알려줍니다.
스케줄된 작업은 매 실행 시 키를 읽으므로 로그인 단계가 필요 없습니다. 보호해야 할 것은 키 자체뿐입니다. 키는 세 가지 명확한 누출 경로가 있습니다: 커밋, 인쇄된 환경 변수, 프록시가 기록하는 URL. 각각을 차단하세요.
키를 CI 제공업체의 비밀 저장소나 작업 사용자만 읽을 수 있는 환경 파일에 붙여넣으세요. 절대 커밋하지 마세요. 환경 변수를 출력하는 단계가 있으면 키가 인쇄되므로 해당 단계를 작성하지 마세요.
Bearer 헤더는 URL이 기록되는 반면 헤더는 일반적으로 기록되지 않으므로 키를 대부분의 액세스 로그에서 제외합니다. 쿼리 문자열 형태도 작동하지만 요청을 보는 모든 프록시에 복사본을 남깁니다.
작업을 유지하는 사람들에게만 읽기 권한을 부여하고 다른 사람에게는 부여하지 마세요. 작업이 인계될 때 해당 목록을 검토하세요.
많은 사람이 읽을 수 있는 키는 언젠가 채팅 창에 붙여넣어질 키입니다.
도달한 응답이 곧 사용 가능한 응답은 아닙니다. 항상 동일한 순서를 사용하세요. 통과한 것만 기록하고 나머지는 로그에 남기세요. 거부된 응답은 증거이며, 다음에 작업을 디버깅할 사람이 이를 보고 싶어 할 것입니다.
HTTP 상태 코드를 읽고 본문에서 ok 필드를 확인하세요. ok가 false로 설정된 200 응답도 실패한 호출이므로 로그에 그렇게 기록해야 합니다.
압축 해제, 구문 분석 또는 추가하기 전에 본문이 유효한 JSON인지 확인하세요. 불안정한 러너에서는 다운로드가 잘릴 수 있습니다. 로그에 작성된 손상된 파일은 누군가가 열기 전까지는 괜찮아 보입니다.
지난달에 행이 있던 사이트에 대한 빈 결과는 사실이 아니라 질문입니다. 누군가 알림을 받기 전에 도메인의 철자, 선행 www. 포함 여부를 확인하세요.
키를 SBB_KEY라는 이름의 저장소 비밀로 저장하세요. cron 표현식은 매월 1일 06:00 UTC에 실행됩니다.
name: monthly-link-audit
on:
schedule:
- cron: '0 6 1 * *'
workflow_dispatch: {}
jobs:
audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Overview (free)
run: |
curl -fsS "https://seoblogbot.com/api.php?action=overview&q=example.com" > overview.json
- name: Refdomains (2 credits)
env:
SBB_KEY: ${{ secrets.SBB_KEY }}
run: |
curl -fsS -H "Authorization: Bearer $SBB_KEY" \
"https://seoblogbot.com/api.php?action=refdomains&q=example.com&per=500" > refdomains.json
- name: Log credits
run: jq -r '._credits' refdomains.json >> credits.log| 증상 | 가능한 원인 | 첫 번째 조치 |
|---|---|---|
| HTTP 401 | 비밀 키 누락 또는 갱신됨 | 비밀 키 다시 생성, workflow_dispatch 실행 |
| HTTP 402 | 크레딧 고갈 | 계정 페이지에서 충전, 다시 실행 |
| 알려진 사이트에 대한 빈 행 | 인덱스 새로고침 진행 중 또는 도메인 오타 | 하루 후 재시도; www. 확인 |
| 평점 소폭 변동 | 월간 새로고침 | 무시; 추세 확인 |
| 평점 10점 이상 하락 | 링크 손실 또는 큰 새로고침 변화 | refdomains 가져오기 및 비교 |
crontab 줄에서 동일한 명령 실행. 키를 작업 사용자만 읽을 수 있는 환경 파일에 보관하고, 회전되는 파일에 로그를 기록하세요.
두 목록을 모두 가져올 경우 한 사이트의 월간 감사 비용은 4 크레딧으로 $0.0004입니다. 개요 호출은 무료입니다. 따라서 변경이 없는 달에는 추가 비용이 들지 않습니다.
팀이 여러 사이트에서 하루에 열 개의 게시물을 발행하는 경우, 감사는 게시물당 하나가 아닌 사이트당 월간 작업입니다. 이렇게 하면 수가 작게 유지되고 로그가 읽기 쉬워집니다.
두 번째 사이트를 추가할 때는 작업을 확장하기보다 복사하세요. 도메인당 하나의 워크플로우는 사이트별 로그를 유지하고 실패를 소유자에게 쉽게 추적할 수 있게 합니다.
더 큰 비용은 일반적으로 크레딧이 아닌 CI 제공업체의 분 단위 사용량입니다. 비용 표는 두 항목을 나란히 제시하므로 먼저 조정할 항목을 결정할 수 있습니다.
첫 번째 실행에서 _credits를 출력하도록 요청하세요. 표보다 응답을 신뢰하세요. 게이트 가이드는 이 전에 오는 초안 측 검사를 다룹니다.
GitHub 스케줄은 UTC로 실행되므로 06:00 시작은 각 팀마다 다른 현지 시간에 해당합니다. 로그에서 놀라지 않도록 시간대를 런북에 기록하세요.
이 질문의 대부분은 방금 작업을 처음 스케줄한 팀에서 나옵니다.
이는 Google 제품이 아닌 자체 API를 기반으로 구축된 감사입니다. Google은 일반 백링크 API를 제공하지 않으므로 숫자는 자체 크롤러와 자체 인덱스에서 가져옵니다.
가능하지만 월별 refdomains 가져오기는 모든 빌드에서 실행될 필요가 없습니다. 각 게시 시 무료 개요를 실행하고 유료 가져오기는 월 한 번 실행하세요.
예, 플러그인이나 CDN을 통해 발행하는 경우. 게이트는 초안을 확인하고 감사는 라이브 페이지를 확인합니다. 각각 다른 쪽이 볼 수 없는 실패를 포착합니다.
각 단계의 결과를 자체 파일에 기록하여 실패한 가져오기가 개요를 손상시키지 않도록 하세요. 상단부터가 아닌 실패한 단계부터 다시 실행하여 동일한 가져오기에 두 번 지불하지 마세요.
두 유료 가져오기를 위해 사이트당 월 4 크레딧을 예산으로 책정하세요. 게이트가 초안에서 사용하는 크레딧도 추가하세요. 무료 개요는 이 금액에 추가되지 않으며 로그가 실제 총액을 알려줍니다.
인덱스는 대략 월 한 번 새로고침되므로 일일 변화는 대부분 노이즈입니다. 사건을 열기 전에 이번 달 스냅샷을 지난달과 비교하세요.
_credits가 기록됩니다.