백링크 332개인 줄 알았는데 하나였습니다. 내 사이트의 주장도 4주 동안 틀렸습니다

AI 요약

작성자는 자신의 사이트 solostacklab.net에서 도구를 직접 사용한 뒤 경험을 기록합니다. 이번 글에서는 백링크 수치 검증, 크롤러가 놓친 HTTP 응답 오류, 게시한 내용의 재검증이라는 세 가지 점검 결과를 공유합니다. Ahrefs와 Semrush를 언급하지만, Ahrefs에는 제휴 프로그램이 없고 Semrush의 제휴 신청은 거절됐다고 밝혔습니다.

332개 referring domain 중 실제 사이트는 하나였습니다

Google Search Console의 Links 보고서에 아무것도 표시되지 않아 Ahrefs Free에 가입했습니다. 사이트 소유권을 확인하면 무료로 사용할 수 있는 요금제입니다. Ahrefs는 332개의 referring domain을 보여줬지만, 목록을 직접 확인하자 실제 사이트는 Indie Hackers 하나뿐이었습니다. Indie Hackers에서 발견된 링크는 5개였고 모두 dofollow 링크는 아니었습니다.

나머지 대부분은 도메인을 자동으로 삽입한 SEO 서비스 형태의 페이지였습니다. Ahrefs 자체도 이 페이지들을 스팸으로 표시했습니다. 최근 30일 동안 새로 추가된 도메인만 213개였습니다. 작성자는 Google의 안내에서 대부분의 사이트는 disavow를 사용할 필요가 없다고 확인하고, 별도 조치를 하지 않기로 했습니다. 숫자만 보면 백링크가 늘어난 것처럼 보였지만 목록을 열어보면 거의 전부 정크였다는 경험입니다.

일반 크롤러가 놓친 soft 404

작성자는 사이트를 Screaming Frog와 Semrush로 크롤링했고 별도의 검사 스크립트도 사용했습니다. 세 검사 모두 문제가 없다고 나왔습니다. 이후 Cloudflare의 AI Crawl Control 페이지에서 실제 봇이 요청한 URL을 확인하다가, 사이트에 존재하지 않는 모든 URL이 홈페이지를 200 상태 코드로 반환한다는 사실을 찾았습니다.

존재하지 않는 페이지가 404가 아니라 홈페이지와 함께 200을 반환하는 soft 404였습니다. 작성자는 일반 크롤러가 사이트에 실제로 연결된 링크만 따라가므로, 애초에 존재하지 않는 URL을 요청하지 않아 이 문제를 놓쳤다고 추정합니다. 이후 실제 404 페이지를 추가했습니다.

이 점검은 링크 구조를 따라가는 크롤러와 서버 로그에 나타나는 실제 요청 목록이 서로 다른 데이터를 제공한다는 사례입니다. 사이트에 존재하는 URL만 검사하는 도구는 잘못된 URL이 어떻게 응답하는지 확인하지 못할 수 있습니다.

www 주소가 4주 동안 전체 사이트를 복제했습니다

작성자는 Semrush 리뷰에서 www 버전의 도메인이 기본 도메인으로 redirect된다고 썼습니다. 하지만 글을 게시한 뒤 다시 테스트하지 않았습니다. 실제로는 www 주소가 301 redirect를 반환하지 않고 사이트 전체를 복제한 채 200으로 응답하고 있었습니다.

문제를 발견한 뒤 적절한 301 redirect를 추가했고, 기존 글도 조용히 고치지 않고 날짜가 포함된 정정문을 덧붙였습니다. 글의 마지막에서는 새 도메인에서 첫 번째 genuine backlink를 얻은 구체적인 방법을 독자들에게 질문합니다.

Indie Hackers 반응

• @AmandaBrown — 홈페이지를 200으로 반환하는 soft 404는 크롤러가 놓치는 전형적인 문제입니다. 말씀하신 것처럼 크롤러는 존재하는 링크만 따라가므로 잘못된 URL을 직접 테스트하지 않습니다. 일반 크롤러가 아니라 Cloudflare 쪽에서 발견한 점이 좋습니다. 첫 번째 genuine backlink에 관해서는, 아직 존재하지 않는 구체적인 내용을 가장 먼저 문서화하는 방식이 제 경험에서 가장 꾸준히 통했습니다. ‘백링크를 얻는 방법’ 같은 주제는 이미 5만 개가 있습니다. 표준 크롤러가 놓친 Cloudflare AI Crawl Control과 Screaming Frog 조합처럼 구체적인 내용이 더 링크되기 쉽습니다. 링크를 걸 사람이 ‘이 방법은 여기서 처음 봤다’고 말할 수 있는지 묻습니다. 그렇다면 언젠가 인용될 가능성이 있습니다. Cloudflare에서 soft 404를 발견한 과정은 crawl budget이나 서버 측 검증을 다루는 글에서 인용할 만합니다. Semrush 페이지에 날짜를 적어 정정한 것도 SEO 도구를 다루는 사람들이 신뢰를 쌓는 방식입니다. 첫 백링크는 대체로 이미 참여 중인 커뮤니티에서 나옵니다. 누군가 글을 읽고 Slack이나 뉴스레터에 공유하는 식입니다. 이 글은 생각보다 링크하기 좋은 글입니다.
  • @Shinya — ‘그 사람이 이 내용을 어디에서도 찾지 못했다고 말할 수 있는가’라는 기준이 유용합니다. 다음 글부터 적용하겠습니다.
• @iptvkaufen24net — Ahrefs가 332개 도메인을 보여주고 Search Console에는 거의 아무것도 나오지 않는 차이가 큽니다. GSC가 Indie Hackers 링크도 표시하지 않은 이유를 알아냈습니까? 단순히 보고가 느린 것인지, Ahrefs보다 훨씬 많은 링크를 Google이 걸러내는 것인지 궁금합니다.
  • @Shinya — 아직 알아내지 못했습니다. 사이트를 시작한 뒤 Links 보고서에는 Indie Hackers 링크를 포함해 아무것도 표시되지 않았습니다. 보고가 느린 것인지 필터링된 것인지 판단할 수 없습니다.
• @Nick_ClearView_QoE — 주장한 숫자와 검증한 숫자는 완전히 다른 이야기를 할 수 있습니다. 대부분의 사람은 실제 내용을 확인하지 않습니다. 무엇 때문에 확인하게 됐습니까? 다른 지표가 이상하게 움직였습니까, 아니면 그냥 점검해보기로 한 것입니까?
  • @Shinya — 각각 계기가 달랐습니다. Search Console의 Links 보고서에 늘 아무것도 나오지 않아서 두 번째 출처를 찾았고, 그래서 Ahrefs 목록을 읽었습니다. soft 404는 Cloudflare에서 봇 요청을 확인한 뒤 존재하지 않는 URL을 직접 요청하면서 발견했습니다. www 문제는 4주 전에 작성한 주장을 다시 테스트하면서 찾았습니다.
• @Passcite — 4주 동안 틀린 주장이 가장 인상적이었습니다. 저도 비슷한 일이 있었는데 더 심했습니다. 제품의 숫자를 무료 보고서 질문 30개에서 12개로 바꾼 뒤, 마케팅 페이지 곳곳에서 ‘구매자 질문 30개’라는 문구를 68개나 발견했습니다. 작성 당시에는 모두 맞는 내용이었습니다. 해결한 방법은 더 꼼꼼해지는 것이 아니라 숫자의 소유자를 하나로 옮기는 일이었습니다. 이제 독자에게 약속하는 모든 수치인 질문 수, 엔진 이름, 요금제 가격을 하나의 모듈이 관리합니다. 페이지에서는 그 값을 가져오므로 같은 내용을 두 번 입력하지 않습니다. 제품과 페이지가 일치하는지 테스트도 합니다. 제품을 바꾸고 문구를 잊으면 사이트가 오래된 상태로 남는 대신 빌드가 실패합니다.
  • @Shinya — sitemap을 테스트 목록으로 사용하는 방법이 좋습니다. 제가 한 방식보다 간단합니다. 방금 제 사이트에도 실행해봤습니다. robots.txt는 모두 허용하고 있었고 sitemap의 URL 32개도 모두 200을 반환했습니다. 이번 문제는 없었지만 정기 점검에 포함하겠습니다. 단일 출처는 아직 절반만 적용했습니다. 가격은 마지막 확인 날짜가 있는 JSON 파일에 저장하고 90일이 지나면 스크립트가 경고합니다. 하지만 본문에 적힌 주장은 아직 그렇지 않습니다.
• @DannieDan — Screaming Frog와 Semrush가 정상으로 나온 이유가 이해됩니다. 두 도구는 사이트에 연결된 URL만 요청하므로 존재하지 않는 경로가 200을 반환하는 문제를 보지 못합니다. Cloudflare의 봇 목록은 다른 데이터를 제공합니다. 팀에서 요청할 계획이 없던 URL이 나타나는 곳입니다. sitemap이나 이미 존재하는 링크만 검사하는 도구는 모든 것이 정상이라고 계속 보고할 수 있습니다.
  • @Shinya — 맞습니다. 제 크롤러는 제가 이미 알고 있는 URL만 검사했습니다. Cloudflare는 다른 사람들이 실제로 요청한 URL을 보여줬습니다.
• @chprowtt2 — Ahrefs의 332개가 1개로 줄어드는 경험은 거의 보편적입니다. 무료 도구의 발견 목록에는 PBN 스크랩, 디렉터리 집계 사이트, 도메인을 자동으로 삽입하는 만료 도메인 목록이 대부분 섞여 있습니다. Search Console의 Links 보고서는 60~90일이 지나면 Google이 이런 데이터를 많이 걸러내기 때문에 신호 대 잡음비가 조금 나아집니다. 첫 번째 non-spam 링크에 관해서는 독창적인 데이터나 재현 결과가 제 경험에서 가장 잘 작동했습니다. 332개에서 1개로 줄어든 경험 자체가 링크를 얻을 만한 글입니다. 도구 하나와 주장 하나를 정하고 실제로 테스트한 뒤 원자료를 공개하면 됩니다. 정리 글을 쓰는 사람은 인용할 출처를 찾고 있으므로 그 출처가 될 수 있습니다. 가입 없이 쓰는 무료 도구도 좋습니다. 계산기, 변환기, 검사기처럼 복잡하지 않아도 됩니다. 사람들이 5초 안에 작은 불편을 해결하도록 만들어야 합니다. 대형 SaaS 성장 블로그보다 특정 분야의 작은 블로그에 게스트 글을 보내는 편도 낫습니다. 최근 3개월 안에 글을 올렸는지 확인하고 DR 점수는 무시하는 편이 좋습니다. soft 404도 잘 찾으셨습니다. Cloudflare의 crawl view는 잘 쓰이지 않는 무료 진단 도구입니다. WordPress 사이트를 점검하면 너무 공격적인 redirect 규칙 때문에 존재하지 않는 slug가 홈페이지와 함께 200을 반환하는 경우를 자주 봅니다.
  • @Shinya — 유용한 목록입니다. Search Console에 관해서는 약 6주가 지났는데도 이 사이트의 Links 보고서에 아무것도 나오지 않습니다. Indie Hackers 링크도 표시되지 않았습니다. 60~90일을 기대하고 있지는 않습니다. robots.txt도 확인했고 모두 허용 상태였습니다.
• @GregoryScottHenson — 백링크 숫자는 잡음이고, 잘못된 주장이 진짜 문제입니다. 가이드의 법적 기준 하나가 틀리면 스팸 도메인 332개보다 더 큰 손해를 줍니다. 독자가 그 오류를 발견하면 다른 40개의 내용도 조용히 믿지 않게 됩니다. 제가 지켜온 규칙은 숫자, 가격, 규제 한도를 담은 문장마다 원출처 URL을 함께 저장하는 것입니다. 정기적으로 다시 확인할 가치가 있는 문장은 그런 문장뿐입니다.
  • @Shinya — 좋은 규칙입니다. 이제 숫자 옆에 출처 URL을 저장하겠습니다.
• @cravveo — 글을 읽고 제 사이트에서도 soft 404와 www 검사를 실행했습니다. 임의의 URL은 실제 404를 반환했고, www는 apex 도메인으로 301 redirect됐으며 canonical도 설정돼 있었습니다. 제가 놓친 것은 콘텐츠 주장이었습니다. 한 가이드에서 EU 소기업 기준을 매출액만으로 적었는데, 지침에는 매출액 또는 대차대조표 총액이 200만 유로 이하라고 되어 있었습니다. 다음 날 원문 지침과 글을 대조하다가 발견했습니다. 어떤 주장을 다시 테스트할지 어떻게 정합니까? 목록을 관리합니까, 아니면 일정에 맞춰 다시 확인합니까?
  • @Shinya — 둘 다 하고 있지만 아직 엉성합니다. 가격에는 마지막 확인 날짜가 있고 90일이 지나면 스크립트가 경고합니다. 하지만 www 주장처럼 다른 내용에는 문제가 생기기 전까지 목록도 일정도 없었습니다. 이제 수정한 뒤에는 제대로 작동할 것이라고 가정하지 않고 최종 상태를 다시 테스트합니다.
• @watson_engineer — soft 404는 분석에도 영향을 줍니다. 게시하지 않은 URL에서 홈페이지를 실제 페이지뷰로 기록하기 때문입니다. 저는 봇 요청 로그에서만 그런 URL을 확인합니다. 그래서 amami.dev에서는 assistant와 bot 요청을 방문자 수에서 제외합니다.
  • @Shinya — 분석 측면은 생각하지 못했습니다. 저는 Clarity를 쓰는데, 아는 범위에서는 브라우저에서 스크립트가 실행될 때만 기록합니다. JavaScript를 실행하는 크롤러가 섞였는지는 확인하지 않았습니다. 점검해보겠습니다.
• @peptides18 — 332보다 봐야 할 숫자는 최근 30일 동안 추가된 213개입니다. 한 번의 스크랩이 아니라 도메인을 계속 재생성하는 활성 목록에 들어갔다는 뜻입니다. 앞으로 보게 될 백링크 수치는 계속 대부분 잡음이 될 것입니다. 지금 실제 링크 하나를 손으로 셀 수 있을 때 기록해두는 편이 좋습니다. disavow를 하지 않는다는 데에도 동의합니다. 그 페이지들은 이미 무시되고 있으므로 disavow는 대체로 오후 시간을 쓰게 만들 뿐입니다.
  • @Shinya — 332가 아니라 213을 추적하라는 지적이 좋습니다. 이제 총량보다 그 숫자를 보겠습니다. ‘무해하다’보다 ‘이미 무시되고 있다’가 disavow를 하지 않는 이유를 더 잘 설명합니다.
• @sniper8192 — 332개에서 1개가 된 발견과 soft 404는 생각보다 연결돼 있습니다. 모든 도구의 referring-domain 수에는 이런 자동 생성 페이지가 섞입니다. dofollow인지 nofollow인지보다 링크 페이지에 실제 트래픽과 편집 의도가 있는지가 더 중요합니다. Indie Hackers의 링크는 다른 327개를 합친 것보다 가치가 큽니다. nofollow는 2019년부터 지시가 아니라 힌트였고, 그래도 크롤러의 발견을 돕습니다. Ahrefs에서 봐야 할 지표는 도메인 수가 아니라 새 referring domain 중 자체 organic traffic을 가진 곳의 수입니다.
• @sniper8192 — soft 404 쪽이 더 큰 문제이고 진단도 맞습니다. 클라이언트 측 크롤러는 찾을 수 있는 URL만 요청하므로 ‘모든 URL에 200을 반환하는’ 설정 오류를 보지 못합니다. 영구 점검으로 봇 user-agent를 사용해 존재하지 않는 경로를 요청하고, 브라우저가 받는 상태 코드와 비교해보겠습니다. 첫 링크를 얻는 방법은 ‘사람들이 인용하고 싶어 하는 것을 만들라’는 말을 더 구체화하면 됩니다. 여기나 Reddit, 특정 포럼에서 ‘이 내용의 출처가 있습니까?’라는 질문이 올라왔는데 답이 부실한 경우를 찾습니다. 확실하고 인용하기 쉬운 답을 작성한 뒤 질문이 올라온 곳에 답변으로 공유합니다. 대부분의 첫 링크는 아웃리치나 디렉터리가 아니라, 아무도 제대로 답하지 않은 질문에 답하면서 생깁니다.
  • @Shinya — 봇 user-agent 검사를 변형해 실행해봤습니다. 제 컴퓨터에서 user-agent만 속이는 방식은 실제 크롤러가 아닙니다. 그래서 Cloudflare에서 IP가 검증된 봇 로그를 보는 편이 더 유용했습니다. soft 404가 있는 사이트를 AI crawler가 낮게 평가한다는 출처가 있습니까? 저는 아직 그런 자료를 보지 못했습니다.
• @AnchorsLab — 제가 처음 얻은 실제 백링크는 사람들이 이미 검색하는 곳에서 구체적인 질문에 답하고, 정말 문제를 해결할 때만 링크를 붙이는 방식이었습니다. 디렉터리 덤프는 가짜 referring domain처럼 보이는 경우가 많습니다. 많은 링크보다 유용한 페이지 하나가 낫습니다.
  • @Shinya — 계속 읽어온 패턴이지만 실제 장소가 잘 그려지지 않습니다. Reddit, 포럼, Stack Overflow, 특정 분야 사이트 중 어디였습니까? 몇 주 동안 Indie Hackers와 Reddit에서 질문에 답했지만 링크로 이어지지는 않았습니다. 어떤 종류의 질문이었는지 궁금합니다.
• @suraj09 — ‘백링크 332개가 실제로는 하나’라는 발견이 아픕니다. SEO 숫자는 실제 출처를 확인하기 전까지 성과처럼 보일 수 있습니다. genuine backlink를 얻으려면 백링크 숫자를 직접 좇기보다 적절한 커뮤니티에서 유용한 사람이 되는 편이 현실적으로 보입니다. SEO를 위한 백링크를 주로 만들고 있습니까, 아니면 링크 사이트의 referral traffic도 기대합니까?
  • @Shinya — 주로 SEO를 보고 있습니다. 지난주 Search Console 기준으로 대부분의 페이지가 검색어에서 3~8위에 있지만 노출은 거의 없습니다. 그래서 트래픽 문제보다 신뢰 문제로 보고 있습니다. referral traffic은 부수적인 이득이고, 우선 실제 링크를 얻고 싶습니다.

원문: Indie Hackers / 번역·요약: Trawling