콘텐츠 모델에는 숫자 필드 하나, 날짜 필드 하나, 참고 사항 필드 하나가 필요합니다. 이 페이지에서는 필드 설계와 DR 공식 기반의 실제 예시를 보여줍니다.
Contentin 연구팀 ·
PageRank가 필드 옵션이 아닌 이유
아직도 백링크 체커 PageRank 도구를 찾는 사람들이 많지만, 공개된 PageRank 수치는 더 이상 존재하지 않습니다. Google은 2016년 도구 모음의 PageRank 표시를 제거했으며, 이후 Google 자체에서 이를 대체하는 공식 수치를 제공한 적이 없습니다.
남은 것은 벤더별 점수입니다. Ahrefs는 DR을, Moz는 DA를 제공하며, 당사는 자체 도메인 평점(DR)을 공개 공식과 함께 제공합니다. 하나를 선택하고 일관되게 사용하세요. 한 열에 두 가지 점수를 섞어 넣으면 이후의 모든 비교가 무의미해집니다.
헤드리스 팀을 위한 실용적인 규칙: 표시하거나 필터링할 값만 저장하고, 나머지는 저장하지 마세요. 불필요한 필드가 추가될수록 편집자가 오해할 가능성이 높아지고, 내보내기 시 열이 하나 더 늘어나며, CMS 간 마이그레이션 시 매핑 오류가 발생할 확률이 커집니다.
이름은 중요합니다. 필드를 authority가 아닌 link_dr로 명명하세요. 첫 번째 이름은 해당 점수가 누구의 것인지 명확히 나타냅니다. 두 번째 이름은 1년 후 다른 벤더의 점수로 교체하라는 유혹을 줄 수 있습니다.
소스 기준으로 필드명 지정하기
숫자를 생성한 벤더의 이름을 필드명으로 항상 사용하세요. link_dr와 같은 필드명은 숫자의 출처를 명확히 하여, 나중에 다른 벤더로 전환할 때 오류가 silently(무음으로) 발생하지 않도록 방지합니다.
라벨만 유지되고 숫자는 유지되지 않습니다. Ahrefs의 DR, Moz의 DA, 그리고 저희의 도메인 평점(Domain Rating)은 서로 다른 측정 기준이므로, 한 벤더의 값을 다른 벤더의 이름이 붙은 필드에 복사하면 다음 사용자에게 오해를 불러일으킬 수 있습니다.
두 벤더의 점수를 함께 저장할 수 있나요?
이름이 다른 두 필드에 저장할 수는 있습니다. 하지만 두 숫자는 비교를 유도하며, 그 비교 과정에서 오류가 발생하기 때문에 대부분의 팀에서는 이를 필요로 하지 않습니다.
만약 이해관계자가 두 지표를 모두 요구한다면, 두 공식의 차이점을 나란히 보여주세요. 척도가 다르게 설계되어 있으며, 그 차이로 인해 발생하는 놀라움의 대부분이 설명됩니다.
도구 간에 점수가 동일합니까?
아닙니다. 한 도구의 DR과 다른 도구의 DA는 서로 다른 링크 그래프와 다른 공식에서 비롯된 것이므로, 방향은 같더라도 숫자에서는 차이가 날 수 있습니다.
저희의 공식은 공개되어 있습니다. 로그 스케일(log scale) 때문에 참조 도메인 수가 1,000에서 100,000으로 급증해도, 점수 상승폭은 실제 증가폭보다 작게 나타납니다.
예시 계산: 가상의 도메인 5개에 대한 공식 적용
참조 도메인 수는 예시 작성을 위해 임의로 생성된 것입니다. 공식: round(100 · log(ref_domains+1) / log(2·10^7)).
가상의 도메인
참조 도메인
DR
권장 밴드
tiny-docs.example
10
14
낮음
small-saas.example
50
23
낮음
mid-blog.example
1,000
41
중간
big-publisher.example
100,000
68
높음
theoretical-top.example
20,000,000
100
높음
테이블이 필드 설계에 대해 시사하는 바
스케일은 로그 스케일입니다. 10개 도메인과 1,000개 도메인은 27점 차이이며, 1,000개와 100,000개는 다시 같은 거리만큼 차이가 납니다. 따라서 정수를 저장하되 밴드로 읽으세요.
밴드 필드는 종종 원시 숫자보다 편집자에게 더 큰 도움이 됩니다. 41과 43의 차이를 보고 행동할 사람은 없습니다. 하지만 '중간'이라는 라벨은 명확한 행동 지침이 됩니다. 간결하게 유지하세요.
날짜는 점수와 마찬가지로 중요합니다. 날짜가 없는 점수는 실시간 측정치처럼 보이며, 1년 후 누군가가 회의에서 그것을 사실처럼 인용할 것입니다. 날짜를 명시하고, 비용 테이블의 야간 bulk_dr 스윕처럼 이름 지을 수 있는 주기적으로 업데이트하세요.
노트 필드는 그 역할이 작으므로 간결하게 유지해야 합니다. 한 문장이면 충분합니다. 이 필드의 역할은 색인이 월별로 변동하며 Google Search Console이 Google의 자체 관점을 반영한다는 사실을 독자에게 상기시키는 것입니다.
시간이 지나도 필드의 정확성 유지하기
한 번 기록하고 다시 검토하지 않는 필드는 조용히 과거의 사실이 됩니다. 업데이트 작업이 이를 측정치로 유지하며, 이 작업은 한 문장으로 설명할 수 있는 일정에 따라 실행되어야 합니다.
일정으로 시작하세요. 일정이 나머지 모든 것을 결정하기 때문입니다. 월간 업데이트는 색인의 리듬과 일치하며, 야간 실행은 정보 추가 없이 비용만 증가시킵니다. 색인은 월 약 1회 변동하기 때문입니다.
점수는 얼마나 자주 업데이트해야 하나요?
대부분의 경우 월간으로 업데이트하세요. 색인이 따르는 리듬과 일치하기 때문입니다. 숫자가 변하지 않았더라도 모든 항목에 최신 날짜를 표시하려는 팀에게는 야간 스윕도 의미가 있습니다.
비용이 업데이트를 주저하는 이유가 되어서는 안 됩니다. 최대 2,000개 도메인에 대한 야간 bulk_dr 호출은 1크레딧이 필요하며, 나머지 비용은 비용 테이블에 나열되어 있습니다.
누락된 값이 있을 때 작업은 어떻게 처리해야 하나요?
기존 점수와 날짜를 그대로 유지하고, 시도 자체를 실패로 기록하세요. 좋은 데이터 위에 빈 값을 덮어쓰면 깔끔해 보일 수 있지만, 유일한 기록이 사라집니다.
누락된 값과 0은 서로 다른 사실입니다. 필드 타입은 이 둘을 구분해야 하므로, 편집자가 빈 공간을 낮은 점수로 오해하지 않도록 해야 합니다.
각 배치의 제한을 어떻게 유지하나요?
목록을 2,000개 도메인을 초과하지 않는 청크로 나누고, 청크마다 하나의 호출을 보냅니다. 청크 크기를 단일 상수에 저장하여 제한 변경 시 한 줄만 수정하면 됩니다.
전송된 도메인 수와 저장된 읽기 횟수를 기록하세요. 두 수의 불일치는 배치 중 오류가 발생했음을 알리는 첫 번째 단서입니다.
편집자가 점수 옆에서 확인해야 할 내용은 무엇인가요?
편집자는 필드를 몇 초 만에 읽으므로, 필드도 몇 초 만에 답변해야 합니다. 바쁜 독자가 필요한 순서대로 밴드, 날짜, 정수 순으로 표시하세요.
레이블은 레이아웃만큼 중요합니다. link_dr_band라는 필드명이 'middle'이라고 표시되어 있으면 인덱스에 대해 아무것도 알려주지 않으므로, 옆의 메모에 해당 주의사항을 명시해야 합니다.
밴드 색으로 항목을 강조해야 하나요?
색상 배지는 바쁜 편집자에게 도움이 될 수 있지만, 중간 수준의 점수를 실패처럼 보이게 할 수도 있습니다. 색상은 밴드 이름에만 사용하고, 심각한 문제가 아닌 한 빨간색은 피하세요.
밴드는 검토를 위한 조언이지 게시를 위한 규칙이 아닙니다. 녹색 또는 황색 배지가 합격으로 읽히지 않도록 옆 레이블에 명시하세요.
동일한 밴드가 많은 항목에 나타날 경우, 항목을 확인하기 전에 먼저 규칙을 확인하세요. 사이트의 절반을 플래그하는 밴드는 보통 콘텐츠보다 임계값에 대해 알려주는 것입니다.
날짜가 오래되었을 때 메모에는 무엇을 넣어야 하나요?
오래된 날짜는 점수를 숨기지 않고 메모를 변경해야 합니다. '마지막 갱신보다 오래된 읽기'라는 문구는 편집자에게 다시 확인하라는 행동을 알려줍니다.
이 문구는 코드에서 생성하여 모든 항목이 동일한 방식으로 표시되게 하세요. 수기로 작성한 메모는 시간이 지남에 따라 흐려지고, 몇 달 후면 원래 의도를 기억하는 사람이 없어집니다.
콘텐츠 모델 스케치
필드명은 예시를 위한 것입니다. Contentful, Sanity, Strapi, Payload는 각자 고유한 방식으로 필드를 선언하므로 번역이 필요합니다.
