3. 로그 파일 분석
사용자 또는 검색 봇이 웹사이트 데이터를 전달하는 서버에 요청을 보낼 때마다 로그 파일에 이에 대한 항목이 기록됩니다. 이것은 사이트의 크롤러 및
방문자, 색인 생성 오류, 크롤링 예산 낭비, 임시 리디렉션 등에 대한 가장 정확하고 유효한 정보입니다. 로그 파일을 수동으로 분석하는 것은 어려울 수
있으므로 로그 파일 분석 프로그램 이 필요합니다 .
어떤 도구를 사용하기로 결정하든 색인이 생성된 페이지의 수는 웹사이트의 실제 페이지 수와 비슷해야 합니다.
이제 웹사이트 크롤링 및 인덱싱을 제어하는 방법에 대해 알아보겠습니다.
2단계. 웹사이트 색인 생성 및 크롤링 관리
기본적으로 크롤링 제어 기능이 있는 기술적인 SEO 파일이 없는 경우 검색 봇은 여전히 사이트를 방문하여 있는 그대로 크롤링합니다. 그러나 기술 파일을
사용하면 검색 엔진 봇이 페이지를 크롤링하고 색인을 생성하는 방법을 제어할 수 있으므로 사이트가 큰 경우 이 파일을 사용하는 것이 좋습니다. 다음은 색인
생성/크롤링 규칙을 수정하는 몇 가지 방법입니다.
사이트맵
로봇.txt
메타 로봇 태그
X-Robots-Tag HTTP 헤더
Rel="표준"
서버 응답 코드
그렇다면 각각을 사용하여 Google에서 사이트를 더 빠르게 색인화하는 방법은 무엇입니까?
사이트맵
Sitemap은 사이트의 모든 페이지, 비디오 및 기타 리소스와 이들 간의 관계를 나열하는 기술적인 SEO 파일입니다. 이 파일은 검색 엔진에 사이트를
보다 효율적으로 크롤링하는 방법을 알려주고 웹사이트 접근성에 중요한 역할을 합니다.
다음과 같은 경우 웹사이트에 Sitemap이 필요합니다.
웹사이트가 너무 큽니다.
연결되지 않은 분리된 페이지가 많이 있습니다.
사이트 구조 깊숙이 묻혀 있는 페이지가 너무 많습니다.
웹사이트가 새롭고 백링크가 너무 적습니다.
웹사이트에는 많은 멀티미디어 콘텐츠(이미지, 비디오) 또는 뉴스가 있습니다.
주로 관리하는 웹사이트의 유형에 따라 사이트에 추가할 수 있는 다양한 유형의 사이트맵이 있습니다.
HTML 사이트맵
HTML 사이트맵은 독자를 대상으로 하며 웹사이트 하단에 있습니다. 그러나 SEO 가치는 거의 없습니다. HTML 사이트맵은 사람들에게 기본 탐색을
표시하며 일반적으로 사이트 헤더의 링크를 복제합니다. 한편, HTML 사이트맵은 기본 메뉴에 포함되지 않은 페이지에 대한 접근성을 향상시키는 데 사용할 수
있습니다.
XML 사이트맵
HTML 사이트맵과 달리 XML 사이트맵은 특별한 구문 덕분에 기계에서 읽을 수 있습니다. XML Sitemap은 루트 도메인(예:
https://www.link-assistant.com/sitemap.xml)에 있습니다. 아래에서 올바른 XML 사이트맵을 만들기 위한 요구 사항 및 마크업
태그에 대해 설명합니다.
TXT 사이트맵
이것은 검색 엔진 봇에 사용할 수 있는 대체 유형의 사이트맵입니다. TXT 사이트맵은 콘텐츠에 대한 다른 정보를 제공하지 않고 단순히 모든 웹사이트
URL을 나열합니다.
이미지 사이트맵
이러한 유형의 사이트맵은 방대한 이미지 라이브러리와 대형 이미지가 Google 이미지 검색에서 순위를 매기는 데 도움이 됩니다. 이미지 사이트맵에서
지리적 위치, 제목 및 라이선스와 같은 이미지에 대한 추가 정보를 제공할 수 있습니다. 페이지당 최대 1,000개의 이미지를 나열할 수 있습니다.
동영상 사이트맵
동영상 사이트맵은 페이지에 호스팅된 동영상 콘텐츠가 Google 비디오 검색에서 순위를 높이는 데 필요합니다. Google은 동영상에 구조화된 데이터를
사용할 것을 권장하지만 특히 페이지에 동영상 콘텐츠가 많은 경우 사이트맵도 유용할 수 있습니다. 비디오 Sitemap에서 제목, 설명, 재생 시간, 미리보기
이미지와 같은 비디오에 대한 추가 정보를 추가할 수 있으며 Safe Search를 위해 가족용인 경우에도 마찬가지입니다.
Hreflang 사이트맵
다국어 및 다지역 웹사이트의 경우 검색 엔진 이 특정 위치에서 제공할 언어 버전을 결정하는 몇 가지 방법이 있습니다. Hreflang은 현지화된
페이지를 제공하는 여러 방법 중 하나이며 이를 위해 특별한 hreflang 사이트맵을 사용할 수 있습니다. hreflang 사이트맵 은 페이지의 언어/지역
코드를 나타내는 하위 요소와 함께 URL 자체를 나열합니다.
뉴스 사이트맵
뉴스 블로그를 운영하는 경우 News-XML Sitemap을 추가하면 Google 뉴스에서 순위에 긍정적인 영향을 미칠 수 있습니다. 여기에서 제목,
언어 및 발행일에 대한 정보를 추가합니다. 뉴스 사이트맵에 최대 1,000개의 URL을 추가할 수 있습니다. URL은 2일 이내여야 하며 이후에는 삭제할 수
있지만 색인에는 30일 동안 유지됩니다.
RSS
웹사이트에 RSS 피드가 있는 경우 피드 URL을 사이트맵으로 제출할 수 있습니다. 대부분의 블로그 소프트웨어는 피드를 생성할 수 있지만 이 정보는
최근 URL의 빠른 검색에만 유용합니다.
요즘 가장 많이 사용되는 것은 XML 사이트맵이므로 XML 사이트맵 생성을 위한 주요 요구 사항을 간단히 수정해 보겠습니다.
사이트맵은 최대 50,000개의 URL 을 포함해야 하며 크기가 50MB 를 초과하지 않아야 합니다(크기는 압축 가능). 가장 중요한 페이지가 더 자주
크롤링되도록 하려면 길이를 더 짧게 유지하는 것이 이상적입니다. 기술적인 SEO 실험 에 따르면 사이트맵이 짧을수록 크롤링이 더 효과적입니다.
URL이 더 있는 경우 여러 사이트맵으로 분할하여 하나의 사이트맵 색인 파일에 제출할 수 있습니다.
모든 XML 사이트맵은 200 서버 응답 코드를 반환해야 합니다.
새 페이지를 추가하고 사이트맵에서 삭제하는 것은 사이트에 페이지를 추가할 때 자동으로 수행되어야 합니다.
사이트맵의 URL 순서는 중요하지 않습니다. 그러나 중복이 없어야 합니다. 사이트맵에 표준 URL 만 추가하면 Google 로봇이 사이트맵의 모든
페이지를 표준으로 처리합니다.
XML 사이트맵은 UTF-8로 인코딩되며 XML 요소에 대한 필수 태그를 포함합니다.
1항목 XML 사이트맵의 간단한 예는 다음과 같습니다.
페이지 크롤링의 우선 순위와 빈도를 나타내는 선택적 태그가 있습니다. - ,
(Google은 현재 무시함) 및 정확할 때 값(예: 페이지의 마지막 수정 사항과 비교) .
사이트맵의 일반적인 오류는 대규모 도메인에 유효한 XML 사이트맵이 없는 것입니다. WebSite Auditor 를 사용하여 사이트맵이 있는지 확인할
수 있습니다 . 사이트 감사 > 인덱싱 및 크롤링 가능성 섹션 에서 결과를 찾습니다
사이트맵이 없다면 지금 당장 사이트맵을 만들어야 합니다.
페이지 섹션 으로 전환할 때 WebSite Auditor의 웹 사이트 도구 를 사용하여 사이트 맵 을 빠르게 생성할 수 있습니다.
그리고 Google에 귀하의 사이트맵에 대해 알립니다. 이렇게 하려면 다음을
수행할 수 있습니다.
Sitemaps 보고서를 통해 Google Search Console에 수동으로 제출하거나(여기에서 이전에 업로드한 전체 사이트맵 목록을 볼 수 있음)
또는 다음과 같은 방법으로 robots.txt 파일의 아무 곳에나 해당 위치를 지정합니다. Sitemap:
http://yourdomain.com/sitemaplocation.xml
사실 웹사이트에 사이트맵이 있다고 해서 모든 페이지의 색인이 생성되거나 크롤링되는 것은 아닙니다 . 사이트 인덱싱을 개선하기 위한 다른 기술적인 SEO
리소스가 있습니다. 다음 단계에서 검토하겠습니다.
2. Robots.txt 파일
robots.txt 파일은 크롤러가 사이트에서 액세스할 수 있는 URL을 검색 엔진에 알려줍니다. 이 파일은 요청으로 서버에 과부하가 걸리는 것을 방지
하고 크롤링 트래픽을 관리하는 역할을 합니다 . 이 파일은 일반적으로 다음 용도로 사용됩니다.
중복 문제를 숨깁니다.
사이트 검색 결과, 서비스 페이지, 로그인, 개발 중인 임시 페이지와 같이 색인에 표시할 필요가 없는 일부 페이지에 대한 액세스를 제한합니다.
크롤링 예산을 늘리십시오.
대용량 멀티미디어, 웹 리소스 등과 같은 일부 콘텐츠 유형을 숨깁니다.
Robots.txt는 도메인의 루트에 위치하며 각 하위 도메인에는 자체 파일이 있어야 합니다. 500kB를 초과해서는 안 되며 200 코드로 응답해야
합니다.
robots.txt 파일에는 Allow 및 Disallow 규칙이 있는 구문도 있습니다.
사용자 에이전트: 규칙이 적용되는 크롤러를 정의합니다.
와일드카드(*)는 지시문이 모든 검색 엔진에 적용됨을 의미합니다.
슬래시(/)는 규칙이 적용되는 경로의 이름입니다.
$ 기호는 URL의 끝을 의미합니다.
해시태그 기호(#)는 텍스트 파일 내에서 주석으로 구문을 시작합니다.
다른 검색 엔진은 지시문을 다르게 따를 수 있습니다. 예를 들어 Google 은 robots.txt 의 noindex, crawl-delay 및
nofollow 지시문 사용을 중단 했습니다. 그 외에도 Googlebot-Image, Bingbot, Baiduspider-image,
DuckDuckBot, AhrefsBot 등과 같은 특수 크롤러가 있습니다. 따라서 모든 검색 봇에 대한 규칙을 정의하거나 일부에 대해서만 별도의 규칙을
정의할 수 있습니다.
robots.txt에 대한 지침을 작성하는 것은 매우 까다로울 수 있으므로 여기의 규칙은 지침을 줄이고 상식을 더 많이 사용하는 것입니다. 다음은
robots.txt 지침을 설정하는 몇 가지 예입니다.
도메인에 대한 전체 액세스 권한입니다. 이 경우 금지 규칙이 채워지지 않습니다.
사용자 에이전트: *
허용하지 않음:
호스트의 전체 차단.
사용자 에이전트: *
허용하지 않음: /
이 지침은 도메인 이름 뒤에 업로드로 시작하는 모든 URL 크롤링을 허용하지 않습니다.
사용자 에이전트: *
허용하지 않음: /업로드
이 지침은 Googlebot-News가 뉴스 폴더의 모든 gif 파일을 크롤링하는 것을 허용하지 않습니다.
사용자 에이전트: Googlebot-News
허용 안 함: /news/*/gifs$
모든 검색 엔진에 대해 일반 명령 A를 설정하고 특정 봇에 대해 하나의 좁은 명령 B를 설정하면 특정 봇이 좁은 명령을 따르고 봇에 대해 기본적으로
설정된 다른 모든 일반 규칙을 수행할 수 있습니다. 규칙 A에 의해 제한되지 않습니다. 예를 들어 아래 규칙과 같이:
사용자 에이전트: *
허용하지 않음: /tmp/
사용자 에이전트: AdsBot-Google-모바일
허용하지 않음: /gallery/*/large.tif$
여기에서 AdsBot-Google-Mobile은 와일드카드 * 표시가 있는 지침에도 불구하고 tmp 폴더의 파일을 크롤링할 수 있습니다.
robots.txt 파일의 일반적인 용도 중 하나는 Sitemap이 있는 위치를 나타내는 것입니다. 이 경우 규칙이 모든 크롤러에 적용되므로 사용자
에이전트를 언급할 필요가 없습니다. Sitemap은 대문자 S로 시작해야 하고(robots.txt 파일은 대소문자를 구분함을 기억하십시오) URL은
절대적이어야 합니다(즉, 전체 도메인 이름으로 시작해야 함).
사이트맵: https://www.example.com/sitemap.xml
모순되는 명령을 설정하면 크롤러 봇이 더 긴 명령에 우선순위를 둡니다. 예를 들어:
사용자 에이전트: *
허용하지 않음: /admin
허용: /admin/js/global.js
여기에서 /admin/js/global.js 스크립트는 첫 번째 지침에도 불구하고 크롤러에 대해 계속 허용됩니다. admin 폴더의 다른 모든 파일은
여전히 허용되지 않습니다.
WebSite Auditor에서 robots.txt 파일의 가용성을 확인할 수 있습니다. 또한 robots.txt 생성기 도구 를 사용하여 파일을
생성할 수 있으며 추가로 저장하거나 FTP를 통해 웹사이트에 바로 업로드할 수 있습니다.
robots.txt 파일은 공개적으로 사용 가능하며 일부 페이지를 숨기는 대신 노출할 수 있습니다. 일부 개인 폴더를 숨기려면 해당 폴더를 암호로
보호하십시오.
마지막으로 robots.txt 파일은 허용되지 않은 페이지가 크롤링되거나 색인이 생성되지 않는다고 보장하지 않습니다 . Google에서 페이지를
크롤링하지 못하도록 차단하면 Google 색인에서 제거될 수 있지만 검색 봇은 페이지를 가리키는 일부 백링크를 따라 계속 페이지를 크롤링할 수 있습니다.
따라서 페이지 크롤링 및 인덱싱을 차단하는 또 다른 방법인 메타 로봇이 있습니다.
3. 메타 로봇 태그
메타 로봇 태그는 크롤러 에게 개별 페이지를 처리하는 방법을 지시하는 좋은 방법입니다. 메타 로봇 태그는 HTML 페이지의 섹션에 추가되므로 지침이
전체 페이지에 적용됩니다. robots 메타 태그 지시문을 쉼표와 결합하거나 여러 메타 태그를 사용하여 여러 지침을 만들 수 있습니다. 다음과 같이 보일 수
있습니다.
(…)
(…)
예를 들어 다양한 크롤러에 대해 메타 로봇 태그를 지정할 수 있습니다.
Google은 다음과 같은 태그를 이해합니다.
검색 색인에서 페이지를 유지하기 위한 noindex ;
링크를 팔로우하지 않으려면 nofollow ,
noindex, nofollow에 해당하는 없음 ;
noarchive 는 Google에 페이지의 캐시된 사본을 저장하지 말라고 지시합니다.
반대 태그 인덱스/팔로우/아카이브 는 해당 금지 지시문을 무시합니다. snippet / nosnippet / notranslate /
nopagereadaloud / noimageindex 와 같이 검색결과에 페이지가 어떻게 표시되는지 알려주는 몇 가지 다른 태그가 있습니다 .
다른 검색 엔진에 유효하지만 Google에 알려지지 않은 다른 태그를 사용하는 경우 Googlebot은 해당 태그를 무시합니다.
4. X-로봇 태그
메타 태그 대신 PDF, 비디오 및 이미지 파일과 같은 HTML이 아닌 리소스에 대한 응답 헤더를 사용할 수 있습니다 . 응답에서 값이 noindex
또는 none인 X-Robots-Tag 헤더를 반환하도록 설정합니다.
예를 들어 max-image-preview: [setting] 또는 nosnippet 또는 max-snippet: [number] 등 의 지시어 조합을
사용하여 검색 결과에서 스니펫이 어떻게 보일지 정의할 수 있습니다.
사이트의 웹 서버 소프트웨어의 구성 파일을 통해 웹사이트의 HTTP 응답에 X-Robots-Tag를 추가할 수 있습니다. 크롤링 지시문은 정확한 이름을
정의하는 경우 개별 파일뿐만 아니라 모든 파일에 대해 사이트 전체에 걸쳐 전역적으로 적용될 수 있습니다 .
메모
noindex 지시문이 적용되기 위한 경험 법칙은 noindex 메타 태그 또는 X-Robots-tag가 있는 페이지가 robots.txt 파일에 의해
차단되어서는 안 된다는 것입니다. 페이지가 robots.txt 파일에 의해 차단되거나 크롤러가 페이지에 액세스할 수 없는 경우 noindex 지시문이 표시되지
않으며 다른 페이지가 해당 페이지에 링크되는 경우와 같이 페이지가 검색 결과에 계속 나타날 수 있습니다.
WebSite Auditor 를 사용하여 모든 로봇 지침을 빠르게 검토할 수 있습니다 . 사이트 구조 > 모든 리소스 > 내부 리소스 로 이동 하여 로봇의 지침 열 을 확인합니다 . 여기에서 허용되지 않는 페이지와 적용되는 방법(robots.txt, 메타 태그 또는 X-Robots-tag)을 찾을 수 있습니다.
사이트를 호스팅하는 서버는 클라이언트, 브라우저 또는 크롤러의 요청에 응답할 때
HTTP 상태 코드를 생성합니다. 서버가 2xx 상태 코드로 응답하면 수신된 콘텐츠가 인덱싱을 위해 고려될 수 있습니다. 3xx에서 5xx까지의 다른 응답은
콘텐츠 렌더링에 문제가 있음을 나타냅니다. 다음은 HTTP 상태 코드 응답의 몇 가지 의미입니다.
200 — 좋습니다. URL을 색인화할 수 있습니다.
301 — 리디렉션, 페이지가 이동되었으며 크롤러가 표시된 대상을 방문해야 합니다.
302 — 임시 리디렉션은 실질적으로 동일함을 의미하며 임시 리디렉션이 곧 제거되지 않으면 리디렉션 대상이 검색 인덱스에 포함됩니다.
304 - 캐시된 리소스에 대한 암시적 리디렉션 페이지는 최신 크롤링 이후 변경되지 않았으며 봇은 페이지를 다시 크롤링하지 않습니다.
404 — 페이지를 찾을 수 없지만 봇이 방문을 여러 번 시도합니다. 특히 일부 다른 페이지가 해당 페이지에 링크되어 있는 경우 더욱 그렇습니다.
503 — 서비스를 일시적으로 사용할 수 없습니다. 모든 5xx 오류는 내부 서버 오류이며 웹 사이트에서 진행 중인 작업 중에 사용해야 합니다.
301 리디렉션은 다음과 같은 경우에 사용됩니다.
페이지를 제거했고 사용자를 새 페이지로 보내려고 합니다.
두 사이트를 병합하고 오래된 URL에 대한 링크가 올바른 페이지로 리디렉션되는지 확인하려고 합니다.
사람들은 여러 다른 URL을 통해 사이트에 액세스합니다(사이트의 http/https 또는 www/www가 없는 버전을 통해).
사이트를 새 도메인으로 이동했습니다.
302 임시 리디렉션
임시 302 리디렉션은 임시 페이지에서만 사용해야 합니다. 예를 들어 페이지를 다시 디자인하거나 새 페이지를 테스트하고 피드백을 수집하지만 URL이
순위에서 떨어지지 않기를 원하는 경우입니다.
캐시를 확인하는 304
304 응답 코드는 Google, Bing, Baidu, Yandex 등과 같은 가장 널리 사용되는 모든 검색 엔진에서 지원됩니다. 304 응답 코드를
올바르게 설정하면 봇이 마지막 크롤링 이후 페이지에서 변경된 사항을 이해하는 데 도움이 됩니다. 봇은 If-Modified-Since HTTP 요청을
보냅니다. 마지막 크롤링 날짜 이후에 변경 사항이 감지되지 않으면 검색 봇이 페이지를 다시 크롤링할 필요가 없습니다. 사용자의 경우 페이지가 완전히 다시
로드되지 않고 해당 콘텐츠가 브라우저 캐시에서 가져옴을 의미합니다.
304 코드는 다음과 같은 작업에도 도움이 됩니다.
콘텐츠를 더 빠르게 제공합니다. 이는 특히 인터넷 연결이 좋지 않은 경우에 유용합니다.
페이지가 변경되지 않은 경우 다시 크롤링할 필요가 없으므로 추가 요청으로부터 서버를 저장합니다.
크롤링 예산을 절약하고 페이지를 더 빠르게 인덱싱합니다.
페이지의 내용뿐만 아니라 이미지나 CSS 스타일과 같은 정적 파일의 캐싱을 확인하는 것이 중요합니다. 304 응답 코드를 확인하기 위한 이와 같은
특별한 도구가 있습니다 .
너무 긴 리디렉션 체인: 두 개 이상의 301 리디렉션으로 여러 페이지를 서로
리디렉션하는 경우 Google이 긴 리디렉션 체인을 크롤링하지 않기 때문에 결국 색인에서 제외됩니다.
나쁜 습관으로 간주되어 Google에서 불이익을 받는 부적절한 리디렉션 입니다.
302 리디렉션이 너무 오래 유지됩니다. 소스와 대상 모두 인덱스에 포함되지만 순위 강도는 재분배되지 않습니다. 기술 사이트 감사 중에 302
리디렉션을 발견하면 정말 필요한지 검토하세요.
WebSite Auditor 의 사이트 감사 > 리디렉션 섹션 에서 301
및 302 리디렉션이 있는 모든 페이지를 검토할 수 있습니다 .
다음 단계로 성장하는데 도움이 될 수 있는 방법에 대해 자세히 알아보려면 문의하기를 클릭하세요.