웹사이트가 아름다운 디자인과 SEO 플러그인의 초록색 원을 갖추고 있어도, 주요 콘텐츠가 로드되기 전에 사용자를 잃을 수 있습니다. 또는 Google이 예상한 URL과 다른 URL을 색인에 포함할 수도 있습니다. 주문은 정상적으로 처리되지만 측정 데이터가 두 번 전송될 수도 있습니다.
그래서 저는 기술 감사를 시작할 때 단일 테스트에서 100점을 받는 것부터 추구하지 않습니다. 먼저 비즈니스 운영, 색인 생성 또는 웹사이트 사용을 방해하는 오류를 찾습니다. 그런 다음에야 작은 세부 사항을 다듬습니다.
1. 중요한 URL이 올바른 상태 코드를 반환하는지 확인합니다
주요 서비스 페이지, 트래픽을 받는 문서, 연락처 페이지 및 전환 경로를 검토합니다. 중요한 페이지는 200 을 반환해야 합니다. 영구적으로 이동한 콘텐츠에는 직접 연결되는 301 리디렉션이 하나만 있어야 합니다. 삭제된 페이지가 조용히 홈페이지로 연결되어서는 안 됩니다.
HTTP와 HTTPS, www와 non-www 변형, 후행 슬래시 및 매개변수도 확인합니다. 결과는 하나의 표준 URL이어야 합니다. Google은 리디렉션을 강력한 표준화 신호로 설명하며, 표준 URL 및 사이트맵을 일관되게 함께 사용하라고 표준 URL 관련 문서에서 권장합니다.
2. 실제 페이지의 관점에서 색인 생성을 확인합니다
Robots.txt, 메타 로봇, 표준 URL 및 사이트맵은 함께 작동해야 합니다. 흔한 실수는 검색에 필요하지 않은 페이지는 색인에 포함하면서 중요한 콘텐츠는 차단하는 것입니다. Search Console의 URL 검사를 여러 대표 URL에 사용합니다. 이 도구는 Google이 페이지에 대해 알고 있는 내용을 보여 주고 실제 버전을 테스트할 수 있게 합니다.
- 표준 URL이 원하는 URL인가요?
- 로그인이나 차단 없이 페이지에 접근할 수 있나요?
- 사이트맵에는 색인 생성이 가능한 URL이 200 개만 포함되어 있나요?
- 내부 링크가 리디렉션을 피하고 있나요?
- 중요한 페이지가 고립되어 있나요?
Google은 크롤링 및 색인 생성에 관한 문서에서 이러한 영역을 개괄적으로 설명합니다.
3. 실험실뿐 아니라 사람을 기준으로 속도를 측정합니다
PageSpeed Insights와 Lighthouse는 유용한 진단 도구입니다. 하지만 실험실 테스트는 실제 방문자의 경험과 같지 않습니다. 현재 Core Web Vitals는 LCP, INP 및 CLS이며, 필드 데이터는 실제 기기와 연결 환경을 사용합니다. 공식 Web Vitals 문서에서 개요와 필드 데이터와 실험실 데이터의 차이를 설명합니다.
우선순위는 다음과 같이 봅니다.
- LCP: 주요 콘텐츠가 표시되는 시점입니다.
- INP: 페이지가 사용자의 동작에 얼마나 빠르게 반응하는지 보여 줍니다.
- CLS: 로드 중 요소가 움직이는지를 나타냅니다.
- TTFB 및 네트워크: 무언가가 빠르게 시작되는지 여부를 보여 줍니다.
Google은 좋은 점수가 최상위 순위를 보장하지 않는다는 점도 분명히 밝힙니다. 하나의 숫자를 좇는 것보다 전반적인 사용성이 더 중요합니다. 페이지 경험 관련 문서를 참고하세요.
4. 로딩의 실제 원인을 찾습니다
워터폴과 DevTools에서 긴 서버 응답 시간, 렌더링을 차단하는 CSS와 JavaScript, 지나치게 큰 이미지, 글꼴, 반복 요청 및 서드파티 요소를 찾습니다. 모든 파일을 결합하라는 예전 규칙은 더 이상 보편적으로 적용되지 않습니다. 최신 프로토콜에서는 사용되지 않는 코드의 양과 메인 스레드를 차단하는 요소가 더 중요할 수 있습니다.
- 주요 이미지를 적절한 크기와 최신 형식으로 로드합니다.
- 콘텐츠가 움직이지 않도록 이미지 크기를 지정합니다.
- 첫 번째 뷰포트 아래의 콘텐츠에는 네이티브 지연 로딩을 사용할 수 있습니다.
- 필요한 글꼴 굵기와 문자 세트만 로드합니다.
- 마케팅 스크립트는 비동기 방식으로 로드하고 필요한 곳에서만 사용합니다.
- 텍스트 리소스를 압축하고 버전이 지정된 파일에는 긴 캐시 기간을 설정합니다.
서드파티 요소는 밀리초 단위의 속도만 고려해 비용이 발생하는 것이 아닙니다. 모든 픽셀, 채팅 위젯 및 히트맵은 추가적인 운영 및 데이터 관리 책임을 만듭니다. 아무도 보고서를 사용하지 않는다면 스크립트를 제거합니다.
5. 키보드와 휴대전화로 고객의 입장에서 웹사이트를 이용합니다
모바일에서 탐색 메뉴, 양식, 쿠키 대화상자 및 주문 과정을 확인합니다. 텍스트를 확대하고 이미지를 비활성화한 뒤 키보드를 사용합니다. 제목은 이해하기 쉬운 구조를 형성해야 하며, 양식에는 레이블이 필요하고 오류 메시지에는 무엇을 수정해야 하는지가 명시되어야 합니다.
모든 페이지에는 주요 작업이 있어야 합니다. 그렇다고 어떤 대가를 치르더라도 버튼 하나만 있어야 한다는 뜻은 아니며, 명확한 계층 구조가 필요하다는 의미입니다. 기본 UX 체크리스트에서 더 실용적인 항목을 확인하세요.
6. 리소스 및 JavaScript 오류를 수정합니다
이미지, 글꼴 또는 스크립트에 대한 404 오류는 단순한 외관상의 문제가 아닙니다. 화면 표시, 측정 또는 기능을 망가뜨릴 수 있습니다. 브라우저 콘솔 오류, 실패한 네트워크 요청 및 서버에서 반복되는 5xx 응답을 확인합니다. 배포할 때마다 중요한 경로를 테스트합니다.
7. 사실에 맞는 콘텐츠에만 구조화된 데이터를 사용합니다
Schema는 별점 표시를 강제로 적용하는 방법이 아닙니다. 실제로 페이지에 있는 내용을 기계가 읽을 수 있도록 설명하는 방식입니다. 지원되는 유형을 사용하고 Rich Results Test에서 테스트합니다. Google은 구조화된 데이터 관련 문서에서 현재 지원되는 형식과 테스트 도구를 안내합니다.
8. 측정하려는 웹사이트를 측정 도구가 망가뜨려서는 안 됩니다
GA4, 광고 플랫폼 및 기타 스크립트를 렌더링을 차단하지 않는 방식으로 로드합니다. 모든 클릭이 아니라 의사결정에 맞춰 이벤트 이름을 지정합니다. 중복 전송, 동의 여부 및 실제로 누군가 데이터를 사용하는지를 확인합니다. Google Tag Manager 및 Google Analytics 4 관련 문서에서 실용적인 기반을 마련할 수 있습니다.
9. 비용과 위험이 수정 순서를 결정합니다
- 작동하지 않는 주문, 양식 또는 로그인.
- 접근할 수 없거나 색인 생성이 불가능한 중요한 페이지.
- 보안 문제 및 오래된 구성 요소.
- 심각한 모바일 사용성 및 Core Web Vitals 문제.
- 잘못된 의사결정으로 이어지는 측정 오류.
- 그 이후에야 낮은 점수와 외관상의 문제를 처리합니다.
기술 SEO는 출발선입니다. 기술 SEO만으로 경주에서 이길 수는 없지만, 웹사이트가 고장 나 있으면 출발 신호가 울리기도 전에 경주에서 질 수 있습니다. 기술적 발견 사항을 비즈니스 우선순위로 전환해야 한다면, 웹사이트와 현재 직면한 의사결정을 설명해 주세요.