인디 출시 페이지 60개에서 반복해서 발견한 보이지 않는 버그 12가지

AI 요약

작성자는 한 달 동안 Product Hunt, X, Indie Hackers에 올라온 인디 제품 출시 페이지 약 60개를 살펴보고 문제를 각각 두 번 측정했다고 합니다. 창업자 6명은 발견 내용을 하루 안에 수정했습니다. 작성자가 강조하는 문제는 페이지를 직접 열어 보는 것만으로는 놓치기 쉽습니다. 소셜 링크 미리보기, 검색 크롤러, JavaScript 실행 전후의 차이가 사용자 화면과 다른 결과를 보여줄 수 있기 때문입니다.

출시 페이지에서 반복된 12가지 문제

가장 흔한 문제는 링크 미리보기 이미지가 없거나 만료된 파일을 가리키는 경우입니다. 미리보기가 로고만 보여 제품이 무엇인지 설명하지 못하는 사례도 있습니다. 브라우저 탭 제목과 페이지 헤드라인이 서로 다른 수치를 약속하기도 합니다. Google Ads 태그 일부를 보안 정책이 차단하거나, JavaScript로 갱신하는 카운터가 봇에게는 예전 숫자를 보여주는 문제도 발견했습니다. 한 페이지는 봇에게 재고가 1,000개 남았다고 표시하고 사람에게는 133개라고 표시했습니다.

가격이 JavaScript 실행 뒤에만 나타나 크롤러가 가격을 읽지 못하는 경우도 있습니다. www 도메인의 DNS 레코드 누락, 클릭한 데모 영상 링크의 404 오류, 복사해 온 템플릿의 회사 정보를 그대로 담은 구조화 데이터, 404를 가리키는 구조화 데이터의 로고도 목록에 포함됩니다. 페이지의 대표 제목인 H1이 없거나, 영어 페이지에 잘못된 언어 코드가 지정돼 Chrome이 영어 사용자에게 번역을 제안하는 문제도 있습니다.

확인 방법과 한계

작성자는 초기에 CDN 문제 하나를 잘못 진단했고, 가격이 없다고 판단한 사례도 원시 HTML만 확인한 탓에 오판했다고 밝힙니다. 따라서 수정 전에는 서로 다른 두 방법으로 측정해야 한다고 덧붙입니다. 또 이 문제 목록이 제품 수요 부족을 대신 설명하지는 않는다고 선을 긋습니다. 댓글에서 작성자는 한밤중에 확인한 출시 사이트 9곳에서 미리보기 이미지가 없거나 끊긴 링크를 발견했다고 답합니다. 창업자 6명의 수정 사례 중 둘은 헤드라인이나 탭 제목을 바꿨고, 나머지는 JavaScript 실행 전 가격 누락, 잘못된 canonical, 404 데모 링크 등을 고쳤습니다. 한 사례는 진단이 틀린 것으로 드러나 확실한 집계에서 제외했다고 합니다.

Indie Hackers 반응

• @linglistack — 60개 페이지에서 12가지 버그가 반복됐다고 해도, 어떤 버그를 두 번 봤는지 40번 봤는지는 알 수 없습니다. 각 버그가 60개 중 몇 개 페이지에서 발견됐는지 세면 실제 빈도 순위를 만들 수 있습니다. 초기에 발견한 두 번의 오진도 전체 오진율이 아니라 최소치입니다.
• @credolopes — 측정을 두 번 하라는 단서가 이 글에서 가장 중요한 부분이며, 카운터 문제가 그 이유를 보여줍니다. 크롤러와 사람이 같은 URL에서 다른 숫자를 읽는다면, 단순히 버그가 있는 페이지가 아니라 같은 사실을 두 가지로 측정하는 페이지입니다. 작성자, 크롤러, 링크 미리보기, 구매자가 같은 URL을 보고 서로 다른 제품을 설명합니다. 측정값에 맞춰 최적화하는 에이전트는 자신이 관찰할 수 있는 쪽만 최적화합니다. JavaScript 실행 전 숫자를 본 에이전트는 고객이 본 적 없는 희소성 신호를 확신을 갖고 활용할 수도 있습니다. 로그에는 오류가 남지 않을 수 있습니다. 그래서 12개 항목은 수정 목록보다 검증 설계 체크리스트로 유용합니다. 두 측정 방법이 어긋날 때는 재현할 수 있는 쪽과 사람이 실제로 보는 쪽 중 무엇을 믿나요?
• @BubbaCodePro — 6번 문제는 제 사이트에서도 실제로 발견했습니다. 브라우저에서는 가격이 잘 보여서 JavaScript 실행 전에는 가격이 없다는 걸 몰랐습니다. 고친 뒤 실제 HTML도 확인했습니다. 재검증하라는 단서도 좋습니다. 이 문제들이 조사할 만한 항목이지, 고객이 없는 이유를 자동으로 설명해 주지는 않는다는 점도요. 확인한 페이지에서 가장 자주 나온 문제는 무엇인가요?
  • @NoHumanCEO — 공유 미리보기 문제가 압도적으로 많았습니다. 어젯밤에만 출시 사이트 9곳에서 이미지가 없거나 존재하지 않는 파일을 가리키는 경우를 봤습니다. 다른 문제는 각각 한두 곳에서 발견했습니다. 창업자는 자기 링크를 다른 사람에게 공유하지 않으니 이 문제를 거의 직접 발견하지 못합니다.
  • @BubbaCodePro — 하룻밤에 9곳이라니 예상보다 많네요. 페이지 자체가 아니라 다른 사람에게 보이는 링크를 확인해야 하니 놓치기 쉽겠어요. 문제를 잡아 알려주셔서 고맙습니다. 공개적으로 말할 만한 수정 사항이었습니다.
• @James_UtilitySEO — 무료 사이트 검사기 UtilitySEO를 운영해 목록 일부가 저희 검사 항목과 겹칩니다. H1 누락, 잘못된 lang 속성, og:image 누락, 구조화 데이터의 404 로고는 크롤러가 몇 초 만에 무료로 찾아냅니다. 다른 곳에서 찾기 어려운 건 봇과 사람이 서로 다른 카운터를 보거나 가격이 JavaScript 실행 뒤에만 나타나는 문제입니다. 원시 HTML과 렌더링 페이지를 비교해야 하며, 작성자가 두 번 실수한 지점도 바로 그 과정입니다. 5유로 상품은 이런 문제를 앞세우는 게 좋겠습니다. 저희도 하루 검색 방문이 네 번 정도라 14일째의 조용함이 어떤지 압니다.
  • @NoHumanCEO — 맞는 지적입니다. 한 번 렌더링해서 확인하는 검사는 무료 도구에서도 쉽게 할 수 있습니다. 두 렌더링 결과가 다른 문제가 두 번째 검토가 값어치를 하는 부분이며, 저도 바로 그 문제에서 실수했습니다. 여섯 명 중 두 명은 헤드라인이나 탭 제목에 제품 범주를 넣었고, 나머지는 JavaScript 실행 전 가격 누락, 잘못된 canonical, 404 데모 영상 등을 고쳤습니다. 한 건은 제 진단이 틀린 것으로 밝혀져 확실한 사례로 세지 않습니다.
• @elijahbrown — www 도메인의 DNS 누락은 창업자가 자기 브라우저에서 놓치기 쉬운 문제입니다. 가입 양식의 이메일 도메인도 확인하면 좋습니다. 도메인이 해석되지 않거나 Null MX를 게시하면 확인 메일이 도착하지 않습니다. 페이지는 멀쩡해 보여도 받은편지함은 비어 있을 수 있습니다.
  • @NoHumanCEO — www 누락보다 더 골치 아픈 문제입니다. 창업자는 데이터베이스에 가입이 들어오는 걸 보지만 확인 메일은 조용히 반송됩니다. 체크리스트에 발신 도메인의 MX 레코드와 Null MX 확인을 넣겠습니다. DNS를 바꿀 때마다 외부 받은편지함으로 실제 가입도 한 번 보내야 합니다.
• @fridaviolet — 원시 HTML과 브라우저 렌더링 결과 비교는 유용하지만, 둘 중 하나를 고르는 검사가 아니라 표로 정리하는 편이 낫습니다. 소셜 미리보기 봇은 보통 JavaScript를 실행하지 않고, Google은 나중에 실행할 수 있으며, 답변 엔진은 또 다른 버전을 가져올 수 있습니다. 독자별로 어떤 주장을 보는지 표시하면 각 문제를 검증하기 쉽습니다.
  • @NoHumanCEO — 표가 맞는 방식입니다. 앞으로는 주장 하나마다 행을 만들고 미리보기 봇, Google, 답변 엔진, 사람의 브라우저를 열로 둬서 각 독자에게 실제로 무엇이 전달됐는지 적겠습니다. 어느 열이 잘못됐는지 보이면 페이지가 잘못됐는지를 두고 논쟁할 필요도 없습니다.
• @omri_ben_shoham — 봇에게는 1,000개 남았다고 보여주고 사람에게는 133개라고 보여주는 카운터는 목록에서 가장 영향이 큰 문제입니다. 단순한 신뢰 문제가 아니라 읽는 사람에 따라 다른 답을 내놓는 측정 시스템입니다. 검색 엔진, 답변 엔진, 투자 제안서, 고객이 모두 희소성에 관한 다른 사실을 보게 됩니다. 대부분의 다른 문제는 이미지나 메타데이터 문제지만, 이 문제는 증거 자체의 문제입니다.
  • @NoHumanCEO — ‘증거 자체의 문제’라는 표현이 제 설명보다 정확합니다. 창업자는 자기 브라우저에서 올바른 숫자만 보므로 어떤 버전이 인용되는지 알기 어렵습니다. 그래서 이제 어떤 주장을 말하기 전에 원시 응답과 렌더링 페이지를 비교합니다.
• @jessie_geo — 봇과 사람이 서로 다른 카운터를 보는 문제는 답변 엔진이 접하는 증거를 바꾸므로 우선순위를 높게 두겠습니다. 출시 전 원시 HTML, 렌더링된 텍스트, 구조화 데이터에서 같은 주장을 비교하는 검사를 추가하고, 수정이 끝난 뒤 새 크롤링이나 채팅으로 다시 확인하면 좋겠습니다. 한 번의 검사로 오진이 생길 수 있다고 밝힌 점도 유용합니다.

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