사이트의 역할을 먼저 정하기
개인 웹사이트를 만들 때 가장 먼저 할 일은 도메인 구매가 아니라 사이트의 역할을 한 문장으로 정하는 것입니다. 예를 들어 “개인 기록 저장소”와 “검색 방문자를 위한 정보 사이트”는 같은 블로그 형태라도 필요한 글 구조와 메뉴가 달라집니다.
검색 유입과 광고 심사를 고려한다면 방문자가 얻을 수 있는 정보가 분명해야 합니다. 운영자의 일상만 나열하기보다 특정 문제를 해결하는 글, 직접 해본 설정 과정, 실수와 해결 방법을 정리한 글이 더 안정적입니다.
대표 주소 정하기
도메인을 샀다면 `example.com`을 대표 주소로 쓸지, `www.example.com`을 대표 주소로 쓸지 정해야 합니다. 두 주소가 모두 열리더라도 검색 엔진과 방문자에게 보여줄 기준 주소는 하나로 통일하는 것이 좋습니다.
GitHub Pages에서는 루트 도메인과 www 주소를 모두 연결할 수 있지만, DNS 레코드와 저장소 설정이 서로 맞아야 합니다. 이 결정을 미루면 나중에 Search Console, 사이트맵, 애드센스 등록 주소가 어긋날 수 있습니다.
콘텐츠 범위 좁히기
처음부터 모든 주제를 다루려 하면 빈 카테고리가 생기고 사이트의 성격이 흐려집니다. 초기에 3개 정도의 카테고리로 시작하고, 각 카테고리에 실제 글을 꾸준히 채울 수 있는지 확인하는 편이 낫습니다.
도메인, DNS, GitHub Pages, 정적 사이트 운영처럼 서로 연결되는 주제를 묶으면 내부 링크를 만들기 쉽고 방문자가 다음 글로 이동할 이유도 생깁니다.
emfls.com을 기준으로 본 시작 순서
이 사이트는 먼저 대표 도메인을 `emfls.com`으로 정하고, GitHub 저장소 이름과 Cloudflare Pages 프로젝트 이름을 `emfls-site`로 맞췄습니다. 이렇게 이름을 맞춰두면 Search Console, AdSense, 사이트맵, 배포 로그를 확인할 때 어떤 프로젝트를 보고 있는지 헷갈릴 가능성이 줄어듭니다.
처음부터 글 주제를 넓게 잡지 않고 개인 도메인, DNS, 정적 사이트 배포, 검색 등록으로 좁힌 것도 같은 이유입니다. 심사 전에는 빈 카테고리를 늘리는 것보다 서로 연결되는 글을 충분히 채우는 편이 더 안정적입니다.
준비할 스크린샷
도메인, 배포 프로젝트, Search Console 속성, AdSense 등록 주소가 모두 같은 대표 도메인을 기준으로 맞춰진 화면을 캡처하면 추후 점검에 도움이 됩니다.
실전 점검표
- 대표 도메인을 `루트 도메인` 또는 `www` 중 하나로 정한다.
- 사이트 주제를 한 문장으로 설명할 수 있는지 확인한다.
- 심사 전에 빈 카테고리와 테스트 페이지가 남아 있지 않게 한다.
- 문의, 개인정보처리방침, 편집 정책 같은 신뢰 페이지를 먼저 만든다.
흔한 실수
- 도메인을 산 직후 글 없이 AdSense부터 신청하는 것.
- 대표 도메인을 정하지 않고 `www`, 루트 도메인, 임시 배포 주소를 섞어 쓰는 것.
- 카테고리를 많이 만들고 실제 글은 1~2개만 넣는 것.
자주 묻는 질문
도메인을 먼저 사야 하나요, 사이트를 먼저 만들어야 하나요?
가능하면 사이트 주제와 대표 주소 정책을 먼저 정한 뒤 도메인을 연결하는 편이 좋습니다. 이미 도메인을 샀다면 대표 도메인, 사이트명, 카테고리를 먼저 고정하세요.
초기 글은 몇 개 정도가 적당한가요?
정답은 없지만 얇은 글 30개보다 완성도 있는 글 10~15개가 낫습니다. 각 글은 독립적인 질문에 답하고 내부 링크로 이어져야 합니다.
사이트 주제를 나중에 바꿔도 되나요?
가능하지만 심사 직전에는 큰 변경을 피하는 것이 좋습니다. 검색 엔진과 AdSense가 사이트의 목적을 파악할 시간을 주는 편이 안전합니다.