테크니컬 SEO & 웹 인프라 on 247COMPASS

301 리디렉션

Thu, 01 Oct 2026 00:00:00 +0900

301 리디렉션은 검색엔진에게 ‘이 페이지는 새 주소로 영구히 이사했다’고 알리는 신호로, 기존 페이지가 쌓아온 백링크 점수(링크 에쿼티)의 대부분을 새 URL로 이전시켜준다. 도메인 이전이나 URL 구조 개편처럼 대규모 변경이 발생할 때는 이전 URL과 신규 URL을 1:1로 매핑한 리디렉션 맵을 미리 작성해두는 것이 순위 손실을 막는 가장 확실한 방법이다. A→B→C처럼 여러 단계를 거치는 체인 리디렉션은 크롤 예산을 낭비하고 링크 점수 손실을 키우므로 항상 A→C로 한 번에 연결해야 한다.

302 리다이렉트

Thu, 01 Oct 2026 00:00:00 +0900

302는 ‘지금은 잠깐 다른 곳에 있다’는 임시성을 나타내는 코드라, 검색엔진은 원래 URL을 색인에서 지우지 않고 그대로 유지한 채 순위도 원본 URL 기준으로 계산한다. 세일 기간에만 사용하는 프로모션 페이지, 서버 점검 안내 페이지처럼 원상 복귀가 예정된 경우에 적합하다. 실무에서 흔한 실수는 실제로는 영구 이전인데 개발 편의상 302를 기본값으로 써버려, 몇 달이 지나도 링크 점수가 새 URL로 넘어가지 않는 것이다.

404 오류

Thu, 01 Oct 2026 00:00:00 +0900

404는 서버가 ‘해당 URL에 대응하는 자원이 없다’고 명확히 알리는 표준 응답으로, 이 신호 덕분에 검색엔진은 더 이상 그 페이지를 색인에 유지할 필요가 없다는 것을 알고 크롤 자원을 다른 살아있는 페이지에 재배분한다. 단순히 콘텐츠를 삭제한 것이라면 404가 정상이지만, 예전에 방문자가 많이 유입되던 인기 페이지라면 관련 콘텐츠로 301 리디렉션해 트래픽과 링크 가치를 보존하는 편이 낫다. 사용자 경험 측면에서는 관련 글 추천, 검색창을 포함한 커스텀 404 페이지를 제공해 이탈을 줄이는 것이 권장된다.

AMP

Thu, 01 Oct 2026 00:00:00 +0900

AMP는 자바스크립트 사용을 극도로 제한하고 자체 CDN 캐싱을 강제하는 방식으로 모바일 페이지 속도를 인위적으로 표준화하려 했던 시도였다. Core Web Vitals가 등장하면서 굳이 AMP라는 별도 기술 스택을 쓰지 않아도 일반 웹 표준만으로 동일한 성능 목표를 달성할 수 있게 되어 구글도 AMP 의존도를 낮추는 방향으로 정책을 바꿨다. 현재 뉴스 업계에서도 AMP를 유지보수하는 곳은 점차 줄고 있으며, 대신 SSG·Astro 같은 최신 프레임워크로 속도를 확보하는 것이 일반적인 흐름이다.

hreflang

Thu, 01 Oct 2026 00:00:00 +0900

hreflang은 <link rel=“alternate” hreflang=“ko-KR”>처럼 언어-국가 코드 조합을 HTML head나 사이트맵에 명시해, 같은 내용이라도 사용자의 언어·지역 설정에 맞는 버전을 검색엔진이 노출하도록 안내하는 태그다. 반드시 서로를 가리키는 양방향(Return Tag) 참조가 있어야 하며, A 페이지가 B를 가리키는데 B는 A를 가리키지 않으면 구글이 해당 hreflang 신호 전체를 무시해버린다. ISO 639-1 언어 코드와 ISO 3166-1 국가 코드를 정확한 대소문자와 하이픈 규칙으로 표기하지 않으면 조용히 무효 처리되는 경우가 많아 검증 도구로 사전 점검이 필요하다.

HTTP 상태 코드

Thu, 01 Oct 2026 00:00:00 +0900

HTTP 상태 코드는 1xx(정보성), 2xx(성공), 3xx(리디렉션), 4xx(클라이언트 오류), 5xx(서버 오류)의 다섯 계열로 나뉘며, 이 중 SEO 관점에서 가장 자주 다뤄지는 것은 200, 301, 404, 410, 5xx다. 검색 콘솔의 ‘페이지’ 보고서는 상태 코드를 기준으로 크롤링·색인 문제를 분류하므로, 5xx 오류가 대량 발생하면 구글이 사이트 전체의 신뢰도를 낮춰 크롤 빈도를 스스로 줄여버릴 수 있다. 정기적으로 서버 로그나 모니터링 도구로 4xx·5xx 비율을 추적해 이상 징후를 조기에 발견하는 것이 중요하다.

HTTPS

Thu, 01 Oct 2026 00:00:00 +0900

HTTPS는 SSL/TLS 인증서를 통해 클라이언트와 서버 사이의 통신을 암호화해, 중간에서 데이터를 가로채거나 변조하는 중간자 공격을 방지한다. 구글은 2014년부터 HTTPS를 공식 랭킹 시그널로 발표했고, 크롬 브라우저는 HTTP 사이트에 ‘안전하지 않음’ 경고를 표시해 사용자 이탈을 유발한다. HTTPS로 전환한 뒤에도 이미지나 스크립트를 여전히 http:// 경로로 불러오는 혼합 콘텐츠(Mixed Content)가 남아있으면 브라우저가 해당 리소스를 차단하거나 경고를 띄우므로 전체 리소스 경로를 https로 일괄 점검해야 한다.

IndexNow

Thu, 01 Oct 2026 00:00:00 +0900

IndexNow는 마이크로소프트 빙과 얀덱스가 주도해 만든 개방형 프로토콜로, 콘텐츠가 생성·수정·삭제될 때마다 사이트가 API 키와 함께 해당 URL을 검색엔진에 푸시(push) 방식으로 즉시 통보한다. 기존에는 크롤러가 주기적으로 재방문해줄 때까지 기다려야 했지만, IndexNow를 쓰면 몇 분 안에 변경 사항이 반영될 수 있다. 다만 구글은 2024년 기준 IndexNow를 공식 지원하지 않으므로, 구글 색인을 빠르게 갱신하려면 서치 콘솔의 URL 검사 도구를 별도로 활용해야 한다.

JavaScript SEO

Thu, 01 Oct 2026 00:00:00 +0900

자바스크립트 SEO는 React, Vue, Angular처럼 클라이언트 사이드 렌더링(CSR)에 의존하는 사이트에서, 크롤러가 빈 HTML 껍데기만 보고 실제 콘텐츠를 놓치는 문제를 다루는 전문 분야다. 구글봇은 자바스크립트를 실행할 수 있지만 렌더링 큐에 대기했다가 처리되므로 일반 HTML보다 색인이 수 일~수 주 늦어질 수 있고, 빙이나 네이버 등 다른 검색엔진은 자바스크립트 실행 지원이 제한적이다. 서버 사이드 렌더링(SSR)이나 사전 렌더링(Prerendering)을 도입하고, 구글 서치 콘솔의 URL 검사 도구로 실제 렌더링된 HTML을 눈으로 직접 확인하는 검증 절차가 필수다.

robots meta tag

Thu, 01 Oct 2026 00:00:00 +0900

robots meta tag는 <meta name=“robots” content=“noindex, nofollow”>처럼 페이지 HTML head 안에 직접 삽입해, 그 페이지 하나만 세밀하게 색인·링크 추적 여부를 제어할 수 있는 태그다. noimageindex, max-snippet:-1, notranslate 같은 세부 지시자를 조합하면 이미지 색인 제외나 스니펫 길이 제한도 가능하다. 다만 robots.txt에서 해당 경로 전체를 차단해버리면 크롤러가 애초에 그 페이지에 접근하지 못해 meta 태그 자체를 읽을 수 없으므로, noindex를 적용하려면 반드시 크롤링은 허용한 채로 두어야 한다.

robots.txt

Thu, 01 Oct 2026 00:00:00 +0900

robots.txt는 사이트 루트(domain.com/robots.txt)에 위치하는 평문 텍스트 파일로, User-agent별로 어떤 디렉터리를 크롤링해도 되는지 규칙을 선언한다. 로그인 페이지나 관리자 화면처럼 크롤러가 굳이 방문할 필요 없는 영역을 차단해 한정된 크롤 예산을 중요한 페이지에 집중시키는 데 효과적이다. 다만 robots.txt로 차단된 페이지도 다른 사이트가 링크를 걸면 URL 자체는 색인에 노출될 수 있어(스니펫 없이), 검색결과에서 완전히 빼려면 noindex 태그와 크롤링 허용을 함께 사용해야 한다.

RSS 피드

Thu, 01 Oct 2026 00:00:00 +0900

RSS 피드는 XML 표준으로 최신 글의 제목, 요약, 발행일, 링크를 구조화해 배포하는 오래된 신디케이션 규격으로, 뉴스 리더 앱뿐 아니라 검색엔진 크롤러와 IFTTT 같은 자동화 도구가 신규 콘텐츠를 빠르게 감지하는 통로로도 쓰인다. 대부분의 CMS(워드프레스, 고스트 등)가 /feed 경로로 기본 제공하며, 서치 콘솔의 사이트맵 제출란에 함께 등록해두면 크롤링 발견 속도를 높이는 데 도움이 된다. 요약만 제공할지 전체 본문을 제공할지는 콘텐츠 스크래핑 위험과 리더 경험 사이의 트레이드오프를 고려해 결정해야 한다.

URL 구조

Thu, 01 Oct 2026 00:00:00 +0900

좋은 URL 구조는 example.com/blog/seo-guide처럼 폴더 계층이 사이트의 정보 구조를 그대로 반영해, 사용자가 주소창만 보고도 어디에 있는지 짐작할 수 있게 한다. 파라미터(?id=482&cat=3)로 뒤범벅된 URL보다 키워드가 포함된 소문자-하이픈 구조가 검색결과 스니펫에서도 더 신뢰감 있게 보이고 클릭률에 긍정적인 영향을 준다. URL은 한 번 공개되면 자주 바꾸지 않는 것이 원칙이며, 부득이하게 변경할 때는 반드시 301 리디렉션으로 이전 주소와 연결해야 한다.

노인덱스

Thu, 01 Oct 2026 00:00:00 +0900

noindex는 페이지 자체는 존재하되 검색결과 목록에는 절대 나타나지 않도록 지시하는 방법으로, 감사 인사 페이지, 내부 검색 결과 페이지, 태그·필터 조합으로 무한히 생성되는 저품질 페이지를 정리할 때 자주 쓰인다. 페이지에 noindex를 걸어도 다른 페이지로의 내부 링크는 여전히 크롤러가 따라갈 수 있어(nofollow와 별개), 사이트 구조 자체를 해치지 않는다. 다만 noindex 페이지가 robots.txt로 크롤링까지 차단되어 있으면 구글이 애초에 그 태그를 읽을 방법이 없어 의도와 다르게 색인에 남아있을 수 있다는 점을 반드시 확인해야 한다.

리디렉션

Thu, 01 Oct 2026 00:00:00 +0900

리디렉션은 301(영구), 302(임시), 307(임시, 메서드 유지), 308(영구, 메서드 유지) 등 여러 상태 코드로 세분화되며, 어떤 코드를 쓰느냐에 따라 검색엔진이 링크 점수를 이전할지 원본을 유지할지가 달라진다. 사이트 개편, 도메인 통합, 모바일 서브도메인(m.example.com) 폐지 등 다양한 상황에서 사용되며, 잘못 설계된 리디렉션 체인이나 루프는 크롤 예산 낭비뿐 아니라 사용자에게 무한 로딩 화면을 보여주는 심각한 UX 오류로 이어질 수 있다. 대규모 변경 전에는 스크리밍프로그(Screaming Frog) 같은 크롤러로 전체 리디렉션 맵을 시뮬레이션해보는 것이 안전하다.

모바일 사용성

Thu, 01 Oct 2026 00:00:00 +0900

모바일 사용성은 뷰포트 메타 태그 설정, 반응형 레이아웃, 터치 대상 간 충분한 간격(구글 권장 최소 48x48px), 확대 없이 읽을 수 있는 폰트 크기(보통 16px 이상) 등을 종합적으로 평가하는 요소다. 서치 콘솔의 ‘모바일 사용성’ 보고서는 텍스트가 너무 작음, 클릭 요소가 너무 가까움 같은 구체적인 오류를 페이지 단위로 알려주므로 정기 점검이 필요하다. 전 세계 검색 트래픽의 절반 이상이 모바일에서 발생하는 만큼, 데스크톱에서만 테스트하고 배포하는 관행은 실제 사용자 이탈로 직결될 위험이 크다.

모바일 우선 인덱싱

Thu, 01 Oct 2026 00:00:00 +0900

모바일 우선 인덱싱은 2018년부터 구글이 단계적으로 전환한 정책으로, 이제는 데스크톱 버전이 아니라 모바일 사용자 에이전트(구글봇 스마트폰)가 수집한 페이지를 기준으로 색인과 순위를 결정한다. 반응형 디자인을 쓰는 사이트는 모바일과 데스크톱 콘텐츠가 동일해 큰 영향이 없지만, 별도의 m.example.com 모바일 전용 사이트를 운영하는 경우 모바일 버전에 본문 일부나 구조화 데이터가 누락되어 있으면 그만큼 손해를 본다. 두 버전이 있다면 모바일 페이지에도 데스크톱과 동일한 메타데이터, 이미지, JSON-LD를 반드시 미러링해야 한다.

사이트 마이그레이션

Thu, 01 Oct 2026 00:00:00 +0900

사이트 마이그레이션은 도메인 변경, HTTP→HTTPS 전환, CMS 교체, URL 구조 개편처럼 사이트의 근본적인 주소나 인프라를 바꾸는 작업으로, SEO 실무에서 가장 리스크가 큰 프로젝트로 꼽힌다. 이전-이후 모든 URL을 1:1로 매핑한 리디렉션 표를 사전에 만들고, 마이그레이션 직후 서치 콘솔의 ‘주소 변경’ 도구로 구글에 공식 통보하는 것이 표준 절차다. 마이그레이션 전후로 최소 2주 이상 서치 콘솔의 노출수·클릭수 추이를 매일 모니터링해, 예상치 못한 트래픽 급락을 조기에 발견하고 원인을 되짚을 수 있어야 한다.

XML 사이트맵은 사이트가 검색엔진에게 ‘이 URL들이 우리가 색인해주길 바라는 페이지 목록’이라고 직접 제출하는 문서로, 특히 내부 링크가 부족해 크롤러가 발견하기 어려운 신규 페이지나 대규모 이커머스 상품 페이지에서 효과가 크다. lastmod(최종 수정일) 필드를 정확히 갱신하면 크롤러가 실제로 바뀐 페이지에 우선적으로 재방문하도록 유도할 수 있다. 사이트맵에는 반드시 200 응답을 반환하는 정상 페이지만 포함해야 하며, noindex 페이지나 리디렉션·404 URL이 섞여 있으면 구글이 사이트맵 전체의 신뢰도를 낮게 평가할 수 있다.

사이트맵 인덱스

Thu, 01 Oct 2026 00:00:00 +0900

사이트맵 인덱스는 서치 콘솔에 단 하나의 URL(sitemap_index.xml)만 제출하면 그 안에 포함된 모든 하위 사이트맵을 구글이 자동으로 함께 읽어가는 구조라 관리가 편리하다. 각 하위 사이트맵의 lastmod 값을 정확히 갱신하면, 구글이 전체를 다시 훑지 않고 실제로 변경된 하위 사이트맵만 우선적으로 재확인하도록 유도할 수 있다. 상품 수가 많은 이커머스라면 카테고리별로 사이트맵을 나눠 특정 카테고리의 색인 누락 여부를 개별적으로 진단할 수 있다는 점도 실무적으로 큰 장점이다.

서브도메인

Thu, 01 Oct 2026 00:00:00 +0900

서브도메인(blog.example.com)은 루트 도메인(example.com)과 별개의 사이트로 취급되어, SEO 성과와 신뢰도 축적이 따로 계산되는 경우가 많다. 반대로 서브디렉터리(example.com/blog) 방식은 루트 도메인의 기존 권위를 그대로 물려받을 수 있어, 신규 블로그·지원 센터를 시작할 때는 대부분 서브디렉터리가 권장된다. 다만 완전히 다른 기술 스택이나 조직이 독립적으로 운영해야 하는 경우(예: 개발자 문서 사이트, 채용 페이지)에는 서브도메인 분리가 관리상 더 합리적일 수 있다.

소프트 404

Thu, 01 Oct 2026 00:00:00 +0900

소프트 404는 실제로는 콘텐츠가 없거나 ‘찾을 수 없음’이라는 텍스트만 있는 빈 페이지인데 서버가 정상 200 코드를 반환하는 상태로, 검색엔진 입장에서는 이 페이지가 진짜 유효한지 없는지 판단하기 어려워 혼란을 겪는다. 재고가 소진된 상품 페이지를 그냥 빈 화면으로 두거나, 프레임워크의 기본 에러 처리 로직이 200을 반환하도록 설정된 경우 자주 발생한다. 서치 콘솔의 ‘페이지’ 보고서에서 ‘소프트 404’로 분류된 URL을 주기적으로 점검해, 실제로 없는 페이지라면 정확한 404/410 코드를 반환하도록 서버 설정을 고쳐야 한다.

캐노니컬 태그

Thu, 01 Oct 2026 00:00:00 +0900

캐노니컬 태그(rel=canonical)는 UTM 파라미터가 붙은 URL, 대소문자만 다른 URL, http/https 혼재처럼 사실상 동일한 콘텐츠가 여러 주소로 존재할 때 ‘이 URL이 대표본’이라고 검색엔진에 알려준다. 캐노니컬을 지정하면 여러 URL에 분산되던 백링크 점수가 대표 URL로 통합되어 순위 경쟁력이 높아진다. 상대 경로가 아닌 https://example.com/page 처럼 전체 절대 경로로 작성해야 하며, 실제로 존재하지 않거나 다른 페이지를 가리키는 캐노니컬은 오히려 색인 오류를 유발한다.

코어 웹 바이탈

Thu, 01 Oct 2026 00:00:00 +0900

코어 웹 바이탈은 LCP(가장 큰 콘텐츠가 화면에 그려지는 시간, 2.5초 이내 권장), CLS(레이아웃이 예기치 않게 움직이는 정도, 0.1 이하 권장), INP(사용자 입력에 반응하는 속도, 200ms 이내 권장) 세 지표로 구성되며 2024년 3월 FID를 대체해 INP가 새로운 반응성 지표로 채택됐다. 이 수치는 실제 사용자의 브라우저에서 수집된 필드 데이터(CrUX)를 기반으로 하기 때문에, 개발자 PC의 랩 데이터(Lighthouse)와 실제 점수가 다를 수 있다. 이미지에 width/height를 명시해 레이아웃 변화를 막고, 메인 스레드를 오래 점유하는 자바스크립트를 코드 분할하는 것이 세 지표를 동시에 개선하는 가장 효과적인 방법이다.

크롤 버짓

Thu, 01 Oct 2026 00:00:00 +0900

크롤 예산은 서버가 감당할 수 있는 처리량과 사이트의 인기도(백링크 수 등)를 종합해 구글이 자동으로 배정하는, 정해진 기간 동안 크롤링할 페이지 수의 한도다. 수십만 페이지 규모의 대형 이커머스나 미디어 사이트에서는 예산이 부족해 일부 신규·수정 페이지가 몇 주씩 크롤링되지 않는 문제가 실제로 발생한다. 불필요한 파라미터 조합 URL을 robots.txt로 차단하고, 서버 응답 속도(TTFB)를 개선하면 같은 예산으로 더 많은 실제 페이지를 크롤링할 수 있게 된다.

테크니컬 SEO

Thu, 01 Oct 2026 00:00:00 +0900

테크니컬 SEO는 콘텐츠의 품질과 무관하게, 검색엔진이 사이트를 물리적으로 발견·수집·해석·색인할 수 있는지를 다루는 인프라 계층의 최적화 분야다. 아무리 훌륭한 글을 써도 서버가 5xx 오류를 자주 내거나, 자바스크립트 렌더링 문제로 본문이 크롤러에게 보이지 않는다면 그 콘텐츠는 검색결과에 노출될 기회조차 얻지 못한다. Screaming Frog, Sitebulb 같은 크롤링 감사 도구로 분기별 정기 점검을 실시해 상태 코드, 캐노니컬, 메타 태그의 대량 오류를 조기에 발견하는 것이 실무 표준 프로세스다.

페이지 속도

Thu, 01 Oct 2026 00:00:00 +0900

페이지 속도는 단순히 서버 응답 속도(TTFB)만이 아니라 이미지 압축, 자바스크립트/CSS 최소화, 폰트 로딩 전략, CDN 사용 여부까지 포함하는 종합적인 성능 지표다. 구글 연구에 따르면 로딩 시간이 1초에서 3초로 늘어나면 이탈률이 32% 증가하는 것으로 나타나, 속도는 SEO뿐 아니라 전자상거래 전환율에 직결되는 비즈니스 지표이기도 하다. WebP·AVIF 같은 차세대 이미지 포맷 도입, Gzip/Brotli 압축, 브라우저 캐싱 헤더 설정은 비교적 적은 개발 리소스로 빠르게 적용 가능한 대표적인 개선 방법이다.

페이지네이션

Thu, 01 Oct 2026 00:00:00 +0900

페이지네이션은 상품 목록이나 아카이브 글 목록을 1페이지, 2페이지처럼 나누어 사용자와 크롤러 모두가 순차적으로 탐색할 수 있게 하는 구조다. 무한 스크롤만으로 구현하면 자바스크립트 스크롤 이벤트에 의존하게 되어 크롤러가 두 번째 페이지 이후 콘텐츠를 아예 발견하지 못하는 경우가 많으므로, 무한 스크롤을 쓰더라도 페이지 번호가 명시된 링크(예: ?page=2)를 함께 제공하는 하이브리드 구현이 권장된다. 각 페이지네이션 URL에는 self-referencing 캐노니컬을 지정하고, view-all 페이지가 있다면 이를 캐노니컬로 지정하는 방법도 고려할 수 있다.

페이지스피드 인사이트

Thu, 01 Oct 2026 00:00:00 +0900

PageSpeed Insights의 랩 데이터는 특정 시점, 특정 네트워크 환경을 가정한 시뮬레이션 값이라 개발자의 로컬 환경에 따라 변동이 크지만, 필드 데이터는 실제 방문자들의 다양한 기기와 네트워크 환경에서 수집된 값이라 훨씬 신뢰도가 높다. 두 데이터가 크게 차이 난다면, 실제 사용자 상당수가 느린 네트워크나 저사양 기기를 쓰고 있다는 뜻이므로 이를 감안한 최적화가 필요하다는 신호로 해석해야 한다. API를 통해 정기적으로 수십~수백 개 URL을 자동 측정해 대시보드화하면 사이트 전반의 성능 추이를 지속적으로 모니터링할 수 있다.