JavaScript SEO: 링크가 렌더링을 견뎌내도록 하세요

크롤러가 보는 것

Googlebot은 2019년 5월부터 최신 Chromium을 사용해 왔습니다. 이는 현대적인 JavaScript를 실행할 수 있다는 의문을 해결했습니다.

실제적인 위험은 오래된 것입니다: 렌더링은 크롤링 이후에 발생하며 지연될 수 있고, 클릭이나 로그인 뒤에 있는 콘텐츠는 나타나지 않으며, div의 onclick 핸들러로 생성된 링크는 링크가 아닙니다. 최근에 React 프론트엔드로 이동한 웹사이트 페이지의 백링크를 확인하기 전에, 해당 페이지가 원본 응답이나 렌더링된 HTML에서 콘텐츠를 표시하는지 확인하십시오.

외부 링크의 역할

렌더링 버그는 콘텐츠를 숨길 수 있습니다. 다른 사이트에서 이미 제공한 링크를 지우지는 않습니다.

Next.js, Vite 또는 헤드리스 CMS로 이동한 후, 호스트에 대해 toppages를 실행하고 가장 많이 링크된 20개 URL의 상태, canonical 및 가시적 콘텐츠를 테스트하십시오. 먼저 수행하십시오. 40개 도메인에서 링크된 페이지가 빈 껍데기나 클라이언트 측 404를 반환하는 경우, 권한이 집중되는 곳이므로 다른 작업보다 먼저 수정하십시오. 내부 대 외부 평판 페이지는 이 목록을 내부 링크와 비교하는 방법을 보여주고, 마이그레이션 체크리스트는 테스트를 출시 계획에 포함시킵니다.

프레임워크는 규칙성보다 중요도가 낮습니다. 템플릿 엔진이 있는 Express, WordPress 테마 및 Next.js 앱 라우터 모두 크롤링 가능한 링크를 제공할 수 있습니다. 클릭 후에만 존재하는 앵커를 배포하면 모두 실패할 수도 있습니다.

검색 콘솔 증거 읽기

검색 콘솔은 올바른 보고서를 요청하면 대부분의 렌더링 질문에 답합니다. URL 검사를 사용한 후 '크롤링된 페이지 보기'를 사용하십시오.

세 가지 항목을 비교하십시오: Google이 가져온 HTML, 스크린샷, 로드되지 않은 페이지 리소스. 브라우저에서는 완성된 것처럼 보이지만 스크린샷에서는 빈 페이지인 경우, 일반적으로 스크립트 오류나 허용되지 않은 리소스로 인해 차단된 것이며, 수정은 콘텐츠가 아닌 빌드에서 이루어져야 합니다.

지연 시간을 기억하십시오. 오늘 배포한 변경 사항은 Google이 URL을 다시 크롤링할 때까지 검사 도구에 나타나지 않으며, 이는 며칠이 걸릴 수 있습니다.

서버 렌더링이 필요한가요, 아니면 사전 렌더링으로 충분한가요?

서버 렌더링은 선택 사항입니다. 이는 첫 번째 응답에 크롤러가 필요한 내용을 담는 방법입니다. 많은 공개 사이트는 사전 렌더링, 정적 빌드 또는 중요한 페이지에 대한 서버 렌더링을 통해 도달하며, 로그인된 부분은 그대로 둡니다.

제품 페이지와 문서가 공개되어 있고 대시보드가 로그인 뒤에 있다고 가정해 봅시다. 첫 번째 그룹을 사전 렌더링하십시오. 대시보드는 클라이언트 측으로 둡니다. 공개 페이지는 첫 번째 응답에 링크를 담게 되고, 대시보드는 필요한 만큼 복잡하게 유지할 수 있습니다.

홈 페이지만 사전 렌더링하기

홈 페이지를 사전 렌더링하면 첫 번째 크롤링은 해결되지만, 다른 모든 라우트는 브라우저의 대기 상태가 됩니다. 홈 페이지가 클라이언트 렌더링된 카테고리 페이지로 링크하는 경우, 해당 페이지의 링크는 여전히 렌더링에 의존합니다. 프런트 도어뿐만 아니라 소유한 모든 템플릿을 확인하십시오.

공개 라우트와 렌더링 방법을 짧은 목록으로 유지하십시오. 이 목록은 크롤링 보고서보다 훨씬 빠르게 격차를 보여줄 것입니다.

서버 렌더링이 로컬 가시성에 영향을 미치나요?

서버 렌더링은 첫 번째 콘텐츠가 나타나는 속도에 영향을 줄 수 있으며, 독자는 이를 느낍니다. 페이지 자체만으로는 지역 쿼리에 대한 관련성을 높이지 않습니다. 이러한 신호는 페이지 콘텐츠, 비즈니스 세부 정보 및 이를 가리키는 링크에서 나옵니다.

렌더링을 이러한 신호가 크롤러에게 읽히게 하는 방식으로 간주하고, API를 사용하여 링크를 별도로 측정하십시오.

하나의 셸을 제공하는 Vite 및 React 앱

모든 경로에 대해 하나의 HTML 셸을 제공하는 Vite 빌드는 모든 작업을 클라이언트에 맡깁니다. 이러한 앱은 일부 쿼리에 대해 랭킹될 수 있지만, 각 공개 라우트에는 계획이 필요합니다: 사전 렌더링하거나 서버에서 렌더링하거나 손실을 인정하고 이를 기록하십시오.

재빌드 후 웹사이트 라우트의 백링크를 확인하기 전에, 각 공개 라우트가 콘텐츠를 어떻게 얻는지 결정하십시오. 그렇지 않으면 링크 데이터가 내용이 없는 페이지에 외부 링크가 도달하는 것을 보여줄 것입니다.

라우트가 링크를 표시하는지 테스트하기

두 가지 테스트가 대부분의 질문에 답합니다. 원본 응답은 스크립트가 실행되기 전에 크롤러가 얻는 것을 보여줍니다. 렌더링된 DOM은 브라우저가 이후에 구축하는 것을 보여줍니다. 두 번째에서만 나타나는 링크는 여전히 링크이지만, 렌더링이 잘 이루어져야 합니다.

검색 콘솔의 라이브 테스트 읽기

URL 검사에서 라이브 테스트를 라우트별로 하나씩 실행하십시오. 렌더링된 HTML과 로드되지 않은 리소스 목록을 확인하십시오. 차단된 스크립트는 전체 네비게이션 블록을 제거할 수 있으며, 페이지는 눈에 띄는 오류 없이 얇게 보입니다.

프레임워크 업그레이드 후 테스트를 반복하십시오. 새로운 기본 설정이 스크립트 실행 전후에 링크가 렌더링되는지 여부를 변경할 수 있습니다. 인덱싱되지 않은 페이지 가이드는 렌더링된 페이지가 여전히 제외될 때 수행할 작업을 다룹니다.

라우트는 렌더링되지만 콘텐츠가 스피너인 경우

첫 번째 응답의 폴백은 대부분의 팀이 예상하는 것보다 중요합니다. 스피너나 빈 컨테이너는 페이지가 그 순간 크롤러에게 텍스트를 전달하지 않음을 의미합니다. 제목, 소개 및 주요 링크를 첫 번째 응답에 넣으십시오. 상세 목록이 나중에 로드되더라도 마찬가지입니다.

실제 페이지인 폴백은 단순하게 유지할 수 있습니다. 유일한 작업은 나머지 콘텐츠가 도착할 때까지 콘텐츠를 보유하는 것입니다.

클라이언트 측 앱의 상태 코드 및 리디렉션

단일 페이지 앱은 종종 서버가 상태 200을 반환하는 동안 '찾을 수 없음' 화면을 표시합니다. Google은 이러한 페이지를 소프트 404로 처리할 수 있으며, 누락된 URL을 가리키는 외부 링크는 거의 도움이 되지 않습니다. 수정은 서버에서 이루어져야 합니다.

200을 반환하는 알려지지 않은 라우트

존재하지 않는 모든 라우트에 대해 서버에서 실제 404를 반환하고, 클라이언트 측 라우트로 도착한 방문자를 위해 앱 내 '찾을 수 없음' 화면을 유지하십시오. 대체 경로가 있는 경우 대신 301을 보내십시오.

각 릴리스 후 실제 호스트에서 몇 가지 가상의 주소를 확인하십시오. 읽어야 할 것은 브라우저에서 보는 페이지가 아닌 응답 코드입니다.

브라우저에서 실행되는 리디렉션

페이지 로드 후에 발생하는 리디렉션(예: 구성 요소 내에서 URL 매개변수를 읽음)은 서버 리디렉션과는 다릅니다. 크롤러는 리디렉션이 실행되기 전에 첫 번째 응답을 인덱싱할 수 있습니다. 라우트가 영구적으로 이동한 경우 서버에서 301을 반환하고 콘텐츠를 변경하는 매개변수를 유지하십시오. 리디렉션 맵 레시피는 이러한 규칙을 테스트하는 방법을 보여줍니다.