용어집
링크 데이터와 발행 파이프라인에서 나오는 열두 가지 용어. 각 용어에는 JSON에서 확인할 필드명과 사람들이 흔히 저지르는 실수가 포함되어 있습니다.
SEOBlogBot 연구팀 ·
이 페이지는 이론이 아닌 용어 설명입니다. 필요한 항목으로 바로 건너뛰세요. 각 항목은 독립적으로 구성되어 있습니다.
각 항목에는 JSON에서 확인할 필드명, 간단한 의미, 그리고 사람들이 흔히 저지르는 실수가 담겨 있습니다. 시간이 부족하다면 실수 부분을 먼저 읽으세요.
용어는 파이프라인이 데이터를 처리하는 순서대로 나열됩니다: 링크 데이터, 비용, 실패 사례, 그리고 팀이 합의한 검증 항목 순입니다.
많은 사람이 리포트에서 도메인 권한(DA)을 보고 스크립트에서도 같은 수치를 얻고 싶어 검색합니다. 하지만 SEOBlogBot의 평가는 다른 지표이므로, 각 항목에서는 이 용어가 여기서 무엇을 의미하는지, 그리고 주요 도구들과 어떻게 다른지 설명합니다.
가장 많이 혼동되는 것은 수치입니다. SEO Moz 백링크 체커 리포트의 숫자조차도 마찬가지입니다. 40개의 참조 도메인에서 온 10,000개의 백링크를 가진 사이트는, 링크 그래프 관점에서 900개의 참조 도메인에서 온 2,000개의 백링크를 가진 사이트보다 훨씬 작습니다.
SEOBlogBot의 평가는 이러한 이유로 참조 도메인을 기반으로 구축되었습니다. 단순 백링크 총수를 읽는 게이트는 사이트 전체 푸터 링크 하나로 쉽게 속일 수 있습니다.
네 번째 실수는 날짜 없이 평가 수치를 읽는 것입니다. 인덱스가 갱신되는 사이에 봄과 가을에 측정한 평가는 동일한 측정치가 아닙니다.
리포트에 숫자 열이 하나뿐이어도, 복사한 모든 평가 수치에는 날짜를 명시하세요.
팀 전체와 로그에서 각 항목에 대해 하나의 명칭을 사용하세요. 그래야 검색 시 관련 모든 로그를 찾을 수 있습니다.
두 번째 함정은 '무료'라는 단어입니다. overview는 무료지만, refdomains는 2 크레딧이 필요합니다. _credits 필드가 포함된 첫 번째 응답에서 호출 유형과 비용을 확인할 수 있습니다.
평가 점수는 척도 위의 숫자이며, 이 척도에는 특정한 형태가 있습니다. 두 가지 개념이 가장 중요하며, 게이트 및 감사 가이드에서도 다시 등장하므로 여기서 정확히 이해해야 합니다.
참조 도메인 수가 20에서 30으로 증가할 때의 평가 변화는 400에서 410으로 증가할 때보다 훨씬 큽니다. 로그 스케일은 큰 수치를 압축하므로, 상단 구간은 천천히 변화합니다. 각 구간을 동일하게 취급하기보다, 이러한 형태를 고려하여 임계값을 계획하세요.
플로어는 아웃바운드 호스트에 대해 허용하는 최저 평가 점수입니다. 이는 자체 게시물을 기준으로 설정하는 로컬 규칙이며, 다른 팀은 이를 사용하지 않습니다. 설정 날짜와 함께 기록해 두세요. 그래야 나중에 검토 시 어떤 기준으로 측정했는지 알 수 있습니다.
30개의 게시물을 기준으로 설정된 플로어는 시작점에 불과합니다. 팀이 최소한 한 번의 전체 인덱스 갱신을 거칠 때까지는 규칙으로 인정되지 않습니다.
ok 필드부터 시작하세요. 모든 응답에는 이 필드가 포함되며, 인증된 응답에는 비용과 잔액을 나타내는 _credits 필드가 추가됩니다.
무엇보다 먼저 이 두 가지를 확인하세요. ok가 false인 응답에서 데이터를 읽는 파이프라인은 로그에 잡음을 무리 없이 기록할 수 있으므로, 이 확인은 코드 한 줄의 비용으로 충분합니다.
모든 실패 사례에 대해 원본 응답을 보관하세요. 필드명은 대부분의 파서에서 대소문자를 구분합니다. ok와 _credits를 정확히 일치시켜야 합니다. 월간 보고서에서 숫자가 이상해 보일 때, 저장된 응답은 API가 실제로 전송한 내용을 보여주므로 논쟁을 해결하는 가장 빠른 방법입니다.
귀하의 사이트에 링크하는 고유한 사이트로, 여러 개의 링크를 보내더라도 한 번만 카운트됩니다. refdomains 액션은 이를 나열하며, 호출당 2 크레딧이 소모됩니다.
한 페이지에서 다른 페이지로의 단일 링크입니다. 당사 인덱스에는 약 7985억 개의 링크가 있으며, backlinks 액션은 호출당 최대 1,000개의 행을 반환합니다.
링크의 클릭 가능한 텍스트입니다. anchors는 분포를 반환하며, 비자연적인 단일 구절의 집중은 주의해야 할 사항입니다.
round(100 x log(ref_domains + 1) / log(20,000,000)). 로그 스케일이므로 20에서 30으로의 증가가 60에서 70으로의 증가보다 더 큰 도약입니다.
다른 도구의 자체 공식으로 계산된 지표입니다. 당사 수치와 일치하지 않으므로 하나의 임계값에서 이들을 혼합하지 마십시오.
누가 누구에게 링크하는지를 나타내는 지도입니다. 당사 그래프에는 181,132,097개의 도메인과 2,774,625,913개의 도메인 간 링크가 있습니다.
청구 관련 용어는 모든 파이프라인 검토에서 등장하며, 각각 여기에서 특정 의미를 가집니다. 대부분의 혼란은 구독 청구서에서 단어의 의미를 그대로 적용한다고 가정하기에서 비롯됩니다.
크레딧을 사전에 구매하며, 각 유료 호출은 이를 차감합니다. 취소할 구독이나 충족해야 할 월간 최소 금액이 없습니다.
계정 페이지에서 잔액을 추가하며, TRC-20 네트워크에서 USDT로 결제합니다. 충전이 잔액을 증가시키는 방법이므로, 402 오류로 중단된 작업은 다시 실행하기 전에 충전이 필요합니다.
무료 액션은 domain, overview, stats, suggest입니다. 그 외 모든 액션은 호출당 1에서 3 크레딧을 소모하며, 응답에는 정확한 금액이 표시됩니다.
간단한 계산으로 이해해 보세요: 크레딧당 $0.0001의 가격으로, 각 호출당 1 크레딧이 소모되는 1,000회의 유료 호출은 약 10센트 정도입니다.
파이프라인은 단일 호출에서는 나타나지 않는 방식으로 실패할 수 있습니다. 이 세 가지 용어는 팀이 가장 자주 놓치는 실패 유형을 지칭합니다. 대부분의 경우 작업이 비감시 상태로 실행될 때만 나타납니다. 예약된 실행을 지켜보는 사람은 없습니다.
이러한 용어를 초기에 기록해 둔 팀은 나중에 이에 대해 논하는 데 더 적은 시간을 소비합니다.
네 가지 작업을 수행해야 하지만 세 가지만 완료된 작업은 본질적으로 실패한 것입니다. 게시물이 반만 처리되었고, 로그에는 그 사실을 알리는 정보가 없습니다. 누군가가 각 단계를 직접 확인해야만 알 수 있습니다. 해결책은 각 단계마다 결과를 남기는 것입니다. 이렇게 하면 로그에서 완료되지 않은 단계를 명확히 식별할 수 있습니다.
작업이 약속한 최종 상태입니다. 예를 들어 게시 시간이 설정된 '예약됨' 상태의 게시물이 해당됩니다. 호출의 상태 코드뿐만 아니라 작업 후 게시물의 실제 상태를 확인하세요. '상태가 예약됨인지', '게시 시간이 아직 미래인지'와 같은 예/아니오 형식의 질문으로 작성하세요.
요청은 성공했지만 행(row)이 없는 응답입니다. 이는 조용히 로그에 남길 사실이 아니라, 조사해야 할 질문입니다. 어떤 결론을 내리기 전에 지난 달의 동일한 도메인 데이터와 비교하세요.
모든 작업에 동일한 경로가 적용되므로 한 번 작성하고 각 호출에서 재사용하세요.
Bearer 헤더에 키를 포함하여 엔드포인트를 호출하고, 쿼리 문자열에 작업(action)과 도메인을 넣습니다.
401 또는 402 상태 코드가 반환되면 데이터 파싱 전에 작업이 중단됩니다.
본문이 파싱되고 ok 필드가 true인지 확인합니다. 그 후에야 데이터 필드를 읽습니다.
날짜, 작업, _credits 값 및 잔액을 저장합니다. 호출마다 한 행씩 기록하면 로그 합산이 쉬워집니다.
게시 전에 게시물을 중단할 수 있는 체크포인트입니다. 의사결정 트리를 참조하세요.
게시 후에 실행되며 차단이 아닌 보고를 수행하는 체크포인트입니다. 런북에는 실행 일정이 포함되어 있습니다.
반복해도 결과가 변경되지 않는 작업입니다. 읽기 전용 API 호출은 멱등하지만, Slack 알림은 일반적으로 멱등하지 않으므로 중복을 제거하세요.
청구 단위입니다. 크레딧 1개는 $0.0001에 해당하며, 응답의 _credits 필드에 비용과 잔액이 표시됩니다.
401은 키가 없거나 잘못되었음을 의미하며, 402는 크레딧이 고갈되었음을 의미합니다. 재시도해도 두 경우 모두 해결되지 않습니다.
당사의 데이터는 월 약 1회 업데이트됩니다. 새로운 링크가 몇 주 동안 표시되지 않을 수 있으므로, 알림은 월별 데이터를 비교해야 합니다.
팀들은 Moz DA나 Ahrefs DR 등 다른 도구의 스크린샷을 기준으로 DR 하한선을 설정한 후, 왜 좋은 게시물의 절반이 차단되는지 의아해합니다. 먼저 자체 게시물을 기준으로 보정하세요.
DR, 크레딧 등 일부 용어는 당사만의 고유 용어입니다. 용어 정의가 자체 응답 결과와 다를 경우, 응답을 우선시하세요.
동료가 Moz DA를 인용할 때, 당사 데이터와 비교하기 전에 그들이 지칭하는 지표가 무엇인지 확인하세요. 두 지표는 서로 다른 입력 데이터와 계산 공식을 사용하므로, 하나의 숫자로 다른 것을 대체할 수 없습니다.
작업의 첫 번째 버전을 작성하는 동안 이 페이지를 열어두고, 로그 라인이 자체적으로 의미를 갖게 되면 닫으세요.
팀 전체에 걸쳐 일관된 답변을 유지하기 위해 이 용어 관련 질문에 답변할 담당자를 한 명 지정하세요.
용어는 로그를 읽는 모든 사람이 동일한 방식으로 사용할 때만 도움이 됩니다. 첫 번째 실행 전에 의미를 합의하면 이 페이지의 역할이 제대로 수행됩니다.
코드 변경 전에 차이점을 기록하세요. 계정 페이지에서 계정 관련 문의를 시작할 수 있습니다.
