SEO 업무 시간, 2022년 6월 3일

2022년 6월 3일 John Mueller 와 함께한 Google SEO Office Hours 에서 가장 흥미로운 질문과 답변을 요약한 것입니다 .

한 페이지에 두 개의 HTTP 결과 코드를 사용할 수 있습니까?

1:22 “[...] 이론적으로 한 페이지에 두 개의 다른 HTTP 결과 코드가 있을 수 있지만 Google은 이 두 코드로 무엇을 할까요? 구글이 그들을 볼 수 있을까? 그렇다면 Google은 무엇을 할 것입니까? 예를 들어 503에 302를 더한 것입니다.”

John의 응답은 다음과 같습니다. “[…] HTTP 결과 코드를 사용하면 다양한 항목을 포함할 수 있습니다. Google은 첫 번째 HTTP 결과 코드 를 보고 기본적으로 이를 처리합니다.

그리고 이론적으로 최종 페이지로 연결 되는 리디렉션인 경우 두 개 이상의 HTTP 결과 코드를 가질 수 있습니다 . 예를 들어 한 페이지에서 다른 페이지로 리디렉션할 수 있습니다. 하나의 결과 코드입니다. 그런 다음 다른 페이지에서 다른 결과 코드를 제공할 수 있습니다. 따라서 404 페이지로의 301 리디렉션 […]이 될 수 있습니다. 그리고 우리의 관점에서 최종 결과를 얻기 위해 리디렉션을 따를 수 있는 체인 상황에서는 기본적으로 최종 결과에만 집중할 것입니다.

그리고 그 최종 결과에 내용이 있다면, 그것은 우리가 정규화에 사용할 수 있는 것입니다. 최종 결과가 오류 페이지인 경우 오류 페이지입니다. 그리고 그것은 우리에게도 좋습니다.”

내 사이트가 내 주요 국가에서 이미 빠른 경우 CDN을 사용하면 순위가 향상됩니까?

2:50 “[…] 트래픽의 대부분은 특정 국가에서 가져옵니다. 우리는 해당 국가에 위치한 서버에서 웹사이트를 호스팅했습니다. 전 세계 사용자의 페이지 속도를 향상시키기 위해 전체 웹 사이트를 CDN 뒤에 두는 것이 좋습니까? 아니면 우리의 경우에는 필요하지 않습니까?”

John은 다음과 같이 대답했습니다. “ SEO와 관련하여 Google에 큰 영향을 미칠 것이라고는 생각하지 않습니다.

내가 상상할 수 있는 유일한 효과는 사용자가 보게 되는 결과뿐입니다. […] 서버가 거기에 있기 때문에 대다수의 사용자가 이미 매우 빠른 웹사이트를 보고 있다면 […] 옳은 일을 하고 있는 것입니다. 그러나 물론 다른 위치의 사용자가 매우 느린 결과를 보고 있다면 아마도 귀하의 국가와의 연결이 그다지 좋지 않기 때문에 이를 개선할 기회가 있을 수 있습니다.

[...] 귀하의 웹사이트를 전 세계적으로 개선하기 위해 할 수 있는 일이 있다면 좋은 생각이라고 생각합니다. 나는 그것이 중요하다고 생각하지 않습니다[…]. 그러나 현재 국가를 넘어 웹 사이트를 성장시키기 위해 […] 할 수 있는 일입니다.

분명히 해야 할 한 가지는 Google의 크롤링이 정말, 정말 느리다면 당연히 웹사이트에서 크롤링하고 색인을 생성할 수 있는 양에 영향을 미칠 수 있다는 것입니다 […]. 수백만 페이지가 아닌 […

Search Console에서 Google이 크롤링하는 속도와 크롤링 통계를 다시 확인할 수 있습니다. 그리고 그것이 합리적으로 보인다면, 그것이 초고속이 아니더라도 나는 그것에 대해 별로 걱정하지 않을 것입니다.”

크롤링을 줄이기 위해 API 요청을 허용하지 않아야 합니까?

5:20 “[…] 우리 사이트는 현재 크롤링 예산의 약 20%를 API 하위 도메인에 사용하고 있으며 또 다른 20%는 동영상의 이미지 축소판에 사용하고 있습니다. 이러한 하위 도메인에는 SEO 전략의 일부인 콘텐츠가 없습니다. 이러한 하위 도메인의 크롤링을 허용하지 않아야 합니까? 아니면 API 끝점을 어떻게 검색하거나 사용합니까?”

John이 말했듯이 "[...] 많은 경우 API 엔드포인트는 웹사이트의 JavaScript에 의해 사용되며 우리는 귀하의 페이지를 렌더링합니다. 그리고 그들이 귀하의 웹사이트에 있는 API에 액세스하면 해당 API에서 콘텐츠를 로드하여 페이지 렌더링에 사용하려고 합니다.

API 설정 방법과 JavaScript 설정 방법에 따라 해당 API 결과를 캐시하기 어려울 수 있습니다. 즉, 렌더링된 버전을 얻기 위해 이러한 API 요청을 많이 크롤링할 수 있습니다. 인덱싱에 사용할 수 있습니다. 그래서 일반적으로 이것이 발견되는 곳입니다. API […]에 JavaScript를 사용할 때 URL에 타임스탬프를 삽입하지 않고 […]

이러한 API 끝점과 함께 반환되는 콘텐츠에 신경 쓰지 않는다면 물론 robots.txt 파일을 사용하여 이 전체 하위 도메인이 크롤링되는 것을 차단할 수 있습니다. 그리고 이는 본질적으로 모든 API 요청이 발생하는 것을 차단합니다.

[...] 먼저 이 API 결과가 [...] 내가 Google에서 색인을 생성하고 싶은 중요한 콘텐츠의 일부인지 파악해야 합니다. 그렇다면 크롤링을 차단해서는 안 됩니다. 그러나 [...] 페이지에 중요하지 않은 [...] 무언가를 생성하는 경우 [...] 차단되었을 때 어떻게 보이는지 다시 확인하는 것이 좋습니다.

그리고 이것을 다시 확인할 수 있는 한 가지 방법은 API를 호출하지 않거나 API 엔드포인트에 대해 깨진 URL을 사용하는 별도의 테스트 페이지를 생성할 수 있는지 여부입니다. [...] 이 페이지가 내 브라우저에서 실제로 어떻게 렌더링되는지 볼 수 있습니까? Google에서는 어떻게 렌더링되나요?”

내부 링크에 rel=”nofollow”를 사용해야 합니까?

8:05 "크롤링 또는 색인 생성을 원하지 않는 URL에 대한 불필요한 크롤러 요청을 피하기 위해 내부 링크에 nofollow 속성을 사용하는 것이 적절합니까?"

John이 다음과 같이 응답한 방법은 다음과 같습니다. “[...] 대부분의 경우 내부 링크에서 nofollow를 사용하는 것은 거의 의미가 없다고 생각합니다. 그러나 그것이 당신이 하고 싶은 일이라면, 그것을 위해 가십시오.

대부분의 경우 rel=canonical 을 사용하여 색인을 생성하려는 URL을 가리키거나 실제로 크롤링하고 싶지 않은 항목에 robots.txt를 사용하는 등의 작업을 시도합니다.

인덱싱하고 rel=canonical을 사용하는 것을 선호하는 미묘한 [...] 같은 것인지 알아내십시오. 아니면 실제로 Googlebot이 이러한 URL에 액세스할 때 내 서버에 문제가 발생한다고 말씀하신 것입니다. 큰 부하의 원인이 됩니다. 그것은 모든 것을 정말 느리게 만듭니다. 그것은 비싸거나 당신이 무엇을 가지고 있습니다.

이러한 경우에는 해당 URL의 크롤링을 허용하지 않습니다. […] rel=canonical을 사용하면 분명히 rel=canonical을 보기 위해 해당 페이지를 먼저 크롤링해야 합니다. 그러나 시간이 지남에 따라 귀하가 정의한 표준에 초점을 맞출 것입니다. 그리고 우리는 주로 크롤링과 인덱싱을 위해 이것을 사용할 것입니다.”

사이트링크를 강제로 표시하는 방법이 있습니까?

16:02 "구글 검색 결과에서 원하는 페이지를 사이트 링크로 표시할 수 있는 전략이 있습니까?"

John은 "[...] 사이트 링크를 표시하는 데 사용할 수 있는 메타 태그나 구조화된 데이터가 없습니다 .

[…] 우리 시스템은 사용자가 이 하나의 웹 페이지를 볼 때 […] 관련되거나 관련이 있는 것이 무엇인지 알아내려고 합니다. [...] 우리의 권장 사항은 본질적으로 좋은 웹 사이트 구조를 갖고, 명확한 내부 링크를 가지고 있어 어떤 페이지가 해당 페이지와 관련이 있는지 쉽게 인식하고, 사용하고 표시할 수 있는 [...] 명확한 제목을 갖는 것입니다. 사이트 링크.

[… ] 이 중 하나라도 그렇게 표시될 것이라는 보장이 있는 것은 아닙니다. 그러나 그것은 우리가 어떤 관련이 있는지 알아내는 데 도움이 됩니다. 사이트 링크를 표시하는 것이 합리적이라고 생각한다면 해당 정보를 기반으로 실제로 링크를 선택하는 것이 훨씬 더 쉬울 것입니다.”

우리 사이트에는 iframe이 있는 PDF가 포함되어 있습니다. 텍스트를 OCR해야 합니까?

17:14 “우리 웹사이트는 iframe과 스크립트를 사용하여 PDF 파일을 우리 페이지와 웹사이트에 포함합니다. PDF의 OCR 텍스트를 가져와서 SEO 목적을 위해 문서의 HTML 어딘가에 붙여넣는 데 어떤 이점이 있습니까? 아니면 Google이 콘텐츠 색인을 생성하기 위해 동일한 가중치와 관련성을 가진 PDF 콘텐츠를 단순히 구문 분석할 것입니까?”

John은 다음과 같이 대답했습니다. “[…] PDF의 텍스트를 가져와서 SEO 목적으로 HTML에서 숨기고 싶은 것 같습니다. […] 그리고 그것은 내가 확실히 하지 않는 것이 좋습니다. 콘텐츠를 인덱싱할 수 있도록 하려면 페이지에 표시되도록 설정하세요.

[...] 우리는 PDF에서 텍스트를 가져와서 PDF 자체에 대한 색인을 생성하려고 합니다. 실용적인 관점에서 볼 때 PDF에서 발생하는 일은 첫 번째 단계 중 하나로 이를 HTML 페이지로 변환하고 HTML 페이지처럼 색인을 생성하려고 합니다. […] 당신이 하고 있는 것은 […] 간접 HTML 페이지를 iframe하는 것입니다. 그리고 iframe의 경우 기본 페이지 내에서 색인을 생성하기 위해 해당 콘텐츠를 고려할 수 있습니다. 그러나 어쨌든 PDF를 별도로 색인화하는 일이 발생할 수도 있습니다. [...] 나는 질문을 바꿔서 당신이 일어나기를 원하는 대로 구성할 것입니다.

그리고 PDF 파일의 내용으로 일반 웹 페이지의 색인을 생성하려면 HTML 페이지에서 해당 내용을 즉시 볼 수 있도록 만드십시오. 따라서 PDF를 기본 콘텐츠로 포함하는 대신 HTML 콘텐츠를 기본 콘텐츠로 만들고 PDF 파일에 링크합니다.

그런 다음 해당 PDF를 별도로 색인화할지 여부에 대한 질문이 있습니다. PDF를 별도로 색인화하고 싶은 경우가 있습니다. 그리고 그것들을 별도로 인덱싱하고 싶다면 그것들에 연결하는 것이 좋습니다.

별도로 색인을 생성하지 않으려면 robots.txt를 사용하여 색인을 차단하는 것도 좋습니다. noindex [? x-robots ?] HTTP 헤더. iframe에서 PDF 파일을 사용할 수 있지만 실제로 색인화되지 않도록 하려면 PDF 파일의 헤더로 이를 제공해야 하기 때문에 조금 더 복잡합니다.”

Google은 구조화된 데이터 마크업의 URL을 크롤링합니까?

23:24 "Google은 구조화된 데이터 마크업에 있는 URL을 크롤링합니까? 아니면 Google에서 데이터만 저장합니까?"

John은 "대부분 HTML 페이지를 볼 때 링크처럼 보이는 것이 있으면 해당 URL도 시도할 수 있습니다. [...] JavaScript에서 URL을 찾으면 해당 URL을 선택하여 사용하려고 할 수 있습니다. 사이트의 텍스트 파일에서 링크를 찾으면 해당 링크를 크롤링하여 사용할 수 있습니다. 그러나 그것은 정말로 정상적인 링크가 아닙니다.

[...] Google이 해당 URL을 크롤링하도록 하려면 대상 페이지에 대한 정보를 제공하는 명확한 앵커 텍스트와 함께 해당 URL에 대한 자연스러운 HTML 링크가 있는지 확인 하십시오.

Google이 특정 URL을 크롤링하지 않도록 하려면 robots.txt로 차단하거나 해당 페이지에서 원하는 버전 등을 가리키는 rel=canonical을 사용하세요. [… ] 구조화된 데이터에 있다고 해서 찾을 수 없다고 맹목적으로 가정하지도 않고 구조화된 데이터에 있다고 해서 발견될 것이라고 맹목적으로 가정하지도 않습니다.

[…] 나는 대신 당신이 그곳에서 일어나기를 원하는 것에 초점을 맞출 것입니다. 링크로 보고 싶으시면 링크로 만드세요. 크롤링하거나 인덱싱하지 않으려면 크롤링 또는 인덱싱을 차단 […]하십시오.”