테크니컬 SEO —
읽을 수 없는 사이트는
평가받지 못합니다

A 렌더링 방식, URL 형식과 canonical, 상태코드와 리다이렉트, 사이트맵과 실제 응답의 일치, 모바일과 Core Web Vitals, 시맨틱 HTML과 접근성을 점검합니다. 공통점은 전부 기계가 사이트를 읽고 처리하는 과정에 관한 항목이라는 것입니다. 무엇을 쓸 것인가는 콘텐츠 SEO에서, 색인 제출과 색인 상태 확인, 사이트맵 lastmod 운영은 색인 영역에서 다룹니다.

A 본문이 스크립트 실행 후에만 나타나는 구조라면 불리할 수 있습니다. 검색엔진과 달리 AI 수집기 상당수는 스크립트를 실행하지 않아, 그런 사이트는 본문 없는 문서로 읽힐 수 있기 때문입니다. 확인은 간단합니다 — 브라우저에서 스크립트를 끄고 페이지를 열어 본문이 남는지 보면 됩니다. 프레임워크를 바꾸지 않아도 서버 렌더링이나 사전 렌더링으로 해결되는 경우가 많습니다.

A 어느 쪽이든 상관없고, 섞이지 않는 것이 중요합니다. 정하는 방법은 취향이 아니라 확인입니다 — 두 형식을 각각 요청해 호스팅이 어느 쪽에 200을 주고 어느 쪽을 리다이렉트하는지 보고, 200이 나오는 형식을 기준으로 삼습니다. 그다음 canonical · 사이트맵 · 구조화 데이터 · 내부 링크를 전부 그 문자열에 맞추고, 새 페이지에서 다시 갈라지지 않게 주소를 만드는 코드를 한 곳으로 모읍니다.

A 한 번에 끝나는 항목과 계속 되돌아오는 항목이 나뉩니다. URL 형식 규칙이나 렌더링 방식처럼 구조를 정하는 결정은 한 번 확정하면 유지되지만, 리다이렉트 체인·소프트 404·사이트맵 누락은 페이지를 옮기거나 지울 때마다 새로 생깁니다. 그래서 마지막 단계에서 배포마다 볼 점검 목록을 남기고, 사이트 개편이나 도메인 변경처럼 구조가 흔들리는 시점에는 01단계부터 다시 재는 것을 권합니다.

A 순위 상승을 약속할 수 없습니다. 속도와 안정성은 검색엔진이 보는 여러 신호 중 하나이고, 순위는 콘텐츠와 신뢰 신호를 포함한 많은 요인으로 결정되기 때문입니다. 다만 렌더를 막는 리소스를 걷어내면 사용자가 내용을 보기까지 기다리는 시간이 줄고, 화면이 잡힌 뒤 밀리는 현상도 함께 사라집니다. 이는 점수와 무관하게 그 자체로 얻는 결과입니다. 나비랑은 점수를 목표로 잡는 대신 적용 전후를 같은 조건에서 측정해 무엇이 얼마나 바뀌었는지 기록으로 남깁니다.

A 인용되지는 않습니다. 기술 점검은 답변엔진이 사이트를 읽을 수 있게 만드는 전제 조건이지 인용의 이유가 되지는 못합니다. 나비랑 자사 점검에서도 기술 항목은 전부 통과였지만, 그 사실이 알려 준 것은 문제가 다른 층에 있다는 것뿐이었습니다. 읽을 수 있게 만든 다음에는 답이 되는 문서와 신뢰 신호가 필요합니다.

A 가능합니다. 점검 결과를 개발 조직이 그대로 받아 작업할 수 있는 변경 명세서로 전달하고, 적용 후 같은 항목을 다시 측정해 전후를 비교합니다. 코드 접근 권한을 주시면 나비랑이 직접 처리하는 범위를 나눠 진행할 수도 있으며, 어느 쪽이든 착수 전에 담당 범위를 문서로 나눠 둡니다.