앱 정보 사이트와 SEO 고민들
앱 정보 사이트를 만들면서 정리한 SEO 고민들
웹 서비스를 만들다 보면 SEO는 늘 “나중에 하자”로 밀리기 쉽다.
특히 기능 개발이 먼저인 초기 단계에서는 더 그렇다. 나도 앱 정보 사이트를 만들기 전까지는 SEO를 메타 태그 몇 개 넣는 일 정도로 가볍게 생각한 적이 있었다. 그런데 실제로 서비스를 운영하려고 보니, SEO는 검색 유입만의 문제가 아니었다. 서비스가 어떤 문제를 풀고 있는지, 검색엔진과 사용자에게 얼마나 일관되게 설명하고 있는지의 문제에 더 가까웠다.
이번 글에서는 앱 정보 사이트를 만들면서 실제로 고민했던 SEO 포인트들을 정리해보려고 한다. 거창한 성장 해킹 이야기는 아니고, 작은 서비스라도 처음부터 챙기면 좋은 기본기 위주의 이야기다.
1. SEO는 “검색엔진용 문장”이 아니라 “서비스 설명 방식”에 가깝다
처음에는 “시니어 인지 훈련”, “두뇌 훈련 앱”, “시니어 맞춤 앱” 같은 키워드를 어디에 몇 번 넣을지가 더 중요하다고 생각했다.
그런데 조금만 더 들여다보니, 요즘 검색엔진은 단순히 특정 단어가 많이 들어간 페이지보다 문맥이 자연스럽고, 페이지의 목적이 분명한 쪽을 더 잘 이해하려고 한다.
앱 정보 사이트를 만들면서 가장 먼저 정리한 것은 “이 페이지가 정확히 무엇을 소개하는가”였다.
- 시니어를 위한 인지 훈련 서비스인지
- 어떤 방식으로 사용하는지
- 왜 일반적인 앱보다 더 쉽게 느껴지는지
- 누구에게 도움이 되는지
이런 내용이 자연스럽게 들어가야 검색엔진도 페이지를 이해하고, 사용자도 오래 머문다.
결국 SEO는 키워드 나열보다 “페이지의 자기소개를 얼마나 정확히 하느냐”에 더 가까웠다.
2. canonical은 생각보다 중요했다
처음에는 canonical을 크게 의식하지 않았다.
그런데 홈, 소개 페이지, 외부 앱 링크, 서브도메인 구조가 같이 있다 보니 “어떤 URL이 대표 URL인지”를 명확하게 알려주는 게 꽤 중요했다.
예를 들어 홈은 홈대로, 소개 페이지는 소개 페이지대로 각자 자기 canonical을 가져야 한다.
이게 정리되지 않으면 어떤 페이지는 검색엔진이 독립 문서로 보기 어렵고, 경우에 따라서는 홈과 소개 페이지의 신호가 섞여버릴 수 있다.
특히 서비스 초기에는 페이지 수가 많지 않기 때문에, 각 문서가 자기 역할을 분명히 갖는 것이 더 중요하다.
한 페이지는 브랜드와 서비스 전체를 설명하고, 다른 페이지는 팀의 배경과 방향성을 설명해야 한다.
이 구분이 콘텐츠 구조 측면에서도 중요하지만, SEO 측면에서도 꽤 큰 차이를 만든다.
3. OG와 Twitter 메타는 SEO만이 아니라 “첫인상”이었다
검색엔진만 생각하면 title, description 정도만 챙기기 쉽다.
하지만 실제 서비스는 링크로 더 많이 퍼진다. 카카오톡, 슬랙, 노션, 디스코드, 문자, 메신저 등에서 링크가 공유될 때 썸네일과 설명이 어떻게 보이느냐가 꽤 중요하다.
그래서 앱 정보 사이트를 만들면서 Open Graph와 Twitter 메타도 페이지별로 나누는 쪽으로 정리했다.
- 홈에서는 서비스의 전체 인상
- 소개 페이지에서는 팀의 배경과 방향성
- 각 페이지에 맞는 제목과 설명
- 공유했을 때 무난하고 신뢰감 있는 OG 이미지
이 부분은 SEO처럼 보이지만 사실 브랜드 경험에도 가깝다.
검색 결과에서 보이는 제목 하나, 공유 카드에 보이는 설명 한 줄이 서비스의 결을 만들기 때문이다.
4. FAQ는 생각보다 좋은 진입점이었다
FAQ는 흔히 고객센터용 콘텐츠라고 생각하기 쉽다.
그런데 실제로는 검색 의도를 가장 자연스럽게 담아낼 수 있는 영역이었다.
예를 들면 이런 질문들이다.
- 두뇌 산책은 어떤 분들에게 잘 맞나요?
- 두뇌 훈련은 어떤 방식으로 이어가는 것이 좋을까요?
- 시니어가 사용하기 쉬운 앱은 어떤 특징이 있나요?
이런 질문은 사용자가 실제로 검색창에 입력할 법한 문장과 꽤 비슷하다.
예전처럼 어색하게 키워드를 몰아넣지 않아도, 질문 자체가 검색 의도를 담고 있으면 충분히 의미가 있다.
여기에 FAQ 구조화 데이터까지 더하면 검색엔진이 페이지를 이해하는 데 도움이 된다.
중요한 건 FAQ를 억지로 늘리는 것이 아니라, 실제 서비스 사용 맥락에서 나올 법한 질문을 정리하는 것이다.
AI 검색 결과가 늘어나는 지금은 더더욱 이런 자연어 기반의 FAQ가 중요해졌다고 느꼈다.
5. robots.txt와 sitemap은 “기본값이면 되겠지” 하면 놓치기 쉽다
서비스를 만들다 보면 정작 robots.txt, sitemap, 리디렉션 같은 기본 구성을 뒤로 미루게 된다.
하지만 이건 초기에 한번만 제대로 잡아도 꽤 오래 든든한 영역이다.
이번 작업을 하면서 다음 세 가지를 가장 기본값으로 봤다.
- 검색엔진이 크롤링 가능한지
- sitemap이 정상적으로 열리는지
- canonical과 실제 배포 URL이 서로 일치하는지
이건 기술적으로 어렵지 않지만, 조금만 꼬여도 인덱싱 신호가 애매해질 수 있다.
특히 정적 사이트나 서브도메인이 섞인 구조에서는 더 그렇다.
6. “키워드 최적화”보다 “사용자 언어”가 더 오래 간다
초반에는 제목이나 설명 문구를 만들 때도 검색어 느낌을 많이 의식했다.
그런데 결국 남는 문장은 너무 광고 같지 않으면서도, 실제 사용자가 이해할 수 있는 문장이었다.
예를 들어 “시니어 인지 훈련 솔루션” 같은 표현보다
“시니어를 위한 인지 훈련 앱”,
“하루 5분 정도로 부담 없이 시작할 수 있는 서비스” 같은 문장이 더 자연스럽고 오래 간다.
AI 검색이나 요약 결과를 생각해도 마찬가지다.
문장이 부자연스럽고 키워드만 많으면 오히려 신뢰감이 떨어진다.
반대로 서비스 목적, 대상, 사용 방식이 자연스럽게 드러나는 문장은 검색엔진도 이해하기 쉽고 사용자도 읽기 편하다.
7. 작은 서비스일수록 “과한 SEO”보다 “정직한 구조”가 낫다
앱 정보 사이트를 만들면서 가장 크게 느낀 건, 작은 서비스일수록 거창한 SEO 전략보다 정직한 구조가 중요하다는 점이었다.
- 페이지마다 역할이 분명한가
- 제목과 설명이 각 페이지에 맞게 분리되어 있는가
- 공유 시 첫인상이 괜찮은가
- FAQ나 구조화 데이터가 실제 내용과 맞는가
- 검색엔진이 URL 구조를 헷갈리지 않는가
이런 기본기가 먼저다.
특히 시니어 대상 서비스는 신뢰감이 중요하기 때문에, 과장된 문구보다 차분하고 정확한 설명이 훨씬 잘 맞는다.
마무리
SEO를 하다 보면 자꾸 “검색엔진이 좋아할 문장”을 만들고 싶어진다.
그런데 앱 정보 사이트를 만들면서 오히려 반대로 생각하게 됐다.
검색엔진을 설득하려면 먼저 사용자에게 자연스럽게 설명할 수 있어야 한다는 것이다.
결국 좋은 SEO는 기술적 설정과 콘텐츠 구조가 함께 맞아떨어질 때 나온다.
canonical, OG, sitemap, 구조화 데이터 같은 기본 기술은 반드시 챙겨야 하고, 그 위에 올라가는 문장은 서비스가 실제로 무엇인지 담백하게 설명해야 한다.
아직도 더 다듬을 부분은 많지만, 적어도 지금은 “검색을 위한 페이지”보다 “잘 설명된 서비스 페이지”에 가까워졌다고 느낀다.
혹시 시니어 대상 인지 훈련 서비스가 실제로 어떤 톤과 구조로 보이는지 궁금하다면, 운영 중인 화면을 가볍게 참고해보는 것도 도움이 된다. 너무 과하지 않게 정리된 웹 경험이 어떤 느낌인지 보는 용도로는 https://apps.project-sf.com/ko/ 같은 사례가 꽤 유용했다.