네이버 검색엔진최적화(SEO) 기준과 체크리스트 · 운영 상담

• 서치어드바이저 가이드 전수 대조
• 2026.08 기준
• 순위 보장 표현 없음

1. 웹사이트 섹션의 랭킹 축은 C-Rank가 아닙니다

검색엔진최적화 제안서에서 가장 자주 인용되는 단어가 C-Rank와 D.I.A.입니다. 그런데 서치어드바이저 가이드 문서 전체를 검색하면 이 단어들은 한 번도 나오지 않습니다. 네이버가 공식적으로 C-Rank와 D.I.A.를 설명한 맥락은 전부 VIEW 영역, 즉 블로그와 카페입니다. 홈페이지가 노출되는 웹사이트 섹션과는 다른 영역입니다.

웹사이트 섹션에 대해 네이버가 공식적으로 밝힌 방향은 세 번 있었고, 세 번 다 같은 이야기입니다. 2023년에는 공신력 있는 출처를 우대하겠다고 했고, 2025년에는 자체 언어모델로 출처를 판별한다고 했으며, 같은 해 하반기에는 신뢰도 중심의 통합 랭킹을 시험한다고 밝혔습니다. 축은 블로그식 지수가 아니라 출처 신뢰도입니다.

2. 공식 문서에 숫자로 적혀 있는 기준

아래는 해석이 아니라 네이버 문서에 그대로 적힌 값입니다. SEO최적화 점검은 여기서부터 시작합니다.

참고로 Core Web Vitals, LCP, hreflang은 네이버 가이드 문서에 언급 자체가 없습니다. 구글 기준으로 만든 점검표를 그대로 들이대면 네이버에서는 상관없는 항목에 시간을 쓰게 됩니다. 물론 속도가 느려도 된다는 뜻은 아니고, 네이버가 공표한 기준이 아니라는 뜻입니다.

3. og 태그가 구조화 데이터보다 우선합니다

네이버는 og 태그를 "로봇이 페이지를 분석하고 노출하는 데 사용한다"고 명시하고 있습니다. 구조화 데이터보다 우선순위가 높습니다. 그런데 실제로는 og:image 하나를 로고로 돌려쓰는 경우가 대부분입니다.

• og:image는 가로세로 모두 150px을 넘어야 합니다.
• 파일 용량이 5,000바이트 이상이어야 합니다. 가벼운 로고 파일은 이 조건에서 걸립니다.
• 가로세로 비율이 3:1 이내여야 합니다. 가로로 긴 로고 이미지는 대부분 이 조건을 못 넘깁니다.
• 페이지마다 달라야 합니다. 전 페이지에 같은 로고를 반복하면 무시됩니다.

4. 구조화 데이터 — 넣으면 오히려 손해 보는 것들

구조화 데이터는 많이 넣을수록 좋다고 알려져 있지만, 지금 시점에는 넣지 말아야 할 목록이 더 중요합니다. 아래는 이미 폐기됐거나 정책 위반인데도 국내 자료에는 여전히 권장으로 남아 있는 것들입니다.

• FAQPage — 구글이 지원을 종료했고 관련 문서도 삭제됐습니다. 네이버도 지원 목록에 없습니다.
• WebSite + SearchAction — 사이트링크 검색창 자체가 폐기됐습니다.
• Service — 구글 구조화 데이터 문서에 해당 항목이 존재하지 않습니다.
• 자기 사이트에 직접 박는 aggregateRating — 정책 위반입니다. 별점을 스스로 매기는 마크업입니다.
• 반대로 HowTo는 구글에서는 죽었지만 네이버에서는 아직 유효합니다.

검증은 validator.schema.org로 합니다. 구글 리치결과 테스트는 구글이 지원하는 타입만 보기 때문에 네이버용 마크업을 점검하는 도구로는 맞지 않습니다.

5. 틀리기 쉬운 세부 조항

• breadcrumb에 "홈", "top" 같은 이름을 쓰지 않습니다. 네이버는 "일반적인 단어가 아니라 페이지를 잘 설명하는 텍스트"를 요구합니다. 거의 모든 사이트가 첫 계단을 "홈"으로 두고 있어서, 이것만으로 조건에서 벗어납니다.
• 연관채널을 나타내는 Organization에는 sameAs가 필수입니다. 연결할 채널이 없다면 빈 배열을 넣지 말고 주소 형식으로 작성해야 합니다.
• 공통 주소를 모든 페이지에 반복 마크업하지 않습니다. 푸터에 있다고 해서 전 페이지에 같은 사업장 정보를 구조화 데이터로 박으면 안 됩니다.
• ItemList에서 image는 ListItem의 유일한 필수값입니다. 목록형 마크업을 넣고 이미지를 빼면 그대로 무효가 됩니다.

6. 1위 페이지 실측 — 결국 무엇으로 갈리나

플레이스 관련 검색어 8개를 골라 웹사이트 섹션 1위 페이지를 직접 열어 확인했습니다. 결과는 기술적 최적화의 한계를 그대로 보여줍니다.

• 1위 8곳 중 6곳은 구조화 데이터가 하나도 없었습니다. 그중에는 네이버 자체 페이지도 포함돼 있습니다.
• 실질적인 경쟁 상대라 할 만한 곳은 한 곳뿐이었고, 그 사이트의 특징은 스키마가 아니라 본문 3,400자대의 문서와 30개의 내부링크, 60개 규모의 사이트맵이었습니다.

이 표본만으로 순위의 원인을 단정할 수는 없습니다. SEO최적화는 수집 가능한 구조와 검색 의도에 맞는 내용을 함께 점검하는 작업입니다. 문서 분량이나 페이지 수를 늘리는 것만으로 순위가 보장되지 않습니다. 제목은 내용을 정확하게 설명하고, 본문에는 이용자가 필요한 답과 검증 가능한 근거를 담아야 합니다. robots.txt와 canonical을 확인한 뒤 노출·클릭·문의 변화를 관찰합니다.

7. 실행 순서 체크리스트

순서대로 확인하시면 됩니다. 앞의 항목이 깨져 있으면 뒤의 작업은 효과가 나오지 않습니다.

1단계 · 수집을 막고 있는 것부터 없앱니다

• robots.txt가 200으로 응답하는지, CSS·JS·파비콘을 막고 있지 않은지 확인합니다.
• 사이트맵의 호스트가 실제 주소와 같은지, 사이트맵에 없는 페이지가 있는지 확인합니다.
• 같은 문서가 여러 주소로 열리는지 확인하고 하나로 301 통합합니다.
• 소유확인 meta가 head 안에 있는지 확인합니다.

2단계 · 문서마다 주제를 알려줍니다

• title 40자, description 80자 안에서 페이지마다 다르게 씁니다. 회사명은 뒤에 붙이고, 앞에는 그 문서가 답하는 질문을 씁니다.
• H1을 문서당 1개 둡니다.
• og 5종을 채우고, og:image를 페이지별로 따로 만듭니다.
• canonical을 자기 자신을 가리키는 절대경로로 통일합니다.

3단계 · 구조화 데이터는 최소한만

• 화면에 실제로 있는 내용만 마크업합니다.
• 본문에 실제로 있는 정보를 해당 문서의 유형에 맞게 표현합니다.
• schema.org의 타입 정의와 검색엔진별 노출 기능의 지원 여부를 구분해 확인합니다.

4단계 · 여기부터가 실제 순위 작업입니다

• 같은 검색 의도의 질문은 한 문서에서 함께 답하고, 구분되는 주제는 기존 URL과 연결해 보강합니다.
• 페이지끼리 서로 연결합니다. 링크가 하나도 안 걸린 문서는 늦게 잡힙니다.
• 새 문서를 만들거나 크게 고치면 수집을 요청합니다.