블로그에 좋은 글을 작성했다고 바로 Google 검색에 나타나는 것은 아니다.
검색엔진이 먼저 URL을 발견해야 하고, 페이지를 읽을 수 있어야 하며, 무엇을 설명하는 글인지 이해해야 한다. 그다음에야 사용자의 검색과 연결될 수 있다.
결국 블로그 SEO에서 확인할 것은 크게 두 가지다.
검색엔진이 페이지를 제대로 찾고 이해할 수 있는가? + 검색한 사람이 원하는 답을 제공하고 있는가?
SEO는 검색엔진을 속여 순위를 올리는 기술이라기보다 좋은 글을 검색엔진도 제대로 발견하고 이해할 수 있게 만드는 작업에 가깝다.
검색엔진이 내 블로그를 찾게 만든다
먼저 검색엔진이 사이트에 어떤 페이지가 있는지 알고 접근할 수 있어야 한다.
1. sitemap.xml
sitemap.xml은 검색엔진에게 사이트에 어떤 URL이 있는지 알려주는 파일이다.
<url>
<loc>https://example.com/blog/room-ksp/</loc>
</url>
특히 새로 만든 사이트처럼 외부 링크가 많지 않다면 Google이 페이지를 발견하는 데 도움을 줄 수 있다.
다만 사이트맵에 URL을 넣었다고 색인이 보장되는 것은 아니다.
sitemap.xml
→ URL 발견을 도움
→ Google이 크롤링
→ 색인 여부 판단
Google 역시 사이트맵 제출은 URL 발견을 돕지만 크롤링이나 색인을 보장하지 않는다고 설명한다.
2. robots.txt
robots.txt는 검색엔진 크롤러가 사이트의 어떤 URL에 접근할 수 있는지 정한다.
User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml
관리 페이지처럼 크롤링할 필요가 없는 경로는 제한 할 수도 있다.
User-agent: *
Disallow: /admin/
여기서 중요한 것은 robots.txt와 noindex를 구분하는 것이다.
robots.txt → 크롤링 제어
noindex → 색인 제외
검색결과에서 페이지를 제외하려고 robots.txt만 사용하는 것은 목적에 맞지 않는다.
검색엔진이 페이지를 이해하게 만든다
페이지를 발견한 다음에는 어떤 내용을 가진 페이지인지, 어떤 URL을 대표 주소로 봐야 하는지 이해할 수 있어야 한다.
1. title
<title>에는 페이지의 내용을 가장 잘 설명하는 제목을 사용한다.
<title>Room을 쓰는데 왜 KSP까지 필요한 걸까?</title>
다음처럼 키워드를 나열할 필요는 없다.
Room KSP Room Compiler Kotlin Android 사용법
Google도 구체적이고 간결한 페이지 제목을 권장한다.
다만 <title>에 작성한 문장이 검색결과 제목으로 항상 그대로 표시되는 것은 아니다. Google은 본문의 주요 제목이나 다른 페이지 정보도 함께 참고한다.
2. meta description
meta description은 페이지 전체의 내용을 짧게 설명한다.
<meta
name="description"
content="Room Compiler와 KSP의 관계를 DAO 구현 코드 생성 과정으로 설명합니다."
>
다만 검색결과에 이 문장이 반드시 그대로 표시되는 것은 아니다.
Google은 검색어와 본문을 바탕으로 snippet을 만들고, 필요한 경우 meta description을 참고한다.
따라서 블로그에서는 역할을 이렇게 나누면 된다.
title → 어떤 글인지 보여준다
subtitle → 제목에서 생략한 범위를 설명한다
description → 글 전체를 짧게 요약한다
3. canonical
같은 콘텐츠가 여러 URL로 접근될 수 있다.
/blog/room-ksp/
/blog/room-ksp/?utm_source=github
이럴 때 대표 URL을 알려주는 것이 canonical이다.
<link
rel="canonical"
href="https://example.com/blog/room-ksp/"
>
Google은 중복되거나 매우 비슷한 페이지 중 대표 URL을 선택한다. rel="canonical"은 어떤 URL을 선호하는지 알려주는 강한 신호지만, Google이 반드시 해당 URL을 선택해야 하는 명령은 아니다.
가능하면 canonical, 내부 링크, sitemap 모두 같은 대표 URL을 바라보게 만드는 것이 좋다.
4. Open Graph
Open Graph는 카카오톡, Slack, Discord 같은 곳에 링크를 공유했을 때 나타나는 미리보기를 설정한다.
<meta property="og:title" content="Room을 쓰는데 왜 KSP까지 필요한 걸까?">
<meta property="og:description" content="Room Compiler와 KSP의 관계">
<meta property="og:image" content="/images/room-ksp.webp">
역할은 간단히 구분할 수 있다.
meta description
→ 검색결과 설명 생성에 참고
Open Graph
→ 링크 공유 미리보기
SEO와 함께 설정해두면 좋지만, 검색 순위를 올리기 위한 별도의 태그라고 볼 필요는 없다.
페이지가 불필요하게 느려지지 않게 한다
기술 블로그는 이미지, 코드 하이라이팅, JavaScript, 웹폰트 때문에 생각보다 쉽게 무거워진다.
성능 역시 사용자 경험의 일부다. Google은 현재 Core Web Vitals를 검색 시스템에서 사용하는 여러 페이지 경험 요소 중 하나라고 설명한다. 다만 좋은 점수를 받는다고 상위 노출이 보장되는 것은 아니다.
1. 이미지 최적화
5MB짜리 이미지를 화면에서 800px로 보여준다면 원본 그대로 내려줄 필요는 없다.
이미지는 필요한 크기로 줄이고 WebP나 AVIF 같은 포맷을 고려한다.
<img
src="/images/room-flow.webp"
width="800"
height="500"
alt="Room에서 SQLite까지 데이터가 전달되는 흐름"
>
화면 아래쪽의 이미지는 lazy loading을 사용할 수 있다.
<img src="/images/example.webp" loading="lazy" alt="...">
반대로 첫 화면에서 바로 보여야 하는 중요한 이미지까지 무조건 lazy loading하면 초기 표시가 늦어질 수 있다.
alt 역시 키워드 입력란이 아니다.
나쁜 예
Room KSP Android Kotlin SEO
좋은 예
KSP를 통해 Room Compiler가 DAO 구현 코드를 생성하는 흐름
이미지가 무엇을 설명하는지 자연스럽게 작성하면 된다.
2. CSS/JS 최적화
이미지만 줄여서는 부족하다.
CSS가 지나치게 크거나 초기 화면에 필요하지 않은 JavaScript가 HTML 렌더링을 막으면 페이지 표시가 늦어질 수 있다.
초기 실행이 필요하지 않은 JavaScript라면 defer나 async를 고려할 수 있다.
<script src="/assets/app.js" defer></script>
차이는 간단하다.
defer
→ HTML 파싱 후 실행
→ 실행 순서 유지
async
→ 다운로드 완료 즉시 실행
→ 실행 순서 보장 안 됨
CSS 역시 실제 사용하지 않는 스타일이 많이 포함되어 있다면 빌드 과정에서 제거하는 편이 좋다.
사용하지 않는 CSS 제거
불필요한 JavaScript 제거
CSS / JS 압축
초기 화면에 필요 없는 코드 지연
웹폰트를 사용한다면 불필요한 굵기를 전부 내려받지 않고 실제 사용하는 파일만 제공하는 편이 낫다.
@font-face {
font-family: "BlogFont";
src: url("/fonts/blog-font.woff2") format("woff2");
font-display: swap;
}
font-display: swap을 사용하면 웹폰트가 로딩되는 동안 대체 폰트로 먼저 텍스트를 보여줄 수 있다. 다만 실제 웹폰트와 대체 폰트의 크기가 크게 다르면 글자가 바뀌면서 화면이 움직일 수 있다.
3. Core Web Vitals
현재 Core Web Vitals는 다음 세 가지다.
| 지표 | 의미 | 권장 기준 |
|---|---|---|
| LCP | 주요 콘텐츠 표시 속도 | 2.5초 이하 |
| INP | 사용자 입력 반응 속도 | 200ms 이하 |
| CLS | 화면의 시각적 안정성 | 0.1 이하 |
과거 글에서 많이 보이는 FID는 현재 INP로 대체됐다.
성능은 PageSpeed Insights나 Chrome DevTools, Search Console의 Core Web Vitals 보고서에서 확인할 수 있다.
목표는 100점을 만드는 것이 아니라 실제로 사용자를 불편하게 만드는 병목을 찾는 것이다.
글 자체도 검색하기 쉽게 작성한다
시스템 설정이 끝났다면 결국 남는 것은 콘텐츠다.
1. 한 글은 하나의 질문에 집중한다
Room과 관련 있다고 다음 내용을 모두 한 글에 넣을 필요는 없다.
Room
SQLite
DAO
KSP
Migration
Flow
Paging
대신 하나의 질문을 잡는다.
Room을 쓰는데 왜 KSP가 필요한가?
그러면 DAO, Room Compiler, KSP처럼 그 질문을 설명하는 데 필요한 내용만 남길 수 있다.
검색엔진보다 먼저 독자가 이 글에서 어떤 답을 얻는지 명확해야 한다.
2. Heading은 찾기 쉽게 만든다
목차를 기술 용어만 나열하면 글의 흐름이 보이지 않는다.
## SEO
## Sitemap
## Robots
## Canonical
반대로 모든 Heading을 긴 질문으로 만들면 나중에 필요한 정보를 다시 찾기 어렵다.
그래서 큰 Heading과 작은 Heading의 역할을 나눈다.
## 검색엔진이 페이지를 이해하게 만든다
### title
### meta description
### canonical
##는 글의 흐름을 보여주고, ###는 필요한 기술을 다시 찾기 쉽게 만든다.
3. 내부 링크
관련 글이 있다면 내부 링크로 연결한다.
SQLite가 있는데 왜 Room을 사용할까?
↓
Room을 쓰는데 왜 KSP가 필요할까?
↓
Room Migration은 언제 필요한가?
링크 텍스트도 자세히 보기보다 실제 목적지를 알 수 있도록 작성한다.
자세히 보기 X
Room Migration이 필요한 이유 O
다만 관련 글이라고 무조건 연결할 필요는 없다.
현재 글을 읽은 사람이 다음에 실제로 궁금해할 내용만 연결하면 된다.
SEO 때문에 굳이 할 필요 없는 것들
SEO를 검색하다 보면 공식처럼 알려진 규칙이 많다.
키워드를 반드시 3~5번 넣기
키워드 밀도를 몇 %로 맞추기
모든 H2에 핵심 키워드 넣기
글을 반드시 몇 천 자 이상 작성하기
이런 숫자를 맞추는 것을 목표로 글을 작성할 필요는 없다.
검색할 만한 표현이 제목과 본문에 자연스럽게 등장하고, 글이 실제 질문에 충분히 답하면 된다.
글자 수도 마찬가지다. 3,000자로 충분한 설명을 SEO 때문에 8,000자로 늘리면 오히려 읽기 어려워진다.
글의 길이는 SEO 목표가 아니라 필요한 설명을 끝낸 결과여야 한다.
글을 발행한 뒤 실제 결과를 확인한다
마지막으로 Google이 실제 페이지를 어떻게 처리했는지 확인해야 한다.
Google Search Console에서는 다음을 확인할 수 있다.
페이지가 색인됐는가?
어떤 검색어에서 노출되는가?
얼마나 노출되는가?
얼마나 클릭되는가?
검색 노출이 없다면 순서대로 확인하면 된다.
Google이 URL을 발견했는가?
↓
색인됐는가?
↓
페이지 주제가 명확한가?
↓
검색한 사람의 질문에 답하고 있는가?
색인도 되지 않은 상태에서 제목만 계속 수정해봐야 해결되지 않는다.
Search Console에 사이트를 등록하고 sitemap을 제출해 실제 색인을 확인하는 과정은 다음 글에서 따로 다룬다.
내부 링크 추천: 사이트 색인 생성과 Google Search Console 등록하기
결국 SEO는 좋은 글을 제대로 전달하는 과정이다
기술 블로그에서 챙겨야 할 SEO를 정리하면 다음 정도다.
| 항목 | 역할 |
|---|---|
| sitemap.xml | URL 발견을 돕는다 |
| robots.txt | 크롤링 범위를 정한다 |
| canonical | 대표 URL을 알려준다 |
| title / description | 페이지 내용을 설명한다 |
| 이미지 | 불필요한 로딩 비용을 줄인다 |
| CSS / JS | 렌더링 지연을 줄인다 |
| Core Web Vitals | 실제 페이지 경험을 확인한다 |
| Heading | 글의 구조를 보여준다 |
| 내부 링크 | 관련 글을 연결한다 |
| 콘텐츠 | 검색한 사람의 질문에 답한다 |
결국 가장 중요한 것은 콘텐츠다.
그렇다고 시스템 SEO가 필요 없다는 뜻도 아니다. 좋은 글을 써도 검색엔진이 발견하거나 이해하지 못하면 필요한 사람에게 전달되기 어렵다.
SEO는 검색엔진을 위한 별도의 글쓰기가 아니다. 좋은 글을 만들고, 검색엔진도 그 글을 제대로 찾고 이해할 수 있도록 정리하는 과정이다.
