기술 SEO 감사 체크리스트 9단계

이 체크리스트는 이론에서 실제에 이르기까지 기술 현장 감사의 모든 기본 사항을 설명합니다.

어떤 기술 파일이 존재하는지, 왜 SEO 문제가 발생하는지, 그리고 향후 이러한 문제를 수정하고 방지하여 갑작스러운 순위 하락 으로부터 항상 안전할 수 있는 방법을 배우게 됩니다.

그 과정에서 번거로움 없이 기술적인 웹사이트 감사를 수행할 수 있는 유명하고 잘 알려지지 않은 SEO 감사 도구를 보여드리겠습니다.

기술적 SEO 체크리스트의 단계 수는 조사하려는 사이트의 목표와 유형에 따라 다릅니다. 우리는 기술적 SEO 감사의 모든 중요한 단계를 다루는 이 체크리스트를 보편적으로 만드는 것을 목표로 했습니다.

현장 감사를 위한 준비 단계

1. 사이트 분석 및 웹마스터 도구에 대한 액세스 권한 얻기

사이트의 기술 감사를 수행하려면 분석 및 웹마스터 도구가 필요하며 웹사이트에 이미 구성되어 있으면 좋습니다. Google Analytics , Google Search Console , Bing 웹마스터 도구 등을 사용하면 기본 사이트 확인 에 필요한 많은 양의 데이터가 이미 있습니다.

2. 도메인 안전성 확인

순위에서 떨어진 기존 웹사이트를 감사하는 경우 무엇보다도 도메인이 검색 엔진 제재 대상이 될 가능성을 배제하십시오.

이렇게 하려면 Google 검색 콘솔을 참조하십시오. 사이트가 블랙햇 링크 구축으로 불이익을 받았거나 해킹당한 경우 콘솔의 보안 및 수동 조치 탭에 해당 알림이 표시됩니다. 사이트의 기술 감사를 계속 진행하기 전에 이 탭에 표시되는 경고를 해결해야 합니다. 도움이 필요한 경우 수동 및 알고 페널티를 처리하는 방법에 대한 가이드를 확인하십시오.

출시 예정인 새로운 사이트를 감사하는 경우 도메인이 손상되지 않았는지 확인하십시오. 자세한 내용은 만료된 도메인을 선택하는 방법과 웹 사이트 시작 중에 Google 샌드박스에 갇히지 않는 방법에 대한 가이드를 참조하세요.

이제 준비 작업을 마쳤으므로 웹 사이트의 기술 SEO 감사를 단계별로 진행해 보겠습니다.

1단계. 웹사이트 색인 생성 확인

일반적으로 인덱싱 문제에는 두 가지 유형이 있습니다. 하나는 URL이 인덱싱되어야 하는데도 인덱싱되지 않는 경우입니다. 다른 하나는 URL이 인덱싱되지 않아야 하는데 인덱싱되는 경우입니다. 사이트 색인이 생성된 URL의 수를 확인하는 방법은 무엇입니까?

1. 구글 서치 콘솔

귀하의 웹사이트가 실제로 검색 색인에 얼마나 포함되었는지 확인하려면 Google Search Console 에서 노출 범위 보고서를 확인하세요. 이 보고서는 현재 색인이 생성된 페이지 수, 제외된 페이지 수, 웹사이트의 색인 생성 문제가 무엇인지 보여줍니다.

인덱싱 문제의 첫 번째 유형은 일반적으로 오류로 표시됩니다. 색인 생성 오류는 Google에 페이지 색인을 생성하도록 요청했지만 차단된 경우에 발생합니다. 예를 들어 페이지가 사이트맵에 추가되었지만 noindex 태그로 표시되었거나 robots.txt로 차단된 페이지가 있습니다.

다른 유형의 인덱싱 문제는 페이지가 인덱싱되지만 Google은 인덱싱되어야 한다고 확신하지 못하는 경우입니다. Google Search Console에서 이러한 페이지는 일반적으로 유효함(경고 포함) 으로 표시됩니다.

개별 페이지의 경우 Search Console에서 URL 검사 도구를 실행하여 Google 검색 봇이 페이지를 보는 방식을 검토합니다. 해당 탭을 누르거나 상단의 검색창에 전체 URL을 붙여넣으면 검색 봇이 마지막으로 검색한 URL에 대한 모든 정보가 검색됩니다.

그런 다음 라이브 URL 테스트를 클릭하면 응답 코드, HTML 태그, 첫 화면의 스크린샷 등 페이지에 대한 더 자세한 정보를 볼 수 있습니다.

2. 웹사이트 감사자

이 단계에는 WebSite Auditor. 지금 무료로 다운로드할 수 있습니다. 다운로드 WebSite Auditor

인덱싱을 모니터링하는 또 다른 도구는 WebSite Auditor 입니다. 소프트웨어를 실행하고 웹 사이트의 URL을 붙여넣어 새 프로젝트를 만들고 사이트 감사를 진행합니다. 크롤링이 끝나면 WebSite Auditor의 사이트 구조 모듈에 모든 문제와 경고가 표시됩니다. Domain Strength 보고서에서 Google뿐만 아니라 다른 검색 엔진에서도 색인이 생성된 페이지 수를 확인하세요.

3. 로그 파일 분석

사용자 또는 검색 봇이 웹 사이트 데이터를 운반하는 서버에 요청을 보낼 때마다 로그 파일에 이에 대한 항목이 기록됩니다. 이는 사이트의 크롤러 및 방문자, 인덱싱 오류, 크롤링 예산 낭비, 임시 리디렉션 등에 대한 가장 정확하고 유효한 정보입니다. 로그 파일을 수동으로 분석하는 것은 어려울 수 있으므로 로그 파일 분석 프로그램이 필요합니다.

어떤 도구를 사용하기로 결정하든 색인이 생성된 페이지 수는 웹사이트의 실제 페이지 수와 비슷해야 합니다.

이제 웹사이트 크롤링 및 인덱싱을 제어하는 방법에 대해 살펴보겠습니다.

2단계. 웹사이트 색인 생성 및 크롤링 관리

기본적으로 크롤링 제어 기능이 있는 기술적 SEO 파일이 없는 경우에도 검색 봇은 여전히 사이트를 방문하여 그대로 크롤링합니다. 그러나 기술 파일을 사용하면 검색 엔진 봇이 페이지를 크롤링하고 인덱싱하는 방법을 제어할 수 있으므로 사이트가 큰 경우 권장됩니다. 다음은 인덱싱/크롤링 규칙을 수정하는 몇 가지 방법입니다.

그렇다면 각각을 사용하여 Google이 사이트를 더 빠르게 색인화하는 방법은 무엇입니까?

1. 사이트맵

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에서 제목, 설명, 재생 시간, 미리보기 이미지와 같은 비디오에 대한 추가 정보를 추가할 수 있으며 안전 검색을 위해 가족용인지 여부도 추가할 수 있습니다.

Hreflang 사이트맵

다국어 및 다지역 웹사이트의 경우 검색 엔진이 특정 위치에서 제공할 언어 버전을 결정하는 몇 가지 방법이 있습니다. Hreflang은 현지화된 페이지를 제공하는 여러 방법 중 하나이며 이를 위해 특별한 hreflang 사이트맵을 사용할 수 있습니다. hreflang 사이트맵은 페이지의 언어/지역 코드를 나타내는 하위 요소와 함께 URL 자체를 나열합니다.

뉴스 사이트맵

뉴스 블로그를 운영하는 경우 News-XML Sitemap을 추가하면 Google 뉴스의 순위에 긍정적인 영향을 미칠 수 있습니다. 여기에서 제목, 언어 및 출판 날짜에 대한 정보를 추가합니다. 뉴스 사이트맵에 최대 1,000개의 URL을 추가할 수 있습니다. URL은 2일보다 오래되어서는 안 되며 그 후에는 삭제할 수 있지만 30일 동안 색인에 남아 있습니다.

RSS

웹사이트에 RSS 피드가 있는 경우 피드 URL을 사이트맵으로 제출할 수 있습니다. 대부분의 블로그 소프트웨어는 피드를 만들 수 있지만 이 정보는 최근 URL을 빠르게 검색하는 데만 유용합니다.

오늘날 가장 자주 사용되는 것은 XML 사이트맵이므로 XML 사이트맵 생성을 위한 주요 요구 사항을 간단히 수정해 보겠습니다.

XML 사이트맵은 UTF-8로 인코딩되며 XML 요소에 대한 필수 태그를 포함합니다.

단일 항목 XML 사이트맵의 간단한 예는 다음과 같습니다.

페이지 크롤링의 우선순위와 빈도를 나타내는 선택적 태그가 있습니다. <priority>, <changefreq> (Google은 현재 이를 무시함) 및 <lastmod> 값이 정확한 경우(예: 페이지의 마지막 수정과 비교) .

사이트맵의 일반적인 오류는 큰 도메인에 유효한 XML 사이트맵이 없다는 것입니다. WebSite Auditor를 사용하여 사이트맵이 있는지 확인할 수 있습니다. 사이트 감사 > 인덱싱 및 크롤링 가능성 섹션에서 결과를 찾습니다.

사이트맵이 없다면 당장 가서 사이트맵을 만들어야 합니다. 페이지 섹션으로 전환하면 WebSite Auditor의 웹사이트 도구를 사용하여사이트맵을 빠르게 생성 할 수 있습니다.

그리고 사이트맵에 대해 Google에 알려주세요. 이렇게 하려면 다음을 수행할 수 있습니다.

사실 웹사이트에 사이트맵이 있다고 해서 모든 페이지의 색인이 생성되거나 크롤링된다는 보장은 없습니다 . 사이트 인덱싱 개선을 목표로 하는 다른 기술 SEO 리소스가 있습니다. 다음 단계에서 검토하겠습니다.

2. robots.txt 파일

robots.txt 파일은 크롤러가 사이트에서 액세스할 수 있는 URL을 검색 엔진에 알려줍니다. 이 파일은 크롤링 트래픽을 관리 하여 요청으로 서버에 과부하가 걸리지 않도록 합니다. 이 파일은 일반적으로 다음 용도로 사용됩니다.

robots.txt는 도메인의 루트에 있으며 각 하위 도메인에는 별도의 파일이 있어야 합니다. 500kB를 초과하지 않아야 하며 200 코드로 응답해야 합니다.

robots.txt 파일에는 Allow 및 Disallow 규칙이 포함된 구문도 있습니다.

다른 검색 엔진은 지침을 다르게 따를 수 있습니다. 예를 들어 Google은 지시문 사용을 포기했습니다. noindex, crawl-delay 및 nofollow from robots.txt. 게다가 Googlebot-Image, Bingbot, Baiduspider-image, DuckDuckBot, AhrefsBot 등과 같은 특수 크롤러가 있습니다. 따라서 모든 검색 봇에 대한 규칙을 정의하거나 일부에 대해서만 별도의 규칙을 정의할 수 있습니다.

robots.txt에 대한 작성 지침은 매우 까다로울 수 있으므로 여기서 규칙은 더 적은 수의 지침과 더 많은 상식을 갖는 것입니다. 다음은 robots.txt 지침을 설정하는 몇 가지 예입니다.

도메인에 대한 전체 액세스 권한입니다. 이 경우 금지 규칙이 채워지지 않습니다.

호스트 전체 차단.

명령은 도메인 이름 다음에 업로드로 시작하는 모든 URL의 크롤링을 허용하지 않습니다.

명령은 Googlebot-News가 뉴스 폴더의 모든 gif 파일을 크롤링하는 것을 허용하지 않습니다.

모든 검색 엔진에 대해 일반적인 지침 A를 설정하고 특정 봇에 대해 하나의 좁은 지침 B를 설정하면 특정 봇은 좁은 지침을 따르고 봇에 대해 기본적으로 설정된 다른 모든 일반 규칙을 수행할 수 있습니다. 규칙 A에 의해 제한되지 않습니다. 예를 들어 아래 규칙과 같습니다.

여기에서 AdsBot-Google-Mobile은 와일드카드 * 표시가 있는 명령에도 불구하고 tmp 폴더의 파일을 크롤링할 수 있습니다.

robots.txt 파일의 일반적인 용도 중 하나는 Sitemap이 있는 위치를 나타내는 것입니다. 이 경우 규칙이 모든 크롤러에 적용되므로 사용자 에이전트를 언급할 필요가 없습니다. Sitemap은 대문자 S로 시작해야 하며(robots.txt 파일은 대소문자를 구분함) URL은 절대적이어야 합니다(즉, 전체 도메인 이름으로 시작해야 함).

모순되는 지침을 설정하면 크롤러 봇이 더 긴 지침에 우선 순위를 부여한다는 점을 명심하십시오. 예를 들어:

여기에서 /admin/js/global.js 스크립트는 첫 번째 지침에도 불구하고 여전히 크롤러에 허용됩니다. admin 폴더의 다른 모든 파일은 여전히 허용되지 않습니다.

WebSite Auditor에서 robots.txt 파일의 가용성을 확인할 수 있습니다. 또한 robots.txt 생성기 도구를 사용하여 파일을 생성하고 추가로 저장하거나 FTP를 통해 웹사이트에 바로 업로드할 수 있습니다.

robots.txt 파일은 공개적으로 사용할 수 있으며 일부 페이지를 숨기는 대신 노출할 수 있습니다. 일부 개인 폴더를 숨기려면 비밀번호로 보호하십시오.

마지막으로 robots.txt 파일은 허용되지 않은 페이지가 크롤링되거나 색인이 생성되지 않는다고 보장하지 않습니다 . Google이 페이지를 크롤링하지 못하도록 차단하면 Google 색인에서 해당 페이지가 제거될 가능성이 높지만 검색 봇은 페이지를 가리키는 일부 백링크를 따라 계속 페이지를 크롤링할 수 있습니다. 따라서 페이지가 크롤링 및 인덱싱되지 않도록 차단하는 또 다른 방법인 메타 로봇이 있습니다.

3. 메타 로봇 태그

메타 로봇 태그는크롤러에게 개별 페이지를 처리하는 방법을 지시하는 좋은 방법입니다. 메타 로봇 태그는 HTML 페이지의 <head> 섹션에 추가되므로 지침이 전체 페이지에 적용됩니다. 로봇 메타 태그 지시문을 쉼표와 결합하거나 여러 메타 태그를 사용하여 여러 지침을 만들 수 있습니다. 다음과 같이 보일 수 있습니다.

예를 들어 다양한 크롤러에 대해 메타 로봇 태그를 지정할 수 있습니다.

Google은 다음과 같은 태그를 이해합니다.

반대 태그 index / follow / archive 는 해당 금지 명령을 무시합니다. snippet / nosnippet / notranslate / nopagereadaloud / noimageindex 와 같이 페이지가 검색 결과에 표시되는 방식을 알려주는 다른 태그가 있습니다.

다른 검색 엔진에는 유효하지만 Google에는 알려지지 않은 다른 태그를 사용하는 경우 Googlebot은 해당 태그를 무시합니다.

4. X-로봇 태그

메타 태그 대신 PDF, 비디오 및 이미지 파일과 같은 HTML이 아닌 리소스에 대한 응답 헤더를 사용할 수 있습니다. 응답에서 값이 noindex 또는 none인 X-Robots-Tag 헤더를 반환하도록 설정합니다.

지시어 조합을 사용하여 스니펫이 검색 결과에 어떻게 표시되는지 정의할 수도 있습니다(예: max-image-preview: [setting] 또는 nosnippet 또는 max-snippet: [숫자] 등).

사이트의 웹 서버 소프트웨어 구성 파일을 통해 웹사이트의 HTTP 응답에 X-Robots-Tag를 추가할 수 있습니다. 크롤링 지시문은 정확한 이름을 정의하는 경우 개별 파일뿐만 아니라 모든 파일에 대해 사이트 전체에 전역으로 적용될 수 있습니다.

WebSite Auditor를 사용하여 모든 로봇 지침을 빠르게 검토할 수 있습니다. 사이트 구조 > 모든 리소스 > 내부 리소스 로 이동하여 로봇의 지침 열을 확인합니다. 여기에서 허용되지 않는 페이지와 적용된 방법(robots.txt, 메타 태그 또는 X-Robots-tag)을 찾을 수 있습니다.

5. 서버 응답 코드

사이트를 호스팅하는 서버는 클라이언트, 브라우저 또는 크롤러의 요청에 응답할 때 HTTP 상태 코드를 생성합니다. 서버가 2xx 상태 코드로 응답하면 수신된 콘텐츠가 인덱싱 대상으로 간주될 수 있습니다. 3xx에서 5xx까지의 다른 응답은 콘텐츠 렌더링에 문제가 있음을 나타냅니다. 다음은 HTTP 상태 코드 응답의 몇 가지 의미입니다.

301 리디렉션은 다음과 같은 경우에 사용됩니다.

302 임시 리디렉션

임시 302 리디렉션은 임시 페이지에서만 사용해야 합니다. 예를 들어 페이지를 재설계하거나 새 페이지를 테스트하고 피드백을 수집하지만 URL이 순위에서 떨어지지 않도록 하고 싶을 때입니다.

304 캐시 확인

304 응답 코드는 Google, Bing, Baidu, Yandex 등과 같은 가장 널리 사용되는 모든 검색 엔진에서 지원됩니다. 304 응답 코드를 올바르게 설정하면 봇이 마지막 크롤링 이후 페이지에서 변경된 내용을 이해하는 데 도움이 됩니다. 봇은 HTTP 요청 If-Modified-Since를 보냅니다. 마지막 크롤링 날짜 이후 변경 사항이 감지되지 않으면 검색 봇이 페이지를 다시 크롤링할 필요가 없습니다. 사용자의 경우 페이지가 완전히 다시 로드되지 않고 해당 콘텐츠가 브라우저 캐시에서 가져옴을 의미합니다.

304 코드는 다음에도 도움이 됩니다.

페이지 콘텐츠뿐만 아니라 이미지 또는 CSS 스타일과 같은 정적 파일의 캐싱을 확인하는 것이 중요합니다. 304 응답 코드를 확인하기 위한 이와 같은 특수 도구가 있습니다.

응답 코드의 일반적인 문제

대부분의 경우 크롤러가 삭제되거나 이동된 페이지에 대한 내부 및 외부 링크를 계속 따라가 3xx 및 4xx 응답을 받을 때 서버 응답 코드 문제가 나타납니다.

404 오류는 페이지를 사용할 수 없음을 나타내며 서버는 올바른 HTTP 상태 코드(404 Not Found)를 브라우저에 보냅니다.

그러나 서버에서 200 OK 응답 코드를 보낼 때 소프트 404 오류가 발생하지만 Google에서는 이를 404로 간주해야 합니다. 이는 다음과 같은 이유로 발생할 수 있습니다.

WebSite Auditor의 사이트 감사 모듈에서 인덱싱 및 크롤링 가능성 탭 아래의 4xx, 5xx 응답 코드와 링크 탭의 끊어진 링크에 대한 별도 섹션을 검토하십시오.

301/302 응답과 관련된 몇 가지 다른 일반적인 리디렉션 문제:

WebSite Auditor의 사이트 감사 > 리디렉션 섹션에서 301 및 302 리디렉션이 있는 모든 페이지를 검토할 수 있습니다.

6. Rel=”표준”

복제는 웹 사이트 크롤링에서 심각한 문제가 될 수 있습니다. Google에서 중복 URL을 발견 하면 그 중 어느 것이 기본 페이지인지 결정하고 더 자주 크롤링하는 반면 중복된 URL은 덜 자주 크롤링되어 검색 색인에서 전혀 제외될 수 있습니다. 확실한 해결책은 중복 페이지 중 하나를 기본 페이지로 지정하는 것입니다. 이는 페이지의 HTML 코드 또는 사이트의 HTTP 헤더 응답에 배치된 rel=”canonical” 속성을 사용하여 수행할 수 있습니다.

Google은 표준 페이지를 사용하여 귀하의 콘텐츠와 품질을 평가하며, 대부분의 경우 검색 엔진이 일부 비표준 페이지가 사용자에게 더 적합하다고 명확하게 식별하지 않는 한(예: 모바일 사용자 또는 모바일 사용자이거나 특정 위치에 있는 검색자).

따라서 관련 페이지를 정규화하면 다음과 같은 이점이 있습니다.

중복 문제의 이유

중복 문제는 여러 URL에 나타나는 동일하거나 유사한 콘텐츠를 의미합니다. 꽤 자주, 웹 사이트에서 기술 데이터를 처리하기 때문에 중복이 자동으로 나타납니다.

기술적 중복

일부 CMS는 잘못된 설정으로 인해 자동으로 중복 문제를 생성할 수 있습니다. 예를 들어 다양한 웹 사이트 디렉토리에서 여러 URL이 생성될 수 있으며 이는 중복입니다.

페이지 매김이 잘못 구현되면 중복 문제가 발생할 수도 있습니다. 예를 들어, 카테고리 페이지와 페이지 1의 URL은 동일한 콘텐츠를 표시하므로 중복으로 처리됩니다. 이러한 조합이 존재하지 않거나 카테고리 페이지가 표준으로 표시되어야 합니다.

정렬 및 필터링 결과는 중복으로 표시될 수 있습니다. 이는 사이트에서 검색 또는 쿼리 필터링을 위한 동적 URL을 생성할 때 발생합니다. 쿼리 문자열 또는 URL 변수의 별칭을 나타내는 URL 매개변수를 얻게 되며, 이는 물음표 뒤에 오는 URL의 일부입니다.

Google이 거의 동일한 여러 페이지를 크롤링하지 못하도록 하려면 특정 URL 매개변수를 무시하도록 설정하세요. 그렇게 하려면 Google Search Console을 실행하고 레거시 도구 및 보고서 > URL 매개변수 로 이동합니다. 오른쪽에서 편집을 클릭하고 무시할 매개변수를 Google에 지정하면 규칙이 사이트 전체에 적용됩니다. 매개변수 도구는 고급 사용자를 위한 도구이므로 정확하게 다루어야 합니다.

중복 문제는 패싯 필터 탐색을 허용하여 검색 범위를 3개, 4개 및 그 이상의 기준으로 좁힐 수 있는 전자 상거래 웹사이트에서 종종 발생합니다. 다음은 전자 상거래 사이트에 대한 크롤링 규칙을 설정하는 방법의 예 입니다. 더 길고 좁은 검색 결과가 포함된 URL을 특정 폴더에 저장하고 robots.txt 규칙에 따라 이를 허용하지 않습니다.

논리적 중복

웹사이트 구조의 논리적 문제로 인해 중복이 발생할 수 있습니다. 제품을 판매하고 있고 하나의 제품이 다른 범주에 속하는 경우가 이에 해당할 수 있습니다.

이 경우 하나의 URL을 통해서만 제품에 액세스할 수 있어야 합니다. URL은 전체 중복 으로 간주되어 SEO에 해를 끼칩니다. URL은 CMS의 올바른 설정을 통해 할당되어 한 페이지에 고유한 단일 URL을 생성해야 합니다.

예를 들어 태그가 사용될 때 WordPress CMS에서 부분 복제가 자주 발생합니다. 태그는 사이트 검색 및 사용자 탐색을 개선하지만 WP 웹사이트는 카테고리 이름과 일치할 수 있는 태그 페이지를 생성하고 기사 스니펫 미리보기의 유사한 콘텐츠를 나타냅니다. 해결책은 태그를 현명하게 사용하여 제한된 수의 태그만 추가하는 것입니다. 또는 태그 페이지에 메타 로봇 noindex dofollow를 추가할 수 있습니다.

여러 장치 유형

웹사이트의 별도 모바일 버전을 제공하기로 선택하고 특히 모바일 검색용 AMP 페이지를 생성하는 경우 이러한 종류의 중복이 있을 수 있습니다.

페이지가 중복임을 나타내기 위해 HTML의 헤드 섹션에서 <link> 태그를 사용할 수 있습니다. 모바일 버전의 경우 다음과 같이 rel=“alternate” 값이 있는 링크 태그가 됩니다.

AMP 페이지(트렌드는 아니지만 여전히 모바일 결과를 렌더링하는 데 사용할 수 있음)에도 동일하게 적용됩니다. AMP 페이지 구현에 대한 가이드를 살펴보세요.

언어/지역 변형

현지화된 콘텐츠를 표시하는 방법에는 여러 가지가 있습니다. 다른 언어/로케일 변형으로 콘텐츠를 표시하고 사이트의 머리글/바닥글/탐색만 번역했지만 콘텐츠가 동일한 언어로 유지되면 URL이 중복으로 처리됩니다.

hreflang 태그를 사용하여 다국어 및 다지역 사이트 표시를 설정하고 HTML, HTTP 응답 코드 또는 사이트맵에 지원되는 언어/지역 코드를 추가합니다.

하위 도메인 www/www가 아닌 변형

웹사이트는 일반적으로 도메인 이름에 "www"가 있는 것과 없는 것이 있습니다. 이 문제는 매우 일반적이며 사람들은 www 버전과 www가 없는 버전 모두에 링크합니다. 이 문제를 해결하면 검색 엔진이 웹 사이트의 두 가지 버전을 인덱싱하지 못하도록 방지할 수 있습니다. 이러한 인덱싱으로 페널티가 발생하지는 않지만 한 버전을 우선 순위로 설정하는 것이 가장 좋습니다.

HTTP/HTTPS 프로토콜 문제

대부분의 웹사이트(특히 거래를 수행하고 민감한 사용자 정보를 수집할 때)에 보안 암호화가 적극 권장되기 때문에 Google은 HTTP보다 HTTPS를 선호합니다. 때때로 웹마스터는 SSL 인증서를 설치하고 웹사이트의 HTTP/HTTPS 버전을 설정할 때 기술적인 문제에 직면합니다. 사이트에 유효하지 않은 SSL 인증서(신뢰할 수 없거나 만료된 인증서)가 있는 경우 대부분의 웹 브라우저는 사용자에게 "안전하지 않은 연결"을 알려 사이트를 방문하지 못하도록 합니다.

웹 사이트의 HTTP 및 HTTPS 버전이 제대로 설정되지 않은 경우 둘 다 검색 엔진에 의해 인덱싱되고 웹 사이트 순위를 손상시킬 수 있는 중복 콘텐츠 문제가 발생할 수 있습니다.

사이트에서 이미 HTTPS(부분적으로 또는 전체적으로)를 사용하고 있는 경우 SEO 사이트 감사의 일부로 일반적인 HTTPS 문제를 제거하는 것이 중요합니다. 특히 사이트 감사 > 인코딩 및 기술 요소 섹션에서혼합 콘텐츠를 확인 해야 합니다.

혼합 콘텐츠 문제는 보안 페이지가 비보안 HTTP 연결을 통해 일부 콘텐츠(이미지, 동영상, 스크립트, CSS 파일)를 로드할 때 발생합니다. 이는 보안을 약화시키고 브라우저가 비보안 콘텐츠 또는 전체 페이지를 로드하지 못하게 할 수 있습니다.

이러한 문제를 방지하려면 .htaccess 파일 에서 사이트의 기본 www 버전 또는 www가 아닌 버전을 설정하고 볼 수 있습니다. 또한 Google Search Console에서 선호 도메인을 설정하고 HTTPS 페이지를 표준으로 표시합니다.

콘텐츠 중복

자신의 웹사이트에서 콘텐츠를 완전히 제어할 수 있게 되면 중복된 제목, 표제, 설명, 이미지 등이 없는지 확인하십시오. 사이트 전체에서 중복된 콘텐츠에 대한 힌트는 WebSite Auditor 의 사이트 감사 에서 온페이지 섹션을 참조하십시오. 계기반. 중복된 제목과 메타 설명 태그가 있는 페이지는 콘텐츠도 거의 동일할 가능성이 높습니다.

인덱싱 문제를 발견하고 해결하는 방법을 요약해 보겠습니다. 위의 팁을 모두 따랐지만 페이지 중 일부가 여전히 색인에 없는 경우 다음은 이러한 일이 발생할 수 있는 이유를 요약한 것입니다.

페이지가 인덱싱되어서는 안 되지만 왜 인덱싱됩니까?

robots.txt 파일에서 페이지를 차단하고 사이트맵에서 제거한다고 해서 색인이 생성되지 않는다는 보장은 없습니다. 페이지 색인 생성을 올바르게 제한하는 방법 에 대한 자세한 가이드를 참조할 수 있습니다.

3단계. 사이트 구조 확인

얕은 논리적 사이트 아키텍처는 사용자와 검색 엔진 봇 모두에게 중요합니다. 잘 계획된 사이트 구조는 다음과 같은 이유로 순위에 큰 역할을 합니다.

사이트 구조와 내부 링크를 검토할 때 다음 요소에 주의하십시오.

SEO 친화적인 URL

최적화된 URL은 두 가지 이유로 중요합니다. 첫째, Google에 대한 사소한 순위 요소입니다. 둘째, 사용자는 너무 길거나 서투른 URL로 인해 혼란을 겪을 수 있습니다. URL 구조를 생각할 때 다음 권장사항을 따르세요.

WebSite Auditor의 사이트 감사 > URL 섹션에서 URL을 확인할 수 있습니다.

내부 연결

많은 링크 유형이 있으며 그 중 일부는 귀하의 웹사이트 SEO에 어느 정도 도움이 됩니다. 예를 들어, dofollow 컨텍스트 링크는 링크 주스를 전달하고 검색 엔진에 링크가 무엇인지에 대한 추가 표시기 역할을 합니다. 링크는 다음과 같은 경우 고품질로 간주됩니다(내부 및 외부 링크 모두 참조).

헤더와 사이드바의 탐색 링크는 사용자와 검색 엔진이 페이지를 탐색하는 데 도움이 되므로 웹 사이트 SEO에도 중요합니다.
다른 링크는 순위 값이 없거나 사이트 권한에 해를 끼칠 수 있습니다. 예를 들어 템플릿의 대규모 사이트 전체 발신 링크(무료 WP 템플릿에는 많이 포함되어 있음)가 있습니다. SEO의 링크 유형에 대한 이 가이드는 가치 있는 링크를 올바른 방식으로 구축하는 방법을 알려줍니다.

WebSite Auditor 도구를 사용하여 내부 링크와 해당 품질을 철저히 검사할 수 있습니다.

고아 페이지

고아 페이지는 연결되지 않은 페이지로 눈에 띄지 않고 결국 검색 색인에서 제외될 수 있습니다. 고립된 페이지를 찾으려면 사이트 감사 > 시각화 로 이동하고 시각적 사이트맵을 검토하십시오. 여기에서 연결되지 않은 모든 페이지와 긴 리디렉션 체인을 쉽게 볼 수 있습니다(301 및 302 리디렉션은 파란색으로 표시됨).

페이지뷰(Google Analytics에서 통합), PageRank, 들어오고 나가는 링크에서 얻는 링크 주스를 확인하여 전체 사이트 구조를 살펴보고 기본 페이지의 비중을 조사할 수 있습니다. 링크를 추가 및 제거하고 프로젝트를 다시 빌드하여 각 페이지의 중요도를 다시 계산할 수 있습니다.

클릭 깊이

내부 링크를 감사할 때 클릭 깊이를 확인하십시오. 사이트의 중요한 페이지가 홈페이지에서 세 번 이상 클릭되지 않는지 확인하십시오. WebSite Auditor에서 클릭 심도를 검토할 수 있는 또 다른 위치는 사이트 구조 > 페이지 로 이동하는 것입니다. 그런 다음 열 헤더를 두 번 클릭하여 내림차순으로 클릭 심도별로 URL을 정렬합니다.

쪽수 매기기

블로그 페이지의 페이지 매김은 클릭 깊이를 증가시키지만 검색 엔진의 검색 가능성을 위해 필요합니다. 실행 가능한 사이트 검색과 함께 간단한 구조를 사용하여 사용자가 리소스를 더 쉽게 찾을 수 있도록 합니다.

자세한 내용은 SEO 친화적인 페이지 매김에 대한 세부 가이드를 참조하십시오.

빵 부스러기

이동 경로는 사이트 구조 내에서 페이지의 경로를 표시하여 검색에서 리치 결과를 만드는 데 도움이 되는 마크업 유형입니다. 이동 경로는 내부 링크에 최적화된 앵커와 올바르게 구현된 구조화된 데이터가 있는 적절한 링크 덕분에 표시됩니다(후자는 아래 몇 단락에서 설명합니다).

실제로 내부 링크는 사이트 순위와 각 페이지가 검색에 표시되는 방식에 영향을 미칠 수 있습니다. 자세한 내용은 내부 연결 전략에 대한 SEO 가이드를 참조하세요.

4단계. 로드 속도 및 페이지 경험 테스트

사이트 속도와 페이지 경험은 유기적 위치에 직접적인 영향을 미칩니다. 한 번에 너무 많은 사용자가 방문하면 서버 응답이 사이트 성능에 문제가 될 수 있습니다. 페이지 속도와 관련하여 Google은 가장 큰 페이지 콘텐츠가 2.5초 이내에 뷰포트 내에서 로드될 것으로 예상하고 결국 더 나은 결과를 제공하는 페이지에 보상을 제공합니다. 이것이 서버와 클라이언트 측 모두에서 속도를 테스트하고 개선해야 하는 이유입니다.

로드 속도 테스트는 너무 많은 사용자가 동시에 웹 사이트를 방문할 때 서버 측 문제를 발견합니다. 문제는 서버 설정과 관련이 있지만 SEO는 대규모 SEO 및 광고 캠페인을 계획하기 전에 이를 고려해야 합니다. 방문자가 급증할 것으로 예상되는 경우 서버 로드 최대 용량을 테스트하십시오. 방문자 증가와 서버 응답 시간 간의 상관 관계에 주목하십시오. 수많은 분산 방문을 시뮬레이션하고 서버 용량을 충돌 테스트할 수 있는 부하 테스트 도구가 있습니다.

서버 측에서 가장 중요한 메트릭 중 하나는 TTFB 측정 또는 첫 번째 바이트까지의 시간 입니다. TTFB는 사용자가 HTTP 요청을 한 시점부터 클라이언트 브라우저가 페이지의 첫 번째 바이트를 수신할 때까지의 시간을 측정합니다. 서버 응답 시간은 웹 페이지의 성능에 영향을 미칩니다. 브라우저가 서버 응답을 600ms 이상 기다리면 TTFB 감사가 실패합니다. TTFB를 개선하는 가장 쉬운 방법은 공유 호스팅에서 관리 호스팅 으로 전환하는 것입니다. 이 경우 사이트 전용 서버를 갖게 됩니다.

예를 들어, 다음은 사이트 성능을 확인하는 무료 도구인 Geekflare로 만든 페이지 테스트입니다. 보시다시피 도구는 이 페이지의 TTFB가 600ms를 초과하므로 개선해야 한다고 표시합니다.

하지만 클라이언트 측에서 페이지 속도는 측정하기 쉽지 않으며 Google은 오랫동안 이 측정 항목을 가지고 씨름했습니다. 마지막으로 Core Web Vitals에 도달했습니다. 이는 주어진 페이지의 인식 속도를 측정하도록 설계된 세 가지 메트릭입니다. 이러한 메트릭은 LCP(Largest Contentful Pain), FID(First Input Delay) 및 CLS(Cumulative Layout Shift)입니다. 웹 페이지의 로드 속도, 상호 작용 및 시각적 안정성과 관련하여 웹 사이트의 성능을 보여줍니다. 각 CWV 메트릭에 대한 자세한 내용이 필요한 경우 Core Web Vitals에 대한 가이드를 확인하세요.

최근에WebSite Auditor에 세 가지 Core Web Vitals 지표가 모두 추가되었습니다 . 따라서 이 도구를 사용하는 경우 각 메트릭 점수, 웹사이트의 페이지 속도 문제 목록, 영향을 받는 페이지 또는 리소스 목록을 볼 수 있습니다. 데이터는 무료로 생성할 수 있는 PageSpeed API 키를 통해 분석됩니다.

WebSite Auditor를 사용하여 CWV를 감사하면 한 번에 모든 페이지에 대한 대량 검사를 수행할 수 있다는 이점이 있습니다. 동일한 문제의 영향을 받는 페이지가 많이 보이면 문제가 사이트 전체에 발생하고 단일 수정으로 해결할 수 있는 것일 수 있습니다. 따라서 실제로는 보이는 것만큼 많은 작업이 아닙니다. 오른쪽에 있는 권장 사항을 따르기만 하면 페이지 속도가 즉시 빨라질 것입니다.

5단계. 모바일 친화성 확인

요즘은 모바일로 검색하는 사람이 데스크탑에서 검색하는 사람을 능가합니다 . 2019년에 Google은 스마트폰 에이전트가 Googlebot 데스크톱보다 먼저 웹사이트를 크롤링하는 모바일 우선 인덱싱을 구현했습니다. 따라서 모바일 친화성은 유기적 순위에서 가장 중요합니다.

놀랍게도 모바일 친화적인 웹사이트를 만드는 방법에는 여러 가지가 있습니다.

각 솔루션의 장단점은 웹사이트를 모바일 친화적으로 만드는 방법에 대한 자세한 가이드 에 설명되어 있습니다. 또한 AMP 페이지를 다듬을 수 있습니다. 이것은 최첨단 기술은 아니지만 일부 유형의 페이지(예: 뉴스)에서는 여전히 잘 작동합니다.

모바일 친화성은 데스크톱과 모바일 모두에 대해 하나의 URL을 제공하는 웹사이트의 중요한 요소입니다. 게다가 방해가 되는 전면 광고의 부재와 같은 일부 사용성 신호는 데스크톱 및 모바일 순위 모두에 관련 요소를 유지합니다. 그렇기 때문에 웹 개발자는 모든 유형의 장치에서 최상의 사용자 경험을 보장해야 합니다.

사이트가 모바일 친화적인지 확인하는 방법

Google의 모바일 친화성 테스트에는 뷰포트 구성, 플러그인 사용, 텍스트 크기 및 클릭 가능한 요소와 같은 사용성 기준 선택이 포함됩니다. 또한 모바일 친화성은 페이지를 기준으로 평가되므로 각 방문 페이지의 모바일 친화성을 한 번에 하나씩 개별적으로 확인해야 한다는 점을 기억하는 것도 중요합니다.

전체 웹사이트를 평가하려면 Google Search Console로 전환하세요. 경험 탭으로 이동하고 모바일 사용 편의성 보고서를 클릭하여 모든 페이지에 대한 통계를 확인하십시오. 그래프 아래에서 모바일 페이지에 영향을 미치는 가장 일반적인 문제가 있는 표를 볼 수 있습니다. 대시보드 아래의 문제를 클릭하면 영향을 받는 모든 URL 목록이 표시됩니다.

일반적인 모바일 친화성 문제는 다음과 같습니다.

WebSite Auditor는 또한 홈페이지의 모바일 친화성을 검토하고 모바일 사용자 경험의 문제를 지적합니다. 사이트 감사 > 인코딩 및 기술 요소 로 이동합니다. 이 도구는 사이트가 모바일 친화적인지 표시하고 문제가 있는 경우 목록을 표시합니다.

6단계. 온페이지 태그 검사

온페이지 신호는 직접적인 순위 요인이며 웹사이트의 기술적 건전성이 아무리 우수하더라도 적절한 HTML 태그 최적화 없이는 페이지가 검색에 표시되지 않습니다. 따라서 목표는 웹 사이트 전체에서 콘텐츠의 제목, 메타 설명 및 H1–H3 제목을 확인하고 정리하는 것입니다.

제목과 메타 설명은 검색 엔진에서 검색 결과 스니펫을 형성하는 데 사용됩니다. 이 스니펫은 사용자에게 가장 먼저 표시되므로 유기적 클릭률에 큰 영향을 미칩니다 .

단락, 글머리 기호 목록 및 기타 웹페이지 구조 요소와 함께 제목은 Google에서 풍부한 검색 결과를 만드는 데 도움이 됩니다. 또한 자연스럽게 페이지의 가독성과 사용자 상호 작용을 향상시켜 검색 엔진에 긍정적인 신호로 작용할 수 있습니다. 다음을 주시하십시오.

WebSite Auditor는 이 작업에 많은 도움을 줄 수 있습니다. 사이트 구조 > 사이트 감사 섹션에서는 웹 사이트 전체의 메타 태그 문제를 일괄적으로 확인할 수 있습니다. 개별 페이지의 콘텐츠를 더 자세히 감사해야 하는 경우 페이지 감사 섹션으로 이동하세요. 이 앱에는 또한 최고의 SERP 경쟁업체를 기반으로 페이지를 다시 작성하는 방법에 대한 제안을 제공하는 작성 도구 콘텐츠 편집기가 내장되어 있습니다. 이동 중에 페이지를 편집하거나 카피라이터를 위한 작업으로 권장 사항을 다운로드할 수 있습니다.

자세한 내용은 온페이지 SEO 최적화 가이드를 참조하세요.

7단계. 구조화된 데이터 구현

구조화된 데이터는 검색 봇이 페이지의 콘텐츠를 더 잘 이해할 수 있도록 하는 시맨틱 마크업입니다. 예를 들어 페이지에 사과 파이 레시피가 있는 경우 구조화된 데이터를 사용하여 어떤 텍스트가 재료인지, 요리 시간, 칼로리 수 등을 Google에 알릴 수 있습니다. Google은 마크업을 사용하여 SERP의 페이지에 대한 리치 스니펫을 생성합니다.

구조화된 데이터에는 널리 사용되는 두 가지 표준인 소셜 미디어에서 아름다운 공유를 위한 OpenGraph 와 검색 엔진을 위한 Schema가 있습니다. 마크업 구현의 변형은 Microdata, RDFa 및 JSON-LD 입니다. Microdata 및 RDFa는 페이지의 HTML에 추가되는 반면 JSON-LD는 JavaScript 코드입니다. 후자는 Google에서 권장합니다 .

페이지의 콘텐츠 유형이 아래에 언급된 것 중 하나인 경우 마크업이 특히 권장됩니다.

구조화된 데이터를 조작하면 검색 엔진에서 처벌을 받을 수 있습니다. 예를 들어 마크업은 사용자에게 숨겨진 콘텐츠(즉, 페이지의 HTML에 없는 콘텐츠)를 설명하면 안 됩니다. 구현하기 전에 구조화된 데이터 테스트 도구 로 마크업을 테스트하세요.

Enhancements 탭 아래의 Google Search Console에서 마크업을 확인할 수도 있습니다. GSC는 웹사이트에서 구현하려고 시도한 개선 사항을 표시하고 성공 여부를 알려줍니다.

WebSite Auditor 도 여기에 도움이 될 수 있습니다. 이 도구는 모든 페이지를 검토하고 페이지에 있는 구조화된 데이터의 존재, 해당 유형, 제목, 설명 및 OpenGraph 파일의 URL을 표시할 수 있습니다.

아직 스키마 마크업을 구현하지 않은 경우 구조화된 데이터에 대한 이 SEO 가이드를 확인하세요. 웹사이트에서 CMS를 사용하는 경우 구조화된 데이터가 기본적으로 구현되거나 플러그인을 설치하여 추가할 수 있습니다(어쨌든 플러그인을 과도하게 사용하지 마세요).

8단계. Google에 사이트 재크롤링 요청

웹사이트를 감사하고 발견된 모든 문제를 수정한 후에는 변경 사항을 더 빨리 볼 수 있도록 페이지를 다시 크롤링하도록 Google에 요청할 수 있습니다.
Google Search Console에서 업데이트된 URL을 URL 검사 도구에 제출하고 색인 생성 요청을 클릭합니다. 또한 라이브 URL 테스트 기능(이전에는 Fetch as Google 기능이라고 함)을 활용하여 페이지를 현재 형식으로 본 다음 색인 생성을 요청할 수 있습니다.

URL 검사 도구를 사용하면 보고서를 확장하여 자세한 내용을 확인하고 실제 URL을 테스트하고 인덱싱을 요청할 수 있습니다.

웹 사이트에서 무언가를 변경할 때마다 강제로 다시 크롤링할 필요는 없습니다. 변경사항이 심각한 경우 다시 크롤링을 고려하세요. 예를 들어 사이트를 http에서 https로 이동했거나, 구조화된 데이터를 추가했거나, 훌륭한 콘텐츠 최적화를 수행했거나, Google에 더 빨리 표시하고 싶은 긴급한 블로그 게시물을 게시했습니다. Google에는 제한이 있습니다. 월별 재크롤링 작업 수에 영향을 미치므로 남용하지 마십시오. 또한 대부분의 CMS는 변경 사항을 변경하는 즉시 Google에 제출하므로 CMS(예: Shopify 또는 WordPress)를 사용하는 경우 다시 크롤링하지 않아도 됩니다.

크롤러가 페이지를 방문하는 빈도에 따라 다시 크롤링하는 데 며칠에서 몇 주가 걸릴 수 있습니다. 재크롤링을 여러 번 요청해도 프로세스 속도가 빨라지지 않습니다. 대량의 URL을 다시 크롤링해야 하는 경우 각 URL을 URL 검사 도구에 수동으로 추가하는 대신 사이트맵을 제출하십시오.

Bing 웹마스터 도구에서도 동일한 옵션을 사용할 수 있습니다. 대시보드에서 내 사이트 구성 섹션을 선택하고 URL 제출을 클릭하십시오. 색인을 다시 생성해야 하는 URL을 입력하면 Bing이 몇 분 안에 URL을 크롤링합니다. 이 도구를 사용하면 웹마스터는 대부분의 사이트에 대해 하루에 최대 10,000개의 URL을 제출할 수 있습니다.

9단계. 정기적으로 사이트 감사

웹에서는 많은 일이 발생할 수 있으며 대부분은 순위에 더 좋거나 더 나쁜 영향을 미칠 수 있습니다. 그렇기 때문에 웹사이트에 대한 정기적인 기술 감사가 SEO 전략의 필수적인 부분이 되어야 합니다.

예를 들어 WebSite Auditor 에서 기술 SEO 감사를 자동화할 수 있습니다. Rebuild Project 작업을 생성하고 일정 설정(예: 한 달에 한 번)을 지정하면 웹 사이트가 도구에 의해 자동으로 다시 크롤링되고 새로운 데이터를 얻을 수 있습니다.

감사 결과를 고객이나 동료와 공유해야 하는 경우 WebSite Auditor의 다운로드 가능한 SEO 보고 템플릿 중 하나를 선택하거나 사용자 지정 템플릿을 만드십시오.

사이트 감사(요약) 템플릿은 웹사이트 편집자가 수행할 최적화 작업의 범위를 확인하는 데 유용합니다. 사이트 감사(세부 정보) 템플릿은 각 문제와 문제를 해결하는 것이 중요한 이유를 설명하는 더 자세한 설명입니다. Website Auditor에서 사이트 감사 보고서를 사용자 지정하여 정기적으로 모니터링해야 하는 데이터(인덱싱, 끊어진 링크, 온페이지 등)를 가져온 다음 CSV/PDF로 내보내거나 데이터를 스프레드시트에 복사하여 붙여넣을 수 있습니다. 수정을 위해 개발자에게 넘깁니다.

기술 SEO 감사 체크리스트

PDF 다운로드

또한 WebSite Auditor의 사이트 감사 보고서 에서 자동으로 수집된 모든 웹사이트의 기술적 SEO 문제에 대한 전체 목록을 얻을 수 있습니다. 또한 자세한 보고서는 각 문제에 대한 설명과 해결 방법을 제공합니다.

다음은 정기적인 기술 사이트 감사의 기본 단계입니다. 이 가이드가 철저한 사이트 감사를 수행하는 데 필요한 도구, 돌봐야 할 SEO 측면, 웹사이트의 SEO 상태를 양호하게 유지하기 위해 취해야 할 예방 조치에 대해 가장 좋은 방법으로 설명하기를 바랍니다.

자주 묻는 질문:

기술적 SEO란 무엇입니까?

기술 SEO는 검색 봇이 페이지에 보다 효과적으로 액세스할 수 있도록 도와주는 웹 사이트의 기술적 측면의 최적화를 다룹니다. 기술 SEO는 크롤링, 인덱싱, 서버 측 문제, 페이지 경험, 메타 태그 생성, 사이트 구조를 다룹니다.

기술 SEO 감사를 어떻게 수행합니까?

기술 SEO 감사는 모든 URL을 수집하고 웹사이트의 전체 구조를 분석하는 것에서 시작됩니다. 그런 다음 페이지의 접근성, 로딩 속도, 태그, 페이지 세부 정보 등을 확인합니다. 기술적인 SEO 감사 도구는 무료 웹마스터 도구에서 SEO 스파이더, 로그 파일 분석기 등에 이르기까지 다양합니다.

언제 내 사이트를 감사해야 합니까?

기술 SEO 감사는 다른 목표를 추구할 수 있습니다. 시작 전이나 진행 중인 최적화 프로세스 중에 웹 사이트를 감사할 수 있습니다. 다른 경우에는 사이트 마이그레이션을 구현하거나 Google 제재를 해제하고 싶을 수 있습니다. 각각의 경우에 대해 기술 감사의 범위와 방법이 다릅니다.