해결된 질문
작성
·
21
0
안녕하세요. 배포 후 SEO 확인 과정에서 이해되지 않는 부분이 있어 질문드립니다.
[id].tsx
에서 동적 라우팅을 처리할 때, getStaticPaths
를 통해 id=1,2,3
에 해당하는 페이지는 빌드 시점에 SSG로 사전 렌더링되도록 설정하였고,
나머지 ID에 대해서는 fallback: true
를 사용해 첫 요청 시 SSR처럼 처리되는 것으로 이해했습니다.
또한 강의에서 router.isFallback
이 true
일 경우, SEO를 고려하여 <Head>
에 별도의 메타 정보를 넣어주는 분기 처리를 하신 것으로 알고 있습니다.
저는 이 분기 처리가 필요한 이유가, 해당 시점에는 실제 데이터가 포함된 HTML이 아직 완성되지 않았기 때문에 SEO 검사 도구나 크롤러에 최소한의 메타 정보를 제공하려는 의도라고 이해했습니다.
하지만 실제 배포된 결과를 확인해보니, id=1,2,3
외의 fallback으로 생성된 페이지들조차도
og:image 등 메타 정보가 정상적으로 노출되고 SNS 공유 시에도 커버 이미지가 잘 보이고 있습니다.
이런 경우, fallback으로 생성된 SSR 페이지임에도 불구하고 og 태그가 잘 노출되는 이유는 무엇인지 궁금합니다.
SEO 관점에서 이런 동작이 가능한 이유가 있다면 설명 부탁드립니다.
답변 1
0
안녕하세요 이정환입니다.
여기에는 여러가지 경우가 있을 것 같아요!
1) SSG로 이미 생성을 마친 상태에서 크롤러가 접근했다.
fallback 옵션이 설정되어 실시간으로 생성된 페이지도 한번 생성을 마친 이후에는 서버측에 캐시로 저장되어 SSG와 동일하게 동작합니다. 따라서 한번이라도 해당 경로로 요청이 있었다면 이 페이지의 OG 태그 등의 SEO 정보는 잘 수집됩니다.
2) 외부 서비스의 크롤러의 캐시 이슈
카카오톡이나 페이스북 등의 SNS 서비스는 특정 주소에 대한 OG 정보를 매번 수집하지 않고, 특정 주기로 캐싱 해 둡니다. 따라서 fallback을 적용하기 전 이미 캐싱된 OG 정보가 남아 있을지도 모릅니다! 이를 정확히 확인하시려면 카카오 디벨로퍼 사이트의 Open Graph 디버거에서 캐시 무효화를 진행해보시기 바랍니다.
답변 감사합니다!