Indie Hackers

Two weeks of SEO work did less for my traffic than one feature I almost didn't build

2주간의 SEO 작업보다 트래픽에 더 큰 변화를 준 기능 하나

도메인 이름 때문에 검색 엔진에서 영화 사이트로 오인받던 개발자가 2주간 SEO를 손본 뒤, 사용자 요청에 따라 PDF에 이미지를 넣는 기능을 추가했습니다. 작성자는 검색 노출을 정리하는 작업과 실제 검색 의도에 맞는 제품 기능을 만드는 일이 서로 다르다고 설명합니다.

에디터 노트

SEO 정비가 검색 엔진의 오분류를 줄였고 이미지 도구는 비어 있던 검색 의도를 제품에 채웠다는 구분이 이 사례의 설득력 있는 부분입니다. 다만 새 기능은 출시 하루 만에 작성자가 본격적인 트래픽 변화를 아직 확인하지 못했습니다. "SEO보다 기능이 트래픽을 움직였다"는 제목의 대비는 현재로서는 결과가 아니라 예상에 기대고 있습니다. 댓글에서도 HTML 사이트맵과 수동 색인 요청 중 어느 쪽이 나은지는 사이트 규모에 따라 갈립니다. 더 직접적인 논점은 이미지 기능을 별도 URL로 제공할지입니다. 댓글에서는 편집기를 이미지 모드로 바로 여는 별도 진입 페이지를 제안했지만, 실제 색인이나 클릭 성과는 아직 없습니다. 검색 의도에 맞는 기능을 만들었다는 사실과 그 기능이 검색 유입으로 이어졌다는 결과를 구분해서 읽어야 합니다.

AI 요약

영화 프로젝트에 쓰려고 산 soroflix.xyz 도메인을 브라우저 기반 파일 도구에 재사용하자 Google은 사이트를 영화 관련 페이지로 분류했습니다. Search Console에서 실제로 들어온 검색어는 "soro films"뿐이었고 PDF 편집이나 EXIF 제거 같은 도구 검색어에서는 노출되지 않았습니다.

2주간 진행한 SEO 작업

작성자는 모든 페이지 제목을 고치고 WebSite 스키마에 alternateName을 추가했습니다. 10개 도구를 나열하는 ItemList 스키마를 넣었고 서로 달랐던 두 페이지의 canonical 태그도 수정했습니다. 색인되지 않은 페이지마다 URL Inspection으로 색인을 요청했습니다. 그러나 약 열흘 동안 검색어는 바뀌지 않았고 노출 수는 22회에서 약 40회로 늘어나는 데 그쳤습니다. 클릭은 작성자가 사는 베냉에서만 발생했습니다.

사이트맵은 Cloudflare Pages에서 정상 응답하고 XML과 콘텐츠 유형도 유효했지만 Google Search Console이 가져오지 못했습니다. 작성자는 Dev.to에 올라온 글을 근거로 이 오류가 서버가 아니라 Google 쪽 문제라고 판단했습니다. HTML 사이트맵을 만드는 대신 15개 페이지를 하나씩 색인 요청하는 방식을 택했습니다. 규모가 작은 사이트에서는 페이지별 진행 상태를 확인할 수 있지만 페이지가 늘면 확장하기 어렵다고 설명합니다. 2주가 끝날 무렵 "soro films" 검색어는 사라지고 브랜드명과 도구 관련 검색어가 나타났습니다. 작성자는 제목과 스키마를 정리한 작업이 사이트의 영화 연관성을 없애는 데 시간이 걸렸다고 봅니다. 클릭과 노출은 여전히 적습니다.

사용자 요청으로 추가한 PDF 이미지 도구

사이트를 실제로 사용한 한 사람이 PDF에 이미지를 넣는 기능이 있느냐고 물었습니다. 기존 편집기에는 텍스트와 워터마크, 서명 기능이 있었지만 로고나 사진, 스캔한 도장을 넣는 기능은 없었습니다. 작성자는 서명 기능의 구조를 재사용해 이미지 배치 도구를 이틀 만에 만들었습니다. 사용자가 페이지 위에서 요소를 움직이고 크기를 조절한 뒤 Apply를 누르면 PDF 바이트에 반영되는 방식입니다. 이미지 요소를 기존 배열에 추가해 드래그 핸들, 크기 조정, 실행 취소, 적용 흐름을 그대로 사용했습니다.

구현 과정에서는 예상하지 못한 문제가 생겼습니다. pdf-lib가 WebP와 AVIF를 PDF에 넣지 못해 캔버스를 거쳐 PNG로 다시 인코딩해야 했습니다. 브라우저 좌표의 왼쪽 위 원점과 PDF 좌표의 왼쪽 아래 원점이 달라 Y 좌표를 뒤집어야 했습니다. 페이지의 가로와 세로 길이가 다른 점도 사이드바의 크기 조절 비율 계산에 반영해야 했습니다. 기능은 글을 올리기 하루 전에 출시됐으며 작성자는 아직 트래픽 수치를 갖고 있지 않다고 밝혔습니다. Google이 새 기능을 제대로 크롤링하는 데 약 일주일, 트래픽 변화가 보이는 데 2~3주가 걸릴 것으로 예상했습니다.

작성자는 SEO 작업이 사이트를 명확하게 설명하는 데는 필요했지만 검색 수요를 만들지는 못한다고 정리합니다. 새 이미지 도구는 "PDF에 로고 넣기", "PDF에 사진 추가하기", "PDF에 도장 넣기" 같은 검색 의도에 맞는 기능을 제공합니다. 다음 기능도 사람들이 실제로 찾는 항목을 기준으로 고르겠다고 했습니다. 도메인은 프로젝트가 완성되기 전에 사지 말고, 이미 도메인을 샀다면 도메인 문자열보다 브랜드명을 일관되게 알리라는 조언도 덧붙였습니다.

Indie Hackers 반응

  • @Biz4group — 공유해 주셔서 감사합니다.
  • @Setasena Randata — Cloudflare Pages 사이트맵 오류는 성가시지만 HTML 사이트맵 대체안을 만드는 데 20분이면 충분합니다. URL Inspection을 하나씩 쓰는 것보다 페이지를 훨씬 빨리 발견하게 해줍니다. 더 큰 성과는 도구가 검색어에 맞아졌다는 점입니다. "PDF에 로고 추가", "PDF에 도장 추가", "PDF에 사진 추가"처럼 의도별 페이지를 만들고 각 페이지 제목과 도구 위에 짧은 사용법을 넣어 보세요. 이런 페이지는 브랜드명 검색보다 먼저 클릭을 얻기도 합니다.
    • @victor_james — HTML 사이트맵은 계속 미루고 있습니다. 페이지가 15개인 동안은 각 페이지가 색인 과정에서 어떻게 움직이는지 확인하는 편이 자동화보다 가치 있습니다. 40개가 되면 대체안을 만들겠습니다. 의도별 페이지 제안은 고민하던 부분입니다. 이미지 도구는 논리상 /pdf-editor/ 안에 있지만 /add-image-to-pdf/를 만들면 별도 검색 순위 기회를 얻는 대신 내용을 복제하거나 얇은 페이지를 만들어야 합니다. 어떻게 처리하셨나요? Google이 두 페이지를 서로 다른 의도로 보나요, 아니면 같은 의도로 합치나요?
    • @Setasena Randata — 의도가 실제로 다르면 Google은 별개 페이지로 봅니다. "PDF에 이미지 추가"와 "PDF 편집"은 서로 다른 검색 결과를 가져옵니다. 페이지가 단순한 포장에 그치지 않고 할 일을 수행해야 합니다. /add-image-to-pdf/에서 편집기를 이미지 모드로 바로 열고 이미지 형식, 배치, 크기 조정, 투명도를 설명하는 짧은 안내를 쓰세요. 해당 용도의 FAQ도 시도해 볼 수 있습니다. 각 페이지는 자기 자신을 canonical로 지정하고 서로 링크하며 /pdf-editor/는 허브로 유지하면 됩니다.
    • @victor_james — "편집기를 이미지 모드로 바로 열기"가 놓친 부분이었습니다. 중복 콘텐츠 문제로만 생각했는데 실제로는 시작 상태가 핵심이군요. 같은 도구라도 진입 경로와 설명이 다르면 해결 방식이 달라지고 비용도 훨씬 적습니다. 자기 자신을 canonical로 지정한다는 건 의도별 페이지와 허브가 각각 별도의 색인 URL이 된다는 뜻인가요? 내부 링크는 순위에 영향을 주지 않도록 의도별 페이지에서 전체 편집기로 연결하나요?
  • @Malik Danish Ali — 제 경험과도 맞습니다. 기능보다 배포와 유통이 더 중요합니다. 판매 첫날인데 직접 연락하는 과정에서 개발보다 더 많은 것을 배우고 있습니다.
    • @victor_james — 멋집니다. 무엇을 판매하시나요? 진행 과정을 지켜보고 싶습니다.
  • @plainbookstudio — 스키마가 사이트를 명확하게 설명하지만 수요를 만들지는 못한다는 점이 유용합니다. Search Console의 검색어 보고서와 "PDF에 이미지 추가" 같은 검색어의 People also ask를 살펴보면 도구 페이지의 H1과 도입부에 어떤 표현을 쓸지 알 수 있습니다. 새 URL은 페이지별 색인 요청이 특히 유용하니 계속해 볼 만합니다.
  • @Bullpicks — 스키마 작업이 효과가 있다고 가정하지 않고 Search Console의 실제 데이터를 확인한 점이 좋습니다. 페이지별 색인 요청은 규모가 커지면 어렵습니다. 도구 10개를 링크한 HTML 페이지를 만들어 푸터에서 연결하면 사이트맵 없이도 Google과 방문자가 페이지를 찾을 경로가 생깁니다. 각 도구 페이지에도 "EXIF 데이터 제거"처럼 작업을 평이한 말로 설명하는 문장을 넣어 보세요.
    • @victor_james — 도구 페이지에 설명 문장을 추가하는 건 간단해서 하겠습니다. 도구 위에 넣는 문단을 말씀하시나요, 메타 제목을 말씀하시나요? 메타 제목은 정리했지만 페이지 안의 문구는 작업 이름보다 기능을 설명하고 있을 수 있습니다. 사이트맵은 페이지가 15개인 지금은 진행 과정을 보려고 일부러 수동으로 처리하고 있습니다. 40개가 되면 대체안을 만들겠습니다.
  • @Tether — 사용자가 하려는 일을 직접 말해주는 것은 키워드 조사보다 낫습니다. 사람들이 검색어를 입력하기도 전에 검색 의도를 알려준 셈입니다. 요청을 묻어 두지 않고 만든 결정이 좋습니다. 이미지 도구를 찾은 사람들이 다른 도구도 쓰기 시작했나요?
    • @victor_james — 다른 도구 사용으로 이어지는지는 아직 말하기 이릅니다. 이미지 도구는 출시된 지 하루 됐습니다. 사이트를 이미 알던 사람이 아니라 새 방문자를 데려오는지 보려 합니다. 그들이 머물며 압축 도구나 메타데이터 제거 도구까지 써보면 답이 됩니다. 이미지 도구만 쓰고 떠난다면 단일 목적 방문입니다. 몇 주 뒤 결과를 공유하겠습니다.
  • @Jhon Nova — 제 FortuneOK도 비슷한 일을 겪었습니다. 검색 엔진이 제품 이름을 "fortune ok"의 오타로 읽어 Fortune magazine과 ONEOK를 보여줬습니다. 제목과 소개, 등록 정보에 "FortuneOK portfolio tracker"처럼 카테고리를 이름과 함께 넣자 브랜드 검색이 해결됐습니다. 트래픽을 움직인 기능은 무엇인가요?
    • @victor_james — FortuneOK라는 이름이 좋네요. 이름과 카테고리를 함께 쓰는 방식은 SORO File Tools에도 적용하고 있습니다. "soro"가 "soro films"가 아니라고 Google에 알리는 중입니다. 트래픽을 움직인 기능은 PDF 편집기에 추가한 이미지 배치 도구입니다. 누군가 댓글로 요청했고 제가 맞추지 못하던 검색 의도가 가장 컸습니다. 포트폴리오 트래커라는 설명이 장기적으로도 효과가 있었나요? 브랜드 검색이 계속 유지됐나요?
  • @adamyusfan — 저도 같은 일을 겪고 있습니다.
    • @victor_james — 세상 참 좁네요. 무엇을 만들고 있나요?
  • @ScsDriver Team — 거의 빼려던 기능이 사용자가 기억하는 기능이 되는 경우가 있습니다. 대개 설정을 하나 더 넣는 일이 아니라 어려운 상황을 처리하는 문제입니다. 저희에게는 기능보다 동작 방식이 중요했습니다. 마운트한 공유 폴더를 디스크처럼 쓰려면 일부 계층이 깨뜨리는 퍼센트 인코딩 파일명, 서버에서 잠긴 파일, 재부팅 뒤에도 유지되는 인증 정보, VPN이 끊긴 뒤 다시 연결되는 마운트 같은 평범하지만 까다로운 경우를 처리해야 합니다. 이런 부분은 시연에서 드러나지 않지만 사용자가 트레이에 계속 띄워둘 도구와 한 번 써보고 마는 도구를 가릅니다. 배포에서도 같은 원리가 적용됩니다. 이미 누군가 묻고 있는 질문에 답하는 이야기를 내놓아야 합니다. 저는 WebDAV와 NAS 공유 폴더를 드라이브 문자로 마운트하는 Windows 도구 ScsDriver를 만들고 있습니다. 평생 라이선스는 한 번에 5.50달러입니다. 눈에 띄지 않는 예외 처리가 기존 사용자를 붙잡고 질문에 맞춘 콘텐츠가 새 사용자를 데려오는 모습을 봤습니다.
    • @victor_james — 잠긴 파일과 VPN 연결 끊김은 시연에 나오지 않는 문제입니다. 모든 제품에 그런 사례가 있고 사용자가 한 번 써보는 도구와 트레이에 계속 두는 도구를 가르는 요소입니다. "질문에 맞춘 콘텐츠"라는 표현도 가져가고 싶습니다. 특정 검색어에 답하는 글을 그대로 구성하라는 뜻인가요, 먼저 질문을 고른 뒤 그 질문에 맞춰 쓰라는 뜻인가요? 이런 접근은 시간이 지나며 효과가 쌓이나요, 아니면 글마다 새로운 질문이 필요한가요?
  • @Muhammad Mustafa — 저도 비슷한 상황입니다. 기술 글 12개를 게시해 노출은 얻었지만 클릭은 거의 없어서 SEO를 더 해야 하나 생각했습니다. 이 사례는 글이 검색어에 관해 이야기하는 데 그치지 않고 검색 의도를 해결해야 한다는 점을 보여줍니다. 유용한 기능 하나를 만드는 편이 글 10개를 더 쓰는 것보다 가치 있어 보입니다. Google은 별도 페이지에서 이 기능을 발견했나요, 아니면 메인 도구에서 발견했나요?
    • @victor_james — 메인 도구 안에 있습니다. PDF 편집기의 리더 바에 있는 탭입니다. Google이 크롤링한 곳도 /pdf-editor/뿐입니다. 전용 랜딩 페이지를 만들지는 고민 중입니다. Setasena의 제안이 위에 있습니다. 별도 페이지라면 자체 순위 기회를 얻겠지만 내용을 재사용해야 합니다. 클릭이 없는 글 12개는 정말 답답하겠네요. 어떤 글을 쓰고 있나요?
  • @Dharani Jayakanthan — "스키마로 명확성을 얻을 수는 있지만 수요를 만들 수는 없다"는 문장만으로도 저장할 가치가 있습니다. 아직 수치가 없을 때 이야기를 공개한 점도 좋습니다. 성공한 것처럼 꾸밀 때까지 기다리지 않았으니까요.
    • @victor_james — 감사합니다. 수치가 나오기 전에 공유하는 편이 제가 쓸 수 있는 유일한 정직한 글이었습니다. 두 달 기다렸다가 잘된 경우에만 맞는 이야기로 다시 엮는 방법도 있겠지만요.

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