사이트를 공들여 만들었는데, 막상 검색 결과에는 좀처럼 보이지 않는 경우가 있습니다. 콘텐츠의 질은 분명 괜찮고 디자인도 깔끔한데 왜일까요? 대부분은 소위 “기술적 SEO(Technical SEO)” 영역에서 사소해 보이지만 치명적인 실수들이 쌓인 탓입니다. 마케팅 팀이 아무리 좋은 글을 올려도 크롤러가 페이지를 제대로 읽지 못하면 무용지물이죠.
이 글은 실무에서 자주 마주치는 기술적 SEO 실수 20가지를 개발자 시각으로 정리했습니다. 각 항목마다 무엇이 문제이고 어떻게 고쳐야 하는지, 실제 코드와 설정 예시를 함께 달아 두었으니 체크리스트처럼 활용해 보세요.ß
기술적 SEO, 쉽게 이해하기
기술적 SEO는 “검색엔진 크롤러가 내 사이트를 얼마나 쉽게 읽고 이해할 수 있는가”를 다루는 분야입니다. 비유하자면 도서관의 분류 체계와 같습니다. 아무리 좋은 책이 있어도 서가에 무작위로 꽂혀 있고 목록도 없다면, 사서(크롤러)가 원하는 책을 찾아 독자에게 전달하기 어렵습니다. 기술적 SEO는 바로 그 서가 정리와 도서 목록을 관리하는 일입니다.
콘텐츠 SEO(글의 내용·키워드)와 달리 기술적 SEO는 HTML 구조, 서버 설정, 페이지 속도, URL 체계 등 개발자가 직접 컨트롤할 수 있는 영역입니다. 그래서 개발자가 이 부분을 이해하면 그 어떤 SEO 컨설팅보다 빠른 개선이 가능합니다.
시작 전 확인할 도구와 환경
- Google Search Console – 크롤링 오류, 색인 상태, Core Web Vitals 확인
- Screaming Frog SEO Spider (무료 500URL) – 사이트 전체 크롤링 분석
- PageSpeed Insights / Lighthouse – 성능 및 접근성 측정
- Ahrefs / Semrush Site Audit (유료) – 체계적 기술 감사
- 개발 환경에
robots.txt,.htaccess또는nginx.conf편집 권한 - 사이트 배포 전후 비교를 위한 스테이징 환경 권장
주의: robots.txt, 리디렉션, noindex 설정은 잘못 적용하면 페이지 전체가 검색에서 사라질 수 있습니다. 반드시 스테이징 환경에서 먼저 테스트하세요.
실수 1~5: 크롤링과 색인 설정 오류
1. robots.txt로 중요한 페이지를 차단하는 실수
개발 중 편의를 위해 전체 사이트를 막아 두었다가, 배포 후 robots.txt를 원래대로 되돌리는 것을 잊는 경우가 종종 있습니다. 크롤러는 차단된 URL을 색인에 포함시키지 않으므로 사이트 전체가 검색 결과에서 사라질 수 있습니다.
# 잘못된 예 – 전체 차단 상태로 배포됨
User-agent: *
Disallow: /
# 올바른 예 – 관리자 페이지만 차단
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap.xml흔한 실수: 워드프레스의 “검색 엔진이 이 사이트를 색인하지 못하도록 하기” 옵션을 개발 중에 켜 두었다가 배포 후 해제를 잊는 것입니다. 설정 → 읽기 화면에서 반드시 확인하세요.
2. noindex 태그 남용
태그 페이지, 날짜 아카이브, 검색 결과 페이지 등에는 noindex가 적절하지만, 중요한 랜딩 페이지나 서비스 페이지에 실수로 붙이면 색인에서 제외됩니다.
<!-- 중요한 페이지에 noindex 적용 시 검색 결과에서 제외됨 -->
<meta name="robots" content="noindex, nofollow">
<!-- 일반 페이지에는 index 허용 -->
<meta name="robots" content="index, follow">3. 정규(canonical) URL 미설정 또는 잘못 설정
같은 콘텐츠가 https://example.com/page와 https://example.com/page/, https://www.example.com/page 등 여러 URL로 접근 가능하면 크롤러는 어느 것이 “원본”인지 혼란스러워 PageRank가 분산됩니다.
<!-- 각 페이지의 <head>에 정규 URL 선언 -->
<link rel="canonical" href="https://example.com/page" />4. HTTP와 HTTPS 혼용 (Mixed Content)
HTTPS 페이지 내에서 이미지, 스크립트, 폰트 등을 HTTP로 로드하면 브라우저 경고가 발생하고 크롤러 신뢰도도 낮아집니다. 모든 리소스 경로를 프로토콜 상대 URL(//) 또는 명시적 HTTPS로 통일하세요.
5. www / non-www 미통일
둘 다 접근 가능한 상태로 두면 중복 콘텐츠로 간주됩니다. 서버 수준에서 301 리디렉션으로 하나로 통일해야 합니다.
# Nginx – www → non-www 301 리디렉션
server {
listen 80;
server_name www.example.com;
return 301 https://example.com$request_uri;
}실수 6~10: URL 구조와 리디렉션 문제
6. 의미 없는 URL 파라미터 남용
/product?id=4829&session=abc123&ref=email 같은 URL은 크롤러에게 의미 없는 노이즈입니다. 가능하면 슬러그 기반의 정적 URL로 구성하고, 추적 파라미터는 Google Search Console의 URL 파라미터 도구에서 관리하세요.
7. 리디렉션 체인(Redirect Chain)
A → B → C → D처럼 여러 번 리디렉션되면 크롤러가 매번 PageRank를 조금씩 잃고 페이지 로드도 느려집니다. 항상 출발지에서 최종 목적지로 바로 연결하는 것이 원칙입니다.
// WordPress에서 단일 301 리디렉션 (함수 예시)
function single_redirect() {
if ( is_page( 'old-page' ) ) {
wp_redirect( home_url( '/new-page/' ), 301 );
exit;
}
}
add_action( 'template_redirect', 'single_redirect' );8. 302 리디렉션을 영구 이동에 사용
302는 “임시” 이동이라 기존 PageRank가 새 URL로 넘어가지 않습니다. 페이지를 영구적으로 이동할 때는 반드시 301을 사용하세요.
9. URL에 대문자·특수문자 혼용
일부 서버는 /My-Page와 /my-page를 별도 URL로 처리합니다. 모든 URL은 소문자, 하이픈(-) 구분자로 통일하는 것이 모범 사례입니다.
10. 깊은 URL 구조 (Crawl Depth)
중요한 페이지가 클릭 4회 이상 depth에 있으면 크롤러가 발견하지 못할 수 있습니다. 중요 페이지는 3 depth 이내, 가능하면 내부 링크로 홈에서 가까운 경로를 만들어 주세요.
실수 11~15: 페이지 속도와 Core Web Vitals
11. 이미지 최적화 미흡
비압축 PNG나 JPEG 이미지를 그대로 사용하면 LCP(Largest Contentful Paint) 점수가 떨어집니다. WebP 또는 AVIF 형식으로 변환하고, loading="lazy" 속성과 함께 적절한 srcset을 설정하세요.
<!-- 반응형 이미지 + 지연 로딩 -->
<img
src="hero.webp"
srcset="hero-480.webp 480w, hero-960.webp 960w, hero-1440.webp 1440w"
sizes="(max-width: 600px) 480px, (max-width: 1200px) 960px, 1440px"
alt="서비스 소개 히어로 이미지"
width="1440" height="720"
loading="lazy">12. 렌더링 차단 리소스 (Render-Blocking Resources)
<head>에 무거운 CSS와 JS를 동기 방식으로 로드하면 FCP(First Contentful Paint)가 늦어집니다. 중요하지 않은 JS는 defer 또는 async를 붙이고, 중요하지 않은 CSS는 미디어 쿼리로 지연 로드하세요.
<!-- ✅ JS 지연 로드 -->
<script src="analytics.js" defer></script>
<!-- ✅ 중요하지 않은 CSS 지연 로드 -->
<link rel="preload" href="non-critical.css" as="style" onload="this.rel='stylesheet'">13. 미사용 JavaScript/CSS 미제거
jQuery 플러그인이나 사용하지 않는 CSS 라이브러리가 쌓이면 번들 크기가 불어납니다. Lighthouse의 “Remove unused JavaScript” 권고 항목을 주기적으로 확인하고, 빌드 도구(webpack, Vite 등)의 tree-shaking을 활용하세요.
14. CLS(Cumulative Layout Shift) 유발 요소
광고, 이미지, 동적으로 삽입되는 배너가 로드되면서 기존 콘텐츠를 밀어내면 CLS 점수가 올라갑니다. 이미지와 광고 컨테이너에는 고정 너비/높이를 지정하거나 aspect-ratio CSS로 공간을 미리 확보하세요.
15. 서버 응답 시간(TTFB) 느림
TTFB가 200ms를 넘으면 구글은 페이지 경험 점수를 낮게 평가합니다. CDN 도입, 적절한 서버 캐싱, 데이터베이스 쿼리 최적화가 핵심입니다. 워드프레스라면 객체 캐시(Redis/Memcached)와 페이지 캐시 플러그인을 함께 사용하세요.
실수 16~20: 구조화 데이터와 기타 마크업 오류
16. 구조화 데이터(Schema) 미사용 또는 오류
FAQ, 제품, 리뷰, 이벤트 등에 Schema.org JSON-LD를 적용하면 리치 스니펫으로 클릭률이 올라갑니다. 하지만 잘못된 스키마는 오히려 Search Console에서 오류로 분류됩니다. 구글 리치 결과 테스트로 반드시 검증하세요.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "기술적 SEO가 왜 중요한가요?",
"acceptedAnswer": {
"@type": "Answer",
"text": "크롤러가 페이지를 제대로 읽고 색인할 수 있어야 검색 결과에 노출됩니다."
}
}]
}17. Open Graph / Twitter Card 메타 태그 누락
소셜 공유 시 제목, 이미지, 설명이 올바르게 표시되지 않으면 클릭률이 낮아집니다. 간접적으로 사이트 트래픽과 SEO 신호에 영향을 줍니다.
18. XML Sitemap 미제출 또는 오래된 Sitemap
Sitemap에 삭제된 URL, noindex 페이지, 리디렉션 URL이 포함되면 크롤 예산이 낭비됩니다. 사이트 구조 변경 후 반드시 Search Console에서 새 Sitemap을 제출하세요.
19. Hreflang 설정 오류 (다국어 사이트)
다국어 사이트에서 hreflang이 빠지거나 상호 참조가 불완전하면 잘못된 언어 버전이 검색 결과에 노출됩니다. 모든 언어 버전이 서로를 참조하는 양방향 설정이 필수입니다.
20. 404 오류 페이지 방치와 깨진 내부 링크
삭제된 페이지로 가는 내부 링크가 쌓이면 크롤 예산이 낭비되고 사용자 경험도 나빠집니다. Screaming Frog 등으로 정기적으로 깨진 링크를 점검하고, 적절한 301 리디렉션 또는 링크 수정으로 처리하세요.
항목별 우선순위 정리
| 실수 항목 | 영향 범위 | 수정 난이도 | 우선순위 |
|---|---|---|---|
| robots.txt 전체 차단 | 전체 사이트 | 낮음 | 🔴 긴급 |
| noindex 남용 | 개별 페이지 | 낮음 | 🔴 긴급 |
| canonical URL 미설정 | 중복 페이지 | 낮음 | 🟠 높음 |
| HTTPS 미통일 / Mixed Content | 전체 사이트 | 중간 | 🟠 높음 |
| 리디렉션 체인 | 이동된 페이지 | 중간 | 🟠 높음 |
| 이미지 최적화 미흡 | LCP / 속도 | 중간 | 🟡 보통 |
| 렌더링 차단 리소스 | FCP / 속도 | 중간 | 🟡 보통 |
| 구조화 데이터 오류 | 리치 스니펫 | 낮음 | 🟡 보통 |
| Sitemap 미제출/오류 | 크롤 효율 | 낮음 | 🟡 보통 |
| 깨진 내부 링크 | 크롤 예산 | 낮음 | 🟢 낮음 |
현업에서 바로 쓰는 실무 팁 5가지
팁 1. 배포 체크리스트에 SEO 항목 추가하기
CI/CD 파이프라인에 robots.txt, noindex 메타 태그, canonical URL 확인 스텝을 포함시키면 배포 실수를 원천 차단할 수 있습니다.
팁 2. Lighthouse를 로컬 빌드에 연동하기lighthouse-ci를 GitHub Actions에 연결하면 PR 단계에서 성능 점수 저하를 바로 탐지할 수 있습니다.
팁 3. 월 1회 Search Console 크롤링 오류 점검
“Coverage” 리포트에서 Excluded, Error 항목을 정기적으로 확인하고 신규 오류가 생기면 알림을 설정해 두세요.
팁 4. 리디렉션 맵 스프레드시트 관리
사이트 리뉴얼 전후 모든 URL 매핑을 스프레드시트로 관리하면 누락 리디렉션을 방지하고 팀 간 커뮤니케이션도 쉬워집니다.
팁 5. 이미지 파이프라인에 WebP 자동 변환 추가
WordPress라면 Imagify, ShortPixel 같은 플러그인으로, Node.js 프로젝트라면 sharp 라이브러리로 업로드 시 자동 WebP 변환을 적용하세요.
적용 후 확인 방법
수정 작업을 마쳤다면 아래 순서로 결과를 검증하세요.
- Google Search Console → URL 검사 도구: 수정된 페이지의 색인 상태와 크롤링 가능 여부를 개별 확인
- PageSpeed Insights: Core Web Vitals(LCP, FID/INP, CLS) 개선 여부 확인
- Screaming Frog: 전체 사이트 재크롤링 후 404, 리디렉션 체인, canonical 오류 재점검
- Rich Results Test: 구조화 데이터 적용 페이지의 스키마 유효성 검증
- Ahrefs / Semrush Site Audit (선택): 개선 전후 오류 수치 비교
- 수정 후 2~4주는 색인 반영 대기 시간이 필요하므로 Search Console 데이터를 장기 추이로 모니터링하세요.
자주 묻는 질문
Q1. robots.txt로 차단하면 noindex와 차이가 있나요?
네, 큰 차이가 있습니다. robots.txt 차단은 크롤러가 페이지를 아예 방문하지 않으므로 noindex 태그를 읽지도 못합니다. 이미 색인된 페이지를 제외하려면 noindex를 사용하고, 크롤 자체를 막으려면 robots.txt를 사용하세요.
Q2. canonical 태그를 모든 페이지에 다 달아야 하나요?
이상적으로는 그렇습니다. 모든 페이지에 자기 자신을 canonical로 선언하면 예상치 못한 중복 콘텐츠 문제를 예방할 수 있습니다. 워드프레스 SEO 플러그인(Yoast, RankMath)이 자동으로 처리해 줍니다.
Q3. 리디렉션이 많으면 SEO에 얼마나 나쁜가요?
301 리디렉션 한 번은 PageRank 손실이 미미합니다. 하지만 체인이 길어지거나 302를 잘못 쓰면 손실이 누적됩니다. 단일 301로 정리하는 것이 최선입니다.
Q4. PageSpeed 점수가 낮은데 꼭 90점 이상이어야 하나요?
점수 자체보다 실제 사용자 경험 지표(Core Web Vitals의 “Good” 기준)가 더 중요합니다. LCP 2.5초 이하, CLS 0.1 이하, INP 200ms 이하를 목표로 삼으세요.
Q5. 구조화 데이터를 달면 리치 스니펫이 무조건 나오나요?
아닙니다. 유효한 스키마를 적용해도 구글이 리치 스니펫을 노출할지는 구글의 재량입니다. 다만 적용하지 않으면 노출 기회 자체가 없으므로 적용하는 것이 유리합니다.
Q6. 소규모 사이트는 Sitemap이 꼭 필요한가요?
페이지 수가 적더라도 Sitemap을 제출해 두면 크롤러가 새 페이지를 더 빠르게 발견합니다. 특히 신규 도메인이거나 내부 링크 구조가 약한 경우 Sitemap의 효과가 큽니다.
마무리 – 지금 바로 확인할 체크리스트
기술적 SEO는 한 번 설정하고 끝나는 것이 아니라, 사이트가 성장하고 변경될 때마다 지속적으로 점검해야 합니다. 이 글에서 다룬 20가지 실수 중 하나라도 현재 사이트에 해당된다면, 오늘 바로 수정을 시작해 보세요. 콘텐츠 품질이 뒷받침된다면 기술적 SEO 개선만으로도 검색 노출이 의미 있게 늘어나는 경우가 많습니다.
오늘 할 수 있는 빠른 점검 목록:
- robots.txt 에서 중요 페이지가 차단되어 있지 않은지 확인
- Search Console에서 noindex 오류 페이지 목록 확인
- canonical URL이 전 페이지에 올바르게 선언되어 있는지 확인
- HTTP → HTTPS 리디렉션 및 www/non-www 통일 여부 확인
- Lighthouse로 Core Web Vitals 점수 측정
- Sitemap이 Search Console에 등록되어 있는지 확인
- 주요 페이지에 구조화 데이터(JSON-LD) 적용 및 검증
- 깨진 내부 링크 점검 (Screaming Frog 활용)