인디 웹서비스 SEO 실전 체크리스트 (2026)

출시했는데 검색에는 안 뜨는 이유

인디 메이커의 웹서비스는 출시 당일부터 바쁘습니다. 랜딩을 고치고, 결제 버그를 잡고, 지인에게 링크를 뿌립니다. 그런데 일주일이 지나도 구글·네이버에서 서비스 이름을 쳐야만 자기 사이트가 나옵니다. 기능을 찾는 사람은 경쟁사나 오래된 블로그로 가고, 내 페이지는 존재하지만 검색 결과에 없는 상태가 됩니다.

원인은 대개 콘텐츠가 없어서가 아닙니다. 페이지 목적이 겹치고, 제목과 H1이 다르고, 사이트맵을 제출하지 않았고, 히어로 이미지가 LCP를 밀어 버린 경우가 많습니다. 이 글은 이론 백서가 아니라 혼자 운영하는 Next.js 랜딩·SaaS를 기준으로 한 실전 체크리스트입니다. 키워드 밀도 공식이나 비밀 알고리즘 이야기는 하지 않습니다. 배포 전에 고치고, 배포 후에 제출하고, 매주 30분만 손보는 순서로 갑니다.

광고 없이 사이트를 알리는 다른 채널이 궁금하면 웹사이트 무료로 홍보하는 방법과 함께 읽어도 됩니다. 여기서는 검색에 걸리게 만드는 기초만 좁혀 봅니다.

최적화 전에 정할 두 가지

검색엔진은 페이지를 “이 질문에 답하는 문서”로 읽습니다. 한 장에 가입, 가격, 블로그, 채용, 로드맵을 다 넣으면 어떤 검색어에도 1등이 되기 어렵습니다. 도구를 고르기 전에 이 페이지가 무엇을 끝내는 곳인지를 한 문장으로 적으세요.

페이지마다 목적 하나

랜딩은 “이 도구가 무엇이고, 누가 쓰며, 지금 시작할 수 있다”를 설득하는 페이지입니다. 요금은 /pricing, 도움말은 /docs 또는 /guide, 회사 소개는 /about으로 나눕니다. 같은 문장을 세 곳에 복사해 두면 검색엔진은 어느 URL을 보여줄지 헷갈립니다. 핵심 설명은 한곳에 두고, 나머지는 내부 링크로 보냅니다.

대기 명단만 있는 단계라면 랜딩 한 장이어도 됩니다. 다만 그 한 장의 첫 화면이 기능 나열이 아니라, 사용자가 검색창에 넣을 법한 상황을 말해야 합니다. “AI로 업무를 혁신한다”보다 “회의록을 녹음해서 할 일로 나눈다”가 검색과 가깝습니다.

한국어 대표 검색어 하나

페이지마다 사람들이 실제로 칠 법한 한국어 구절 하나를 고릅니다. 도구 이름만 적으면 브랜드를 이미 아는 사람만 옵니다. 반대로 유행어를 다섯 개 욱여넣으면 제목이 이상해지고 클릭도 줄어듭니다.

고르는 방법은 단순합니다. 지인에게 “우리 사이트 뭐 하는 곳이냐”고 물었을 때 나오는 말, 네이버·구글 자동완성에 뜨는 말, 커뮤니티에서 같은 문제를 물을 때 쓰는 말을 모읍니다. 예시는 이렇습니다.

파일 변환 도구 → pdf 이미지 변환, 한글 파일 합치기
개인 SaaS 랜딩 → 팀 할일 관리 웹앱, 견적서 자동 작성
개발자 유틸 → json 포맷터, 정규식 테스트

대표 구절은 제목·H1·첫 문단에 한 번씩만 자연스럽게 넣습니다. 같은 단어를 문장마다 반복하는 건 최적화가 아니라 읽기 방해입니다. 영문 키워드가 필요하면 별도 영문 페이지를 두거나, 본문에서 한 번 병기하는 정도로 충분합니다.

페이지에서 먼저 맞출 것

온페이지 SEO는 거창한 플러그인이 아니라, 검색 결과 카드와 브라우저 탭에 보이는 정보를 맞추는 일입니다. Next.js App Router에서는 metadata 객체나 generateMetadata로 이 값을 내보냅니다. 페이지 컴포넌트 JSX만 고치고 <head>를 비워 두면, 예쁜 화면과 빈 검색 스니펫이 따로 놉니다.

제목과 메타 설명

title: 50자 안팎. 앞에 대표 검색어, 뒤에 서비스 구분. 탭에 잘리고 검색에도 잘리는 긴 수식어는 뺍니다.
description: 80~120자. 무엇을 할 수 있는지, 누구를 위한 것인지, 무료/가입 조건을 한 줄에 넣습니다. 키워드 나열이 아니라 클릭할 이유를 쓰는 문장입니다.
브랜드명만 반복하지 마세요. “○○ — 최고의 올인원 솔루션”은 검색 결과에서 비슷해 보입니다.

정적 페이지는 export const metadata로 두고, 슬러그나 상품 ID가 있는 페이지는 generateMetadata에서 title·description을 만듭니다. metadataBase를 사이트 도메인으로 잡아 두면 상대 경로 OG 이미지도 절대 URL로 풀립니다.

H1, 슬러그, 정규 URL

화면에 보이는 H1은 검색 제목과 같은 주제를 말하되, 글자 하나까지 복붙할 필요는 없습니다. 제목이 “인디 웹서비스 SEO 실전 체크리스트 (2026)”이면 H1은 그 약속을 유지하면 됩니다. 히어로에는 영어 슬로건, 본문 H1에는 다른 한국어를 넣는 구성은 피하세요.

슬러그는 짧고 읽히게 둡니다. indie-web-seo-checklist-2026처럼 주제가 보이고, 연도를 넣으면 같은 주제의 글과 URL이 겹칠 일도 줄어듭니다. 한글 슬러그도 동작하지만, 공유·로그·리다이렉트에서 인코딩이 섞이기 쉬워 영문 케밥이 실무에서 덜 아픕니다.

같은 내용이 /, /home, /index에 동시에 열려 있으면 힘이 갈라집니다. 대표 주소를 canonical로 명시합니다. Next.js Metadata API의 alternates.canonical이 그 역할입니다. HTTP→HTTPS, www→루트처럼 한쪽으로만 301을 걸어 두는 것도 같은 일의 연장입니다.

OG 이미지

링크를 카톡·슬랙에 붙였을 때 카드가 깨지면, 검색 이전의 공유부터 끊깁니다. openGraph와 Twitter 카드에 이미지 URL, 제목, 설명을 넣습니다. 이미지는 1200×630 전후가 무난하고, 텍스트가 있으면 가장자리에서 잘리지 않게 여백을 둡니다. 기본 로고만 가운데 둔 회색 카드는 피드에서 건너뛰어집니다.

페이지마다 다른 OG를 만들기 부담되면, 카테고리별 템플릿 한 장과 글 제목만 바꿔도 충분합니다. 로컬 파일은 app/opengraph-image 또는 public 경로로 두고, 코드에 없는 URL을 지어 내지 마세요.

Next.js App Router에서 빠지기 쉬운 구멍

클라이언트 컴포넌트에만 제목이 있다. use client 파일은 메타데이터를 내보낼 수 없습니다. 제목은 서버 페이지나 레이아웃에서 정합니다.
레이아웃 title 템플릿이 길다. %s | 브랜드는 좋지만, 브랜드가 이미 title에 들어 있으면 두 번 붙습니다.
미리보기·스테이징이 색인된다. robots: { index: false } 또는 프리뷰 도메인 noindex를 걸지 않으면, 미완성 문구가 검색에 남을 수 있습니다.
로그인·계정·콜백 페이지가 열린다. 색인할 이유가 없는 경로는 처음부터 noindex입니다.

여기까지가 “페이지가 무엇에 대한 문서인지”를 검색엔진과 공유 카드에 알려 주는 최소 세트입니다.

기술적으로 막히면 콘텐츠가 안 보인다

메타를 잘 써도 크롤러가 못 들어오거나, 첫 화면이 3초에 그려지지 않으면 순위 이야기 전에 이탈이 납니다. 인디 서비스에서 자주 빠지는 네 가지입니다.

sitemap.xml과 robots.txt

사이트맵은 검색엔진에게 공개해도 되는 URL 목록을 주는 파일입니다. Next.js App Router에서는 app/sitemap.ts가 /sitemap.xml로 내려가는 방식이 흔합니다. 랜딩, 요금, 가이드, 블로그 글처럼 사람이 읽어야 하는 주소만 넣고, 검색 결과·필터 쿼리·미리보기 URL은 빼세요. lastModified는 실제로 고친 날짜에 가깝게 둡니다.

robots.txt는 반대로 가지 말 곳을 적습니다. /api, 관리자, 초안, 내부 검색 페이지를 막고, 사이트맵 위치를 한 줄로 가리킵니다. Disallow: /를 프로덕션에 남겨 두는 실수는 의외로 많습니다. 배포 직후 브라우저에서 /robots.txt와 /sitemap.xml을 직접 열어 보세요.

HTTPS와 이동

인증서가 만료되거나, 일부 이미지만 HTTP이면 브라우저가 Mixed Content로 막고 크롤러도 멈칫합니다. 커스텀 도메인을 붙인 뒤 한 호스트만 살아 있게 합니다. Vercel·Cloudflare 앞에서 www와 apex가 둘 다 200을 주면, 검색 입장에서는 사이트가 두 개입니다.

속도와 LCP

Core Web Vitals 가운데 랜딩이 가장 자주 깎이는 값은 LCP(Largest Contentful Paint) 입니다. 히어로 이미지, 큰 제목, 자동재생 배경이 그 주인공이 됩니다. 혼자 만든 사이트에서 흔한 원인은 세 가지입니다.

스크립트 무게: 채팅 위젯, 분석, 폰트 로더, A/B 도구를 첫 페인트 전에 전부 불러옵니다. 꼭 필요한 스크립트만 남기고, 나머지는 늦게 로드합니다.
이미지: next/image로 포맷·크기를 맞추고, 히어로에는 priority를 줍니다. 4K PNG를 CSS로만 줄이면 모바일은 그대로 받습니다.
폰트와 애니메이션: 웹폰트 다섯 개, 히어로 영상, 스크롤 라이브러리를 동시에 켜면 텍스트보다 장식이 먼저 예산이 됩니다.

모바일에서 한 번 더 봅니다. 한국 트래픽의 상당수는 폰입니다. 버튼이 엄지 밖에 있거나, 가로 스크롤이 생기거나, 팝업이 본문을 가리면 검색 점수가 아니라 사용 기록이 먼저 나빠집니다. PageSpeed Insights 숫자보다, 자기 폰의 LTE에서 첫 화면이 보이는 속도가 정직합니다.

렌더링이 비는 순간

본문이 클라이언트에서만 그려지면, 크롤러가 빈 셸을 가져갈 수 있습니다. 마케팅 카피·요금·가이드는 서버에서 HTML로 나오게 두는 편이 안전합니다. 로그인 뒤에만 있는 기능은 검색 대상이 아닙니다. “앱이 있다”는 사실은 공개 랜딩에 문장으로 적으세요.

한국어 검색에서만 생기는 일

한국 사용자는 구글만 쓰지 않습니다. 같은 쿼리라도 네이버와 구글의 결과 구성이 다르고, 블로그·카페·지식iN 카드가 웹사이트보다 위에 올라오는 일도 흔합니다. 영어권 가이드를 그대로 옮기면 “구글 Search Console만 연동했다”에서 끝납니다.

네이버와 구글을 같이 본다

구글은 페이지의 제목·본문·링크·속도를 비교적 직접 봅니다. 네이버는 사이트 등록·웹 마스터 도구(서치어드바이저) 인증, 수집 상태, 그리고 블로그·카페 생태계의 비중이 큽니다. 둘 다에서 브랜드명이 다르게 적히면, 사용자는 두 개의 회사로 느낍니다.

실무에서는 이렇게 나눕니다.

구글: Search Console 소유권 확인, 사이트맵 제출, 색인 요청, 모바일 사용성.
네이버: 서치어드바이저에서 사이트 등록·수집, 사이트맵·RSS(블로그가 있다면), robots 상태.
둘 다: 사이트 이름, 로고, 대표 URL, 파비콘을 같게 유지.

네이버 검색 광고나 쇼핑 특화 영역까지 욕심낼 필요는 없습니다. 웹서비스 랜딩이라면 수집이 되고, 사이트 이름이 맞게 나오며, 대표 페이지가 에러가 아닌 것이 1차 목표입니다.

질문에 답하는 글이 랜딩을 돕는다

도구 페이지만으로는 “방법”, “차이”, “무료로 하는 법” 같은 쿼리를 받기 어렵습니다. 짧은 가이드 한 편이 랜딩보다 먼저 트래픽을 받는 일이 흔합니다. 글은 제품 광고가 아니라 그 문제를 끝까지 설명하는 문서여야 합니다. 마지막에 도구로 이어 주는 링크 하나면 충분합니다.

브랜드 표기는 처음부터 하나로 고정합니다. 한글 이름, 영문 이름, 도메인이 글마다 바뀌면 검색 연결과 입소문이 둘 다 느려집니다. 약관·푸터·OG 사이트 이름·앱 이름까지 같은 철자를 쓰세요.

커뮤니티에 남기는 한 줄 소개도 같은 이름을 씁니다. 검색 사용자가 글에서 본 이름과 사이트 탭 이름이 같아야 “찾은 것”이 됩니다.

배포 다음 주에 할 일

코드를 올렸다고 색인이 끝나지 않습니다. 검색엔진은 초대받지 않으면 늦게 오거나, 오지 않습니다.

소유권 확인과 사이트맵 제출

Google Search Console과 네이버 서치어드바이저에서 도메인 또는 URL 접두어로 소유권을 확인합니다. HTML 태그, DNS TXT, 호스팅 파일 중 이미 쓰고 있는 스택에 맞는 방법 하나만 하면 됩니다. 확인이 끝나면 사이트맵 URL을 제출하고, 며칠 뒤 수집·노출 오류를 봅니다.

한 페이지를 급히 보여주고 싶을 때만 개별 URL 검사를 씁니다. 전체 사이트를 매일 재요청하는 건 효과가 없고, 할당만 씁니다.

내부 링크와 디렉토리

블로그·가이드에서 랜딩·요금·관련 글로 링크를 겁니다. 사이드바 자동 나열보다, 본문에서 “이어서 볼 페이지”를 한두 개 고르는 편이 클릭도 자연스럽습니다. 고아 페이지(어디서도 연결되지 않은 URL)는 사이트맵에만 있고 사람이 못 가는 주소가 됩니다.

검색 외의 발견 경로는 무료 홍보와 겹칩니다. Product Hunt, 국내 커뮤니티, 그리고 웹서비스 디렉토리에 등록하는 일은 백링크와 초기 방문을 같이 줍니다. 오픈웹사이드도 그 채널 중 하나입니다. 카테고리에 맞춰 한 줄 소개를 정확히 적고, 다른 디렉토리에도 같은 이름·같은 URL을 쓰면 됩니다. 등록만으로 순위가 오르지는 않지만, 검색이 붙기 전에 사람이 들어오는 구멍을 하나 여는 셈입니다.

측정은 나중에, 간단하게

색인이 된 뒤에야 방문자 경로가 의미 있습니다. 무료 구간이 있는 분석 도구를 하나 고르고, 쿠키 동의와 스크립트 무게를 같이 봅니다. 처음에는 검색 노출, 클릭, 랜딩 이탈 세 숫자면 충분합니다. 대시보드를 늘리는 일보다, 노출은 있는데 클릭이 없는 제목을 고치는 일이 먼저입니다.

매주 30분짜리 습관

SEO는 출시 전 체크리스트로 끝나지 않습니다. 혼자 만드는 서비스는 한 주를 통째로 바칠 수 없으니, 짧은 루틴이 더 잘 남습니다.

깨진 페이지 하나: 404, 만료된 OG, 죽은 내부 링크, noindex가 남은 공개 URL. Search Console의 페이지 경험을 훑고 하나만 고칩니다.
가이드 한 줄 이상: 요금이 바뀌었거나 기능 이름이 바뀌었으면 검색으로 들어오는 글을 같이 고칩니다. 낡은 문장은 순위를 지키기보다 신뢰를 깎습니다.
노출 숫자 확인: 대표 검색어의 노출이 생겼는지, 브랜드명 오탈자로 들어오지는 않는지. 클릭이 없는데 노출만 많으면 제목·설명을 다시 씁니다.

30분은 완벽한 점검이 목표가 아닙니다. 배포 직후 놓친 한 장을 매주 거두는 리듬입니다. 한 달이 지나면 사이트맵·속도·문구가 조금씩 같이 나아집니다.

정리

인디 웹서비스가 검색에서 안 보이는 이유는 보통 콘텐츠 부족이 아니라, 목적이 겹친 페이지, 비어 있는 메타, 제출되지 않은 사이트맵, 무거운 첫 화면, 한국어 검색 채널을 한쪽만 본 배포입니다. 페이지마다 대표 한국어 구절 하나를 정하고, title·description·H1·canonical·OG를 맞춘 뒤, 사이트맵과 서치 콘솔을 제출하세요. 그다음 주에는 깨진 주소 하나와 가이드 한 편만 손보면 됩니다.

비즈니스 도구와 가벼운 유틸을 더 둘러보고 싶다면 비즈니스·생산성과 유틸리티 목록에서 비슷한 웹서비스를 이어서 볼 수 있습니다. 검색은 한 번의 출시가 아니라, 페이지가 질문에 답하고 있다는 신호를 꾸준히 유지하는 일입니다.