구글 SEO 가이드(3) - 테크니컬 SEO (Technical SEO) 은 무엇인가요?
우리는 #1가이드문서에서 SEO 작업의 범위는 웹사이트의 기술적인 측면을 돕는 최적화 작업인 테크니컬 SEO, 웹사이트 외부에서 수행하는 최적화 작업을 의미하는 오프페이지 SEO, 그리고 페이지가 검색 엔진 결과 페이지 (SERP)에서 잘 수행되도록 도와주는 온페이지 SEO로 구성되어 있음을 간략하게 살펴보았습니다.
(image source: Foundation Marketing)
그리고 콘텐츠를 통해 높은 검색 결과 순위를 차지하기 위해서, 위의 3가지 SEO 작업의 범위를 포함하는 다음의 프로세스를 밟는다는 것까지 이해했습니다:
테크니컬 (Technical) SEO.Optimize for search engine efficiency.
키워드 리서치. Identify optimal search terms.
콘텐츠 SEO.Tailor content for searchers.
온페이지 (On-page) SEO. Clarify content presentation.
오프페이지 (Off-page) SEO.Build trust and authority externally.
비즈니스와 연관성이 높은 동시에 사람들이 궁금해할만한 키워드를 찾고 도출된 키워드들을 이용하여 콘텐츠를 작성하기 이전에, 유저들이 콘텐츠를 쉽게 발견하고 진입하여 내용을 원활하게 볼 수 있는 장소가 필요 합니다. 이러한 환경을 구축하고 보완하는 것, 즉 "검색 엔진"이 콘텐츠를 쉽게 크롤링하고 색인할 수 있도록, 그리고 "사람"이 원활하게 페이지 상의 콘텐츠를 볼 수 있도록 웹사이트의 기술적인 측면을 체크하는 작업을 테크니컬 SEO라고 합니다.
테크니컬 SEO는 검색 엔진 최적화 작업에서 기술적으로 해결해야 하는 여러 가지 요소들을 아우르는 용어입니다. 이는 한 번에 해결되는 것이 아니며 콘텐츠를 작성하고 발행하며 중간에 발견되는 기술 사항들을 지속적으로 개선하고 해결하려고 노력해야 합니다. 우리는 절대로 모든 것을 체크할 수 없으며 무엇보다 가장 중요한 질 좋은 콘텐츠 작성에 집중하는 것이 바람직하므로, 사소한 테크니컬 작업에 소요되는 쓸데 없는 자원 낭비는 최소화해야 한다는 점을 명심해야 합니다.
다만, 웹사이트와 콘텐츠를 위한 기술적인 기초가 필요하다는 점을 감안하여 가장 먼저 테크니컬 SEO에 대해 살펴보는 것이므로, 다양한 기술적인 주제들 중 몇 가지를 (1)웹사이트, (2)검색 엔진, 그리고 (3)사용자 측면으로 나누어 살펴보겠습니다.
아래에 설명하는 내용들을 모두 하나하나 자세히 이해할 필요는 없습니다. 다양한 기술적인 문제들이 존재한다는 사실을 이해하는 정도로도 충분합니다.
웹 사이트 측면에서의 테크니컬 SEO
HTTP 응답 상태 코드
HTTP는 HyperText Transfer Protocol(하이퍼텍스트 전송규약)의 줄임말로 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜입니다. 클라이언트(PC 및 브라우저)가 HTTP를 통해 서버에게 정보를 요청하면 서버는 이 요청에 응답하여 해당 정보를 클라이언트에 전달합니다. (image source:GeeksforGeeks)
HTTP 응답 상태 코드는 클라이언트가 보낸 HTTP 요청에 대한 서버의 응답을 나타냅니다. 이 상태 코드는 요청의 성공 또는 실패 여부를 세 자릿수의 숫자(예시: 404)로 표현합니다.
이러한 상태 코드를 통해 페이지의 접근 가능성과 서버의 상태를 파악할 수 있으며, 테크니컬 SEO 진단 시에 페이지의 응답 상태를 확인하는 것이 중요합니다. 페이지의 상태 코드에 따라 SEO에 부정적인 영향을 미칠 수 있기 때문입니다. 응답 상태에 따라 크게 다섯 개의 클래스로 나뉘며, 클래스 하위에 각 코드와 상태가 존재합니다:
200(OK)
HTTP 상태 코드 200은 요청이 성공적으로 수신되었고, 요청된 내용으로 응답이 정상적으로 이루어졌음을 나타냅니다. 클라이언트에게 모든 것이 정상적으로 작동되었다는 메시지를 전달하며 해당 페이지에 정상적으로 접근이 가능한 상태임을 의미합니다.301(Moved Permanently), 302(Moved Temporarily)
300번대의 코드는 페이지가 다른 페이지로 리디렉션되고 있음을 나타냅니다.
그 중 301은 영구 리디렉션을 나타내며, 요청된 URL이 영구적으로 다른 위치로 이동했음을 표시합니다. 검색 엔진이 이전 페이지의 페이지 순위와 링크에 대한 정보를 새 페이지로 전달하고, 브라우저도 향후 추가 요청을 저장하기 위해 캐시를 통해 페이지 표시 속도를 개선합니다.
반면에 302 리디렉션은 요청된 URL이 임시적으로 다른 위치로 이동했음을 나타내며, 검색 엔진은 보다 오랜 기간이 지난 후에 이를 영구 리디렉션으로 처리할 수 있습니다.
SEO 측면에서 살펴보면, 페이지 위치 변경이 일시적이어서 URL이 다시 회귀하는 경우에는 페이지 순위 및 링크에 대한 점수를 잃게 되므로 301 코드를 사용하면 안되고, 반대로 지속적인 리디렉션에는 301이 권장됩니다.404(Not Found)
404 Not Found 상태 코드는 클라이언트가 서버와의 통신은 가능하지만 요청한 페이지나 파일을 해당 서버에서 찾을 수 없을 때 발생합니다. 주로 손상된 링크를 클릭했을 때 나타나며, 아래와 같은 화면을 인터넷을 사용하며 마주치셨던 경험이 있으실 겁니다.
404 에러 코드는 개발자나 서버 유지보수 담당자의 실수로 인해 콘텐츠가 삭제되었을 때도 발생할 수 있는데, 삭제된 콘텐츠의 URL은 검색 엔진의 색인에서 제거되므로 해당 페이지는 더 이상 검색 결과에 나타나지 않습니다.
따라서, 콘텐츠가 삭제되지 않았는데도 404 에러가 발생하면 심각한 문제가 발생한 것이므로 이를 신속하게 해결해야 하며, 의도적으로 페이지를 삭제했다면 삭제된 콘텐츠의 URL을 웹사이트에서 제거하는 것이 좋습니다.구글은 404 에러가 SEO에 직접적인 영향을 미치지 않는다고 설명하고 있지만(link), 사용자 경험과 웹사이트 신뢰도에 부정적인 영향을 줄 수 있으므로 빠른 조치가 필요합니다.
500(Internal Server Error), 502(Bad gateway)
500번대의 코드는 클라이언트가 아닌 서버에서 발생한 오류를 나타냅니다. 이러한 오류는 서버가 요청을 처리할 수 없어 페이지를 올바르게 표시하지 못할 때 발생하며 일반적으로 서버 구성 오류로 인해 발생합니다.
503 코드는 서버가 현재 사용할 수 없음을 나타내며, 따라서 클라이언트의 요청을 처리할 수 없음을 의미합니다. 이는 주로 서버 점검이나 서버 과부하로 인해 발생합니다.
위와 같은 상태 코드들은 웹페이지의 접근성과 사용자 경험에 부정적인 영향을 미칠 수 있으므로 서버 관리자는 이러한 오류를 신속하게 해결하여 웹사이트의 정상적인 작동을 보장해야 합니다.특히 서버 오류가 계속 발생하고 지속되는 경우에는 검색 엔진이 해당 페이지를 신뢰할 수 없다고 판단하여 색인에서 삭제할 가능성이 있으므로 웹사이트 운영자는 이러한 상황을 방지하기 위해 서버 상태를 지속적으로 모니터링하고 오류를 신속하게 해결해야 합니다.
웹 사이트 구조: 서브도메인 vs 서브디렉토리
크롤러는 URL 경로를 따라 새로운 페이지로 이동하여 새로운 콘텐츠를 찾게 됩니다. 때문에 페이지 간 이동할 수 있는 링크 경로가 없거나 크롤러가 접근하기 어려운 방식으로 네비게이션을 구성한 페이지는 크롤링에 안 좋은 영향을 미칠 수 있고, 웹 소유자는 XML 사이트맵을 제출함으로써 웹 사이트의 중요한 페이지 정보와 구조를 크롤러가 빠르게 이해할 수 있도록 돕기도 합니다.
이처럼 웹사이트 URL 구조는 검색 엔진의 작동 방식에 영향을 미치는 주요한 요소이기 때문에 웹 사이트 빌딩 시부터 세밀한 관심을 기울여야 합니다.
웹 사이트 구조와 관련한 주제 중에서 SEO 필드에서 가장 뜨거운 서브 도메인(Subdomain) vs 서브 디렉토리(Sub-directory) 이슈를 잠시 소개합니다. 보다 자세한 내용은 다음 문서를 참조해주세요:Do custom domains affect SEO?
서브도메인 (Subdomain)은 도메인 앞에 붙는 것을 말한다. 예를 들어, 본래 도메인인 example.com와 더불어 예를 들어, 블로그는 blog.example.com으로 접근할 수 있고, 쇼핑몰은 shop.example.com으로 접근할 수 있도록 하위 도메인들로 나눌 수 있습니다.
서브디렉토리 (Subdirectory) 또는 서브폴더(Subfolder) 방식은 말그대로 URL에 하위 폴더로 구성되는 방식을 말합니다. 예를 들어, 본래 도메인인 example.com와 더불어 블로그는 example.com/blog로 접근할 수 있고, 쇼핑몰은 example.com/shop으로 접근할 수 있도록 디렉토리를 쪼개는 것입니다.
검색 엔진이 서브도메인으로 구성된 페이지를 별개의 사이트로 보기 때문에 서브 도메인으로 구성된 페이지의 SEO 점수가 원래 도메인에 어떻게 반영될지가 문제가 됩니다.
검색엔진 측면에서의 테크니컬 SEO
구글은 크롤러를 이용하여 웹상에 존재하는 페이지를 발견하고 새로운 페이지를 지속적으로 탐색하는 크롤링 과정을 거쳐, 수집된 페이지 자료들의 내용을 분석하고 이 정보를 인덱스 데이터베이스에 저장합니다.
위와 같은 검색엔진 프로세스에 영향을 미치는 테크니컬 요소들을 몇 가지 살펴봅시다.
XML Sitemaps & Robots.txt
구글은 크롤링 작업을 위해 막대한 수의 컴퓨터를 사용하여 매일같이 웹에 있는 페이지 수십억 개를 크롤링하고 있습니다. 이렇게 웹에는 어마어마한 정보가 계속해서 생성되므로 크롤러가 모든 URL과 페이지 내의 모든 세부 정보를 파악할 수는 없기 때문에 구글은 사이트 소유자가 개별 URL의 크롤링을 요청할 수 있도록 구글 서치 콘솔에서 URL 제출 기능을 제공하고, 웹사이트 내 중요한 페이지 정보와 구조를 빠르고 쉽게 이해할 수 있도록 정리한 XML 형식의 파일인 사이트맵 (XML sitemap) 제출을 허용합니다. (source: Adobe Experience Manager Tutorial Blog)
한편 테스트 페이지와 같이 사이트 소유자가 크롤링을 허용하지 않는 페이지도 있고 사이트에 로그인해야 액세스할 수 있는 페이지 등 크롤러는 발견한 페이지를 모두 크롤링하는 것은 아닙니다. 크롤러는 로그인을 하지 못하기 때문에 사용자들이 특정 콘텐츠에 액세스하기 전에 로그인, 양식 작성 또는 설문 조사에 응답해야 한다면, 봇은 해당 보호된 페이지를 크롤링할 수 없습니다. 이렇듯 구글봇이 특정 페이지에 엑세스하지 못하도록 구글봇을 제어하기도 하는데, 이러한 규칙을 담은 파일이 robots.txt 입니다.
표준 URL (Canonicalization)
인덱싱 과정에서 여러 URL이 하나의 페이지를 가리킬 때, 표준 URL로 인식되는 페이지를 대표적인 페이지로 간주하여 검색 결과에 표시하는데, 이를 표준화(Canonicalization) 프로세스라고 합니다.
예를 들어, A페이지의 Canonical URL을 B페이지의 URL로 설정하면, 검색 엔진은 A페이지를 B페이지의 사본으로 인식하고 A페이지를 색인에서 제외합니다.
페이지 색인이 생성되면, 각 페이지의 주요 콘텐츠가 결정됩니다. 검색 엔진은 동일해 보이거나 주된 콘텐츠가 서로 매우 유사한 페이지를 여러 개 발견하면 이들 중 가장 유용한 페이지를 선택하여 표준 페이지로 표시합니다. 표준 페이지가 가장 정기적으로 크롤링되며, 중복 페이지는 사이트의 크롤링 부담을 줄이기 위해 이보다 적게 크롤링됩니다.
검색 엔진은 페이지가 HTTP 또는 HTTPS 중 어느 쪽을 통해 제공되는지, 사이트맵에 URL이 포함되어 있는지, 그리고 rel="canonical" 과 같은 다양한 요소를 고려하여 표준 URL을 결정합니다.
구조화된 데이터, 리치 결과, 스키마 마크업, JSON-LD
구글에서 웹 서핑을 하면서 영화(영화 제목, 감독, 출연 배우, 개봉일)나 음식(레시피, 요리 시간, 칼로리)과 관련된 정보들을 검색 결과 페이지에서 아래와 사진과 같은 모습처럼 마주하게 될 때가 있습니다. 이것은 영화 정보나 음식 정보와 같은 데이터가 구조화되어 노출된 것으로, 이를 구조화된 데이터 (Structured data)라고 합니다. 구조화된 데이터는 영화나 음식과 같이 특정한 데이터 유형을 정의하고 그에 따른 속성과 값의 관계를 명확하게 정의하여 검색 엔진이 웹 페이지의 콘텐츠를 더 잘 이해할 수 있도록 도와줍니다.
구글은 이러한 구조화된 데이터가 사용된 페이지의 콘텐츠를 파악하고 검색 결과에서 해당 콘텐츠를 아래 사진과 같이 다채롭고 유용한 방식으로 노출합니다. 이를 리치 결과 (Rich results)라고 하며, 일반적인 검색 결과보다 더 많은 정보를 제공하고 시각적으로 더욱 돋보이게 표시되므로 유저들의 이목을 강력하게 끌 수 있게 됩니다.
리치 결과는 구조화된 데이터를 통해 노출되며, 이를 정의하기 위해 스키마 마크업 (Schema Markup)이라는 표준을 사용합니다. 스키마는 상관관계를 가진 데이터들을 조직화하여 정의하는 것을 뜻합니다. 예를 들어, 아래 사진과 같이 기사 스키마는 기사에 관련된 속성들을 정의하고 이를 구조화된 데이터로 표현합니다.
스키마 마크업은 일반적으로 위와 같은 JSON-LD 형식으로 작성됩니다. 이러한 마크업은 구조화된 데이터를 웹 페이지의 HTML 문서 내에 삽입하여 검색 엔진이 이를 읽어들여 데이터를 이해하고 검색 결과에 표시하도록 합니다.
이외에도 크롤러가 콘텐츠의 구조를 잘 이해할 수 있도록 돕는 HTML H태그, 웹 페이지의 제목과 설명을 지정하여 검색 결과 페이지에 노출되도록 하여 콘텐츠 외부에서 검색 유저들이 콘텐츠에 대한 전체적인 개요를 파악하는데에 도움을 주는 타이틀 태그 및 메타 디스크립션, 검색 엔진에게 콘텐츠 내의 이미지에 대한 컨텍스트를 제공하기 위한 이미지 alt 태그 등 이외에도 수 많은 요소들이 검색 엔진 프로세스 상에 영향을 미칠 수 있습니다.
사용자 경험 측면에서의 테크니컬 SEO
웹 사이트와 검색 엔진 뿐만 아니라"사람"이 원활하게 페이지 상의 콘텐츠를 볼 수 있도록 웹사이트의 기술적인 측면을 체크하는 작업도 테크니컬 SEO에서 중요한 비중을 차지합니다. 사용자 관점에서의 테크니컬 최적화 작업 몇 가지를 살펴보겠습니다.
HTTP vs HTTPS (SSL화)
웹 브라우저와 웹 서버 간 통신을 담당하는 HTTP 프로토콜은 피싱, 데이터 도청 등의 보안 문제가 있었습니다. 이러한 보안 문제들로부터 정보를 안전하게 보호하기 위해 SSL(Secure Sockets Layer)이 도입되었고, 이를 통해 HTTPS가 등장했습니다. SSL의 암호화 방식에 대한 자세한 설명은 다음 링크를 참조해주세요. (link)
구글은 웹 보안을 강화하기 위해 2014년 HTTPS 암호화 (SSL화)를 하고 있는지를 검색 순위의 결정 요소에 포함한다고 발표하였고, 모든 웹사이트 소유자들에게 HTTP에서 HTTPS로 전환할 것을 권장합니다. (link)
구글은 웹 소유자들이 유저들에게 더 안전하고 신뢰할 수 있는 웹 경험을 제공할 수 있도록 웹 사이트 보안을 강화하고 HTTPS 전환을 촉진하기 위해 Google I/O에서 "HTTPS Everywhere" 세션을 통해 가이드라인과 체크리스트를 발표했습니다:
페이지 속도 - LCP(Largest Contentful Paint)
LCP (Largest Contentful Paint)는 실제 사용자 경험에 영향을 주는 핵심 지표를 식별하고 측정하는코어 웹 바이탈 (Core web vitals) 지표 중 하나로, 사용자가 URL을 요청한 시점부터 페이지 내에서 시각적으로 가장 큰 요소를 그리는데에 걸리는 시간을 의미합니다. (image source: Virendra's TechTalk)
좋은 사용 경험을 제공하기 위해서는 페이지가 처음으로 로딩된 후 2.5초 이내에 LCP 가 발생해야 하며, LCP가 4초 이상인 경우에는 구글은 이를 나쁜 사용성 평가로 분류하며 Core Web Vital 점수를 깎습니다.
HTML <lang> 태그
만약 다국어 페이지에서 디폴트 언어가 지정되지 않았다면, 스크린 리더는 사용자가 설정한 기본 언어로 페이지를 해석합니다. 이 경우, 유저들은 번역된 페이지를 읽을 때의 어색함을 느낄 수 있으며, 언어의 부자연스러움으로 인해 페이지를 빠르게 떠날 수 있습니다. 이는 자연스럽게 사용자 경험에 부정적인 영향을 미치게 됩니다.
<lang> 태그는 HTML 구조 내에 삽입되며 다음과 같이 사용됩니다:
<html lang="en-us">페이지의 디폴트 언어를 선언하기 위해 두 자릿수 코드를 사용하며, 이어서 언어의 지역을 선언하는 두 자릿수 코드가 뒤따르기도 합니다.
<lang> 태그에 대한 보다 자세한 내용은 How the HTML lang attribute helps Accessibility? 문서를 참조하세요.
이외에도 살펴봐야 하는 기술적인 요소들은 다양하게 존재합니다. 하지만 우리의 목표는 기술 요소들의 해결이 아닌 질 좋은 콘텐츠 작성을 통하여 오가닉 유입을 늘리고 점진적인 전환을 만들어냄에 있으므로, 리소스 투입 대비 큰 효용을 만들어내지 못하는 사소한 기술적 작업에 소요되는 시간과 노력은 최소화해나가야 한다는 것을 반드시 명심하세요!
인사이트 받아보기