Severity table
어떤 스크립트도 당신에게 링크가 독성이라고 단정 지을 수 없습니다. 신규 참조 도메인이 무엇인지, 누락된 도메인은 무엇인지, 그리고 수동으로 검토할 만큼 이상해 보이는 도메인을 알려줄 뿐입니다.
| Level | Signal | Action |
|---|---|---|
| Ignore | 신규 도메인, DR 30 이상, 앵커가 브랜드명 또는 일반 URL임 | Log it, move on |
| Look | 1주일 동안 50개 이상의 신규 도메인이 타겟팅하지 않은 단일 TLD에서 발생 | Open ten of them |
| Look hard | 20개 이상의 신규 도메인에서 동일한 정확 일치 앵커 사용 | Check the anchor cloud, find the source |
| Act | 유료 네트워크 또는 해킹된 페이지에서 당신을 가리킴 | 문서화; 수동 조치가 있는 경우에만 disavow 파일 고려 |
| Wait | 한 달 동안 도메인이 사라짐 | 다음 월간 업데이트 후 다시 확인 |
단일 스냅샷은 현재 상태를 보여줍니다. diff는 변경 사항을 알려주며, 문제가 발생하는 곳이 바로 그 부분입니다.
구글은 2016년 9월 펭귄 4.0 출시 이후로, 그리고 2022년 12월 링크 스팸 업데이트에서도 스팸 링크를 처벌하기보다 무시한다고 여러 해 동안 언급해 왔습니다. 스팸브레인( SpamBrain)이 그 작업을 수행합니다. 따라서 잡음의 홍수는 위협보다는 소음인 경우가 많으며, diff는 주로 소음에 반응하는 것을 방지하는 데 도움이 됩니다.
Keep your own history. Suites overwrite theirs.
diff는 모든 실행이 동일한 테이블에 동일한 형태로 저장될 때만 작동합니다. 이 단계들은 그 상태를 유지하게 합니다.
필요한 열(날짜, 도메인, 점수)로 create-if-not-exists 문을 실행합니다. 스크립트에 유지하여 새 머신에서도 수동 단계 없이 동일한 테이블을 다시 빌드할 수 있게 합니다.
파라미터화된 삽입을 사용하고 실행당 한 번 커밋합니다. 단일 커밋은 크래시로 인해 파일의 절반만 남는 것을 방지합니다.
삽입하기 전에 해당 날짜의 행을 삭제하거나, 날짜와 도메인에 고유 키를 추가합니다. 같은 날짜에 다시 실행하면 행이 두 배로 늘어나는 대신 대체됩니다.
max(day) 필터를 사용하여 가장 최근 이전 날짜를 선택하세요. 어제 날짜가 아닌 것입니다. 이렇게 하면 1주가 건너뛰어진 경우에도 비교가 정확하게 유지됩니다.
두 개의 테이블이 더 깔끔할 것입니다. 하지만 취미용 설정에는 충분합니다: 스냅샷 날짜별 도메인당 행.
import json, sqlite3, sys, datetime
db = sqlite3.connect('links.db')
db.execute('create table if not exists snap(day text, dom text, dr int)')
rows = json.load(open(sys.argv[1]))
day = datetime.date.today().isoformat()
db.executemany('insert into snap values (?,?,?)',
[(day, r.get('domain'), r.get('dr')) for r in rows])
db.commit()
prev = db.execute('select max(day) from snap where day < ?', (day,)).fetchone()[0]
if prev:
new = db.execute('select dom from snap where day=? except select dom from snap where day=?', (day, prev)).fetchall()
gone = db.execute('select dom from snap where day=? except select dom from snap where day=?', (prev, day)).fetchall()
print(len(new), 'new,', len(gone), 'gone')| Symptom | Likely cause | Fix |
|---|---|---|
| 하룻밤 사이에 수백 개가 'gone' | 인덱스 업데이트로 샘플이 교체됨 | Compare monthly, not daily |
| 모든 도메인이 새로 보임 | 테이블이 비었거나 day 형식이 변경됨 | Check select distinct day |
| DR 열이 모두 NULL | Row field name differs from dr | Print one raw row and adjust |
| Duplicates after a rerun | Same day inserted twice | Delete that day first, or add a unique key |
Count below total | Pagination stopped early | Fix the loop in the Actions runbook |
블로그 포스트에서 복사한 임계값은 타사 사이트에 대한 추측일 뿐입니다. Bad backlinks checker는 그 제한 사항만큼만 유용하며, 당신의 자체 역사는 도메인별 정상적인 패턴이 무엇인지 알려줍니다.
먼저 몇 달 동안 아무 조치 없이 로깅하세요. 안정화될 때까지 기다린 후, 일반적인 주간 변동폭을 기록하세요. 그 후에야 심각도 테이블의 제한 사항을 설정합니다.
각 실행에서 신규 및 사라진 도메인 수를 기록하되 반응하지 마세요. 몇 달간의 조용한 로깅은 당신 도메인만의 범위를 제공하며, 다른 사람의 것이 아닙니다.
베이스라인이 확립되면, 단 한 주의 나쁜 데이터도 눈에 띄며, 추측 없이 차이를 설명할 수 있습니다. 이것이 베이스라인의 핵심 목적입니다.
테이블의 각 신호에는 하나의 임계값, 하나의 담당자, 하나의 조치가 있어야 합니다. 세 개의 알람이 있는 신호는 아무도 읽지 않는 신호이며, 알람들이 함께 무시됩니다.
코드에서 신호 옆에 알람을 작성하세요. 이렇게 하면 이 페이지의 테이블과 스크립트가 항상 일치합니다.
사이트가 성장함에 따라 정상적인 패턴도 커집니다. 3개월마다 제한 사항을 다시 확인하고, 변경 사항 옆에 이유를 기록하세요. 그러면 역사가 스스로를 설명할 수 있습니다.
테이블은 판단이 아닌 분류 도구입니다. 각 행은 어디를 살펴봐야 하는지 알려주며, 행동 열은 당황스러운 상태에서 disavow 파일을 찾지 않도록 도와줍니다.
상단부터 시작하세요. 대부분의 주는 Ignore 또는 Look에서 끝납니다. Look 행은 몇 분의 읽기 작업을 시작하게 하고, Look hard 행은 앵커에 대한 더 긴 검토를 시작하게 합니다. 주가 바빴다고 행을 건너뛰지 마세요. 건너뛴 행은 홍수가 unnoticed 되는 주의 시작점입니다.
플래그된 도메인 10개를 열고 페이지를 읽어보세요. 디렉토리 스크래퍼 하나로 인한 홍수와 관련 없는 블로그들의 홍수는 다른 문제이며, 오직 페이지만이 그 차이를 보여줍니다.
결정당 한 줄을 유지하세요: 도메인, 레벨, 확인 항목 및 수행한 작업. 다음 로그를 읽는 사람(미래의 당신 포함)은 회의 없이도 추론 과정을 알 수 있습니다.
A monthly summary of those lines takes little time, and it makes a good first draft of a review.
It cannot prove a link hurts you. Nobody outside Google can, and Search Console's manual actions report is the only place a penalty is stated.
It also cannot see links younger than the last refresh. For fresher evidence ask the people who run the linking site, or read your server logs for the referrers. Our note on timing goes deeper.
If you want the anchors side, anchor_cloud costs 2 credits and groups text by frequency, which is the quickest way to spot an exact-match pile-up.
Anything younger than the last refresh is missing from both sides of the diff. A link that appears and disappears inside one refresh window never shows at all, which is why the comparison should run monthly.
A diff sees the domain, not the sentence around the link. Two identical anchors on two different pages can mean very different things, so keep the anchor check as a separate, manual step.
SQLite는 단일 쿼리로 diff 질문을 답변할 수 있는 가장 간단한 데이터베이스입니다. 단일 파일로 존재하므로 서버 없이도 리포지토리나 백업 폴더에 적합합니다.
Dated JSON files work too. It is slower to query, but easier to open in a text editor when something looks wrong. Either way, copy the store to a second place before any cleanup, and keep the copy for a full quarter before you delete anything.
One table with a day column covers a single site for years. The file stays small, and the queries on this page need no tuning.
Once several people write to the same history, a file on one machine becomes the bottleneck. At that point a managed database is the honest choice, and the schema stays the same.
Until then, a file in the repo is the simplest thing that survives a laptop change.
Run diff.py right after the snapshot step. Print the counts, and exit with a non-zero code when new crosses a limit you picked, say 200 in a week for a small site. The job turns red, and GitHub emails you. Simple.
Pick the limit from your own history. After two months you know whether 15 new domains a week is normal or a spike, and any fixed number copied from a blog post is a guess.
Quiet weeks are the norm.
