설정 가이드
작동하는 카운터에는 서버 라우트 하나와 작은 컴포넌트 하나가 필요합니다. 이 가이드는 두 가지를 모두 구축하며, 초기 버전에서 종종 간과하는 실패 상태도 함께 다룹니다.
Node 또는 Python 백엔드와 모든 프론트엔드 프레임워크를 가정합니다. 아래 모든 요청은 문서화된 API를 타겟팅하며, 베이스 URL은 브랜드의 자체 도메인인 alfalinks.net/api.php입니다.
/auth/google.php에서 Google로 로그인하고 계정 페이지에서 sk_ 키를 복사한 뒤 서버 환경 변수에 저장하세요. 프론트엔드에서는 이 키를 직접 보지 않습니다.
도메인을 검증하고 우리 API를 호출한 뒤 UI에서 필요한 필드만 반환하는 /internal/links?domain=... 같은 엔드포인트를 노출하세요. 사용자가 아무 문자열이나 입력할 수 있으므로 검증이 중요합니다.
overview 액션은 비용이 없으므로, 카운터의 첫 번째 버전은 청구 리스크가 전혀 없습니다. 화면에 유료 액션이 필요할 때 전환하세요.
로딩, 데이터, 사용 불가. 사용 불가는 HTTP 401, HTTP 402 및 네트워크 실패를 포괄하며, 절대 0을 표시해서는 안 됩니다.
우리 인덱스는 대략 월간으로 갱신됩니다. '링크 데이터 월간 업데이트'라는 회색 라인을 표시하면 '어제 링크를 추가했는데'로 시작하는 지원 티켓을 방지할 수 있습니다.
한 화면에 들어올 정도로 짧습니다. 캐시는 여기서는 일반 Map입니다. 프로세스가 여러 개라면 Redis로 교체하세요.
const cache = new Map();
const MONTH = 30 * 24 * 3600 * 1000;
app.get('/internal/links', async (req, res) => {
const domain = String(req.query.domain || '').toLowerCase().trim();
if (!/^[a-z0-9.-]+\.[a-z]{2,}$/.test(domain)) return res.status(400).json({ok:false});
const hit = cache.get(domain);
if (hit && Date.now() - hit.t < MONTH) return res.json(hit.v);
const r = await fetch(`https://alfalinks.net/api.php?action=overview&q=${domain}`);
if (!r.ok) return res.status(502).json({ok:false});
const v = await r.json();
cache.set(domain, {t: Date.now(), v});
res.json(v);
});
카운터는 쉬운 반입니다. 배지에는 추가 호출 하나가 더 필요합니다.
고객 도메인 테이블의 경우, 행마다 호출하는 대신 최대 2,000개 도메인을 처리하는 단일 bulk_dr 요청을 보내세요. 행 수에 관계없이 비용은 1 크레딧이며, 응답은 각 도메인을 0-100 점수로 매핑하므로 캐시된 개요 옆에 저장하세요.
정규화된 호스트명으로 도메인을 일치시키세요. 스키마, 경로 및 선행 www를 제거하지 않으면 행의 절반이 조회에 실패해 공백이 표시됩니다.
신규 사용자는 설정 페이지를 잘 읽지 않습니다. 그들은 기능이 노력이 worth한지 확인하고 싶어 하며, 실제 수치를 보여주는 백링크 카운터는 어떤 폼보다 빠르게 그 답을 줍니다. 값을 먼저 배치하세요. 설정은 두 번째입니다.
무료 개요 액션에는 키가 필요 없으므로, 첫 번째 화면에서는 사용자가 아무것도 구성하기 전에도 수치를 표시할 수 있습니다.
도메인 하나와 무료 호출 하나만 필요합니다. 온보딩 중 자신의 사이트를 입력하면 같은 페이지 뷰 내에서 카운터가 나타나는 신규 사용자를 상상해 보세요. 그 단일 수치는 단계 목록보다 설정을 시작하는 데 더 큰 영향을 미치므로, 나머지 설정은 그 뒤에 숨기세요.
사용자는 카드, 키 또는 두 번째 폼을 요청하기 전에 자신이 얻을 것을 봅니다. 첫 렌더링의 어떤 요소도 게이트처럼 보이지 않아야 합니다.
수치 바로 뒤, 그 앞에就不要. '매월 이 도메인을 추적하려면 연결하세요'와 같은 짧은 문구는 카운터 아래에 잘 맞습니다. 프롬프트가 수치 위에 있으면 사용자는 이를 게이트로 인식하고 이탈합니다.
각 설정 단계를 완료한 사용자를 추적하세요. 작은 퍼널은 사용자가 중단하는 지점을 보여주며, 문구 변경은 새로운 기능보다 해당 수치를 더 크게 움직일 수 있습니다.
실패 경로부터 테스트하세요. 성공 경로는 스스로 테스트됩니다.
스테이징 환경에서 키를 회수하고 카드가 0이 아닌 '사용 불가'를 표시하는지 확인하세요. 그런 다음 테스트 잔액을 고갈시켜 402를 트리거하고, 스키마와 후행 경로가 포함된 도메인 같은 잘못된 입력을 붙여넣어 검증자가 크레딧이 소모되기 전에 이를 거부하는지 증명하세요.
짧은 스모크 테스트는 CI에 포함해야 합니다. nytimes.com에서 무료 overview 호출을 매일 밤 실행하면 라우트와 키가 여전히 작동하는지 알 수 있습니다.
모든 문자열을 허용하는 카운터는 잔액에 대한 열린 문문입니다. 라우트가 라이브로 가기 전에 누가 무엇을 요청할 수 있는지 결정하고, 아무도 열지 않는 위키 페이지가 아닌 코드에 답을 작성하세요.
세 가지 질문이 항상 발생합니다: 어떤 도메인, 어떤 한도, 키는 어디에 있는지.
워크스페이스가 권리를 주장하는 도메인만, 그리고 제공하기로 선택한 공개 조회만 허용하세요. 워크스페이스가 두 사이트를 소유한다고 가정해 봅시다. 라우트는 이 두 도메인만 허용하고 명확한 메시지로 나머지를 거부해야 합니다. 이는 한 테넌트가 자신들의 도메인이 아닌 도메인에 크레딧을 사용하는 것을 방지합니다.
라우트의 호스트명 검사는 최소한입니다. 입력이 도메인처럼 보인다는 것을 증명할 뿐, 사용자가 소유한다는 것을 증명하지는 않으므로, 소유 목록은 별도의 테이블로 자체 데이터베이스에 유지하세요.
자체 저장소에 워크스페이스별 할당량을 설정하고 호출 횟수를 카운팅하세요. 우리 측의 잔액은 단일 선불 풀이므로 어떤 고객이 얼마를 썼는지 알 수 없습니다. 조회 페이지 노트는 같은 문제의 공개 측면을 다룹니다. 워크스페이스가 한도에 도달하면 평범한 메시지를 반환하고 캐시가 이미 보유한 내용으로 응답하도록 하세요.
세당 노트의 산술을 기반으로 한도를 선택하고, 플랜이 변경될 때 다시 검토하세요. 할당량을 신뢰하기 전에 두 번째 워크스페이스로 라우트를 테스트하세요.
아니요. 키는 서버에 있고 브라우저는 라우트를 호출합니다. 이 분리는 모든 청구 호출이 제어하는 코드를 거치기 때문에 할당량을 가능하게 합니다. 키가 번들에 포함되는 경우 같은 날 회전하고 미실행 호출에 대해 잔액 로그를 확인하세요. 일부 팀은 프론트엔드가 빌드 시점에 읽는 구성 파일에 키를 저장하며, 해당 파일이 번들에 포함됩니다. 빌드 단계에서 볼 수 있는 모든 것에서 키를 제외하고, 릴리스 전마다 배송된 파일을 확인하세요.
무료 액션은 키 없이 공개 페이지에서 호출할 수 있으며, 이것이 브라우저가 API에 직접 통신할 수 있는 유일한 경우입니다.
알고 있는 것보다 적게 말하세요. '백링크'로 레이블된 카운터는 '왜 Ahrefs는 다른 수치를 보여주나요?'라는 질문을 유발하며, 정직한 답은 두 크롤러가 웹의 서로 다른 조각을 본다는 것입니다.
출처와 월로 수치를 레이블링하세요. '참조 도메인, AlfaLinks 인덱스, 2026년 10월'과 같은 문구는 더 길지만 논쟁이 시작되기 전에 끝내며 작은 카드에서도 잘 읽힙니다.
표시를 위해 반올림하세요. 월요일에 12,481을 보고 금요일에도 12,481을 보는 사용자는 변동성을 보는 사용자보다 도구를 더 신뢰하며, 우리의 월간 갱신은 이러한 안정성을 무료로 제공합니다.
옆에 0-100 점수를 표시하려면 먼저 백링크 점수 노트를 읽으세요. 이는 자체 지표이므로 명명이 중요합니다.
| 신호 | 의미 | 사용자가 보는 것 | 수행할 작업 |
|---|---|---|---|
| HTTP 401 | 누락 또는 잘못된 키 | '링크 데이터 사용 불가' | 스스로 페이지 확인: 배포 버그 |
| HTTP 402 | 크레딧 고갈 | '링크 데이터 사용 불가' | USDT(TRC-20)로 충전 |
| ok: false | 요청 거부됨 | 인라인 재시도 링크 | 도메인 및 액션 로깅 |
| 타임아웃 | 네트워크 문제 | 캐시된 값이 있는 경우 사용 | 한 번 재시도 후 백오프 |
카운터는 크게 실패하기보다 조용히 실패하는 경우가 훨씬 많습니다. 고객이 다음에 물을 질문에 답할 만큼 충분한 로그를 남기고, 개인 데이터는 로그에서 완전히 제외하세요. 짧은 줄이 이깁니다. 지원 질문 하나에 답하는 줄은 작성할 수 있는 어떤 알림보다 더 많은 시간을 절약합니다.
카운터에 대한 지원 스레드의 대부분은 세 가지 질문 중 하나이므로 로그를 그에 따라 계획하세요. 키 회전 단계 옆에 이 세 가지 질문을 러닝북에 보관하세요.
액션, 도메인, 상태 코드, 캐시 만료 시간 및 반환된 크레딧 잔액. 이 다섯 가지 필드는 대부분의 지원 질문에 답합니다. 사용자가 카운터가 오래된 수치를 표시하는 이유를 묻는다고 가정해 봅시다. 캐시 만료 시간과 인덱스 월은 문제가 캐시인지 레이블인지 알려줍니다.
에러 트레이스를 포함해 모든 줄에서 API 키를 제외하세요. 로거에서 마스킹하세요. 누출된 줄 하나만으로도 전체 계정이 고갈될 수 있습니다.
세 가지 수치를 모니터링하세요: 사용 불가 상태의 비율, 크레딧 잔액 추세 및 캐시 히트율. 사용 불가 상태의 급격한 증가는 보통 키 또는 잔액 문제를 가리킵니다. 잔액의 느린 감소는 보통 캐시 키가 너무 구체적임을 가리킵니다.
각 읽기에는 다른 해결책이 있으므로, 세 가지를 모두 위한 단일 대시보드 타일은 거의 도움이 되지 않습니다. 세 읽기를 주간 노트의 한 줄에 마지막 값과 전주 대비 변화와 함께 배치하세요. 고립된 숫자는 추측을 유도하지만, 짧은 추세는 대화를 동일한 사실에 유지합니다.
