19가지 일반적인 기술 SEO 문제(권장 솔루션 포함)

게시 됨: 2020-08-19

Semetrical에서 당사의 SEO 전문가는 수년 동안 수많은 기술적 SEO 감사를 수행했으며 여러 산업 분야에서 웹사이트가 겪는 일반적인 기술 문제를 발견했습니다. 당사 가이드는 권장 솔루션과 함께 가장 일반적인 기술 SEO 문제를 간략하게 설명합니다.

다음은 가장 일반적인 기술 SEO 문제 목록입니다.

  1. Robots,txt의 대소문자 구분하지 않는 규칙
  2. 대문자 및 소문자 URL 중복
  3. HTTPS로 리디렉션하는 HTTP 302
  4. 내부 연결에 영향을 미치는 표준 URL
  5. 404 URL에 연결되는 표준 URL
  6. 여러 표준 태그
  7. 홈페이지 복제
  8. 모바일 및 데스크톱 버전의 사이트가 다름
  9. 국제 IP 탐지
  10. 국제 웹사이트 복제
  11. 과거 URL 및 스테이징 URL을 포함한 XML 사이트맵
  12. 스테이징 웹 사이트가 인덱싱되고 있어 중복이 발생합니다.
  13. 인덱싱되는 내부 검색
  14. 중복을 일으키는 매개변수
  15. 제품 URL 복제
  16. 웹사이트의 깊이
  17. 자바스크립트
  18. 메타 로봇 ​​NOINDEX의 잘못된 사용
  19. 소프트 404페이지

1. Robots,txt의 대소문자 구분하지 않는 규칙

문제:

기술 SEO 감사를 수행할 때 robots.txt의 허용 안 함 규칙이 대문자와 소문자 규칙 모두에 적용되지 않는 경우가 종종 있습니다.

예를 들어 전자 상거래 사이트에서 장바구니 경로는 /basket/ 및 /Basket/ 모두에서 실행되는 경우가 많지만 robots.txt에는 일반적으로 소문자 경로만 포함됩니다. 즉, /Basket/이 있는 URL은 여전히 ​​인덱싱이 가능하고 콘텐츠 중복이 발생하므로 검색 엔진에서 웹사이트의 인덱싱을 개선하려면 이를 피해야 합니다.

Robots.txt 규칙:

허용하지 않음: /basket/

허용하지 않음: /basket/*

해결책:

웹 사이트를 감사하고 차단해야 하는 경로의 대문자 및 소문자 버전이 모두 있는지 확인하십시오. DeepCrawl의 친구와 같은 웹 크롤러를 사용하여 이 작업을 수행할 수 있습니다. 웹사이트에 두 버전이 모두 활성화되어 있으면 robots.txt에 두 번째 규칙을 추가하여 대문자 경로가 차단되도록 하십시오. 예를 들어, 허용하지 않음: /Basket/*

웹 크롤러에 액세스할 수 없는 경우 사이트 프로토콜 검색은 대문자와 소문자 버전이 모두 인덱싱되는지 확인하는 데 매우 유용할 수 있습니다.

2. 대문자 및 소문자 URL 복제

문제:

우리가 발견한 일반적인 문제는 웹사이트 전체에 링크되는 대소문자를 구분하지 않는 URL의 중복이며 Google은 이들이 두 개의 다른 URL이라고 봅니다. 예를 들어:

https://www.example.co.uk/Panerai/Watches
https://www.example.co.uk/panerai/watches

이것은 블로그 게시물의 편집자가 제품 페이지에 대한 직접 링크를 추가했지만 소문자 대신 대문자로 입력했기 때문에 발생할 수 있습니다.

우리는 또한 인기 제품 링크가 대문자를 통해 링크되는 버그가 있는 내부 링크 모듈로 인해 이러한 일이 발생하는 것을 보았습니다.

해결책:

모든 대문자 URL이 301 리디렉션을 통해 소문자로 리디렉션되는 서버 수준에서 규칙을 설정하는 것이 좋습니다. 이렇게 하면 대문자와 소문자 URL이 모두 연결되는 향후 복제로부터 웹사이트를 보호할 수 있습니다.

301 리디렉션 규칙을 추가하면 외부 사이트가 대문자를 통해 실수로 귀하의 사이트에 링크될 수 있는 링크 자산도 통합됩니다.

301 리디렉션이 불가능한 경우 대문자 URL의 소스 코드에 표준 태그를 추가하여 소문자 URL 버전을 참조하는 것이 좋습니다.

3. HTTPS로 리디렉션되는 HTTP 302

문제:

회사는 종종 HTTPS URL을 보호하기 위해 웹사이트를 마이그레이션하지만 항상 301 리디렉션 규칙을 구현하는 것은 아니며 대신 302 리디렉션을 구현하므로 이론적으로 이것은 URL의 HTTP 버전이 영구적이지 않고 일시적으로만 이동되었음을 검색 엔진에 알립니다. 시간이 지남에 따라 백링크를 획득한 HTTP URL은 301 리디렉션이 설정되지 않는 한 링크 자산을 HTTPS 버전으로 완전히 전달하지 않기 때문에 링크 자산과 웹사이트의 전체 권한을 줄일 수 있습니다.

해결책:

모든 HTTP URL 301이 HTTPS 버전으로 리디렉션되는 서버 수준에서 규칙을 설정하는 것이 좋습니다.

4. 내부 연결에 영향을 미치는 표준 URL

문제:

여러 전자 상거래 웹사이트에서 여러 제품 URL 변형이 있는 제품을 보았지만 각 변형은 복제를 방지하기 위해 표준 제품 URL에 연결되었습니다. 그러나 표준 제품 페이지는 표준 태그를 통해서만 찾을 수 있으며 다른 내부 링크는 사용할 수 없습니다.

또한 표준 제품 페이지에는 웹사이트 전반의 내부 링크에 영향을 미치는 이동 경로가 포함되어 있지 않습니다.

이 내부 연결 표준 설정은 사이트 전체의 내부 링크가 혼합 신호를 전송하기 때문에 지침을 무시하기 때문에 검색 엔진이 표준 URL 버전을 선택하지 못하는 경우가 있습니다. 이로 인해 비표준 버전의 제품이 색인화되어 URL 잠식을 유발하여 궁극적으로 SEO 성능에 부정적인 영향을 미칠 수 있습니다.

해결책:

표준 URL의 색인을 생성하려면 웹사이트에서 다음을 수행해야 합니다.

표준 URL을 다른 URL 변형이 아닌 XML 사이트맵에 추가합니다.

"인기 제품"과 같은 사이트 전체 내부 연결 모듈 내에서 표준 URL 버전에 내부적으로 연결

표준 URL 페이지에 기본 이동 경로 구조를 추가합니다.

5. 404 URL에 연결되는 표준 URL

문제:

표준 URL은 때때로 404 URL을 참조하지만 검색에 혼합 신호를 보냅니다.

엔진. 표준 URL이 기본 URL의 크롤러에 색인을 생성하도록 지시하지만 기본 URL은 현재 더 이상 존재하지 않습니다.

해결책:

먼저 표준 URL이 404여야 하는지 아니면 복원해야 하는지 설정해야 합니다. 복원되면 문제가 해결되지만 표준 URL이 404여야 하는 경우 새 표준 URL을 선택하거나 자체 참조가 되도록 표준을 업데이트해야 합니다.

6. 여러 표준 태그

문제:

웹 페이지의 HTML 코드에서 두 개의 표준 태그가 발견되는 경우가 있습니다. 이렇게 하면 충돌하는 메시지를 검색 엔진에 보낼 수 있으며 첫 번째 표준만 계산되어 사용됩니다.

해결책:

일부 웹사이트 크롤러는 여러 표준 태그에 플래그를 지정할 수 있지만 그렇지 않은 경우 사이트를 크롤링할 때 여러 표준 태그를 찾기 위해 사용자 지정 추출을 설정해야 합니다.

HTML 코드에 여러 표준 태그가 있는 웹 페이지는 하나가 제거되고 올바른 표준 태그만 남아 있는 곳에서 업데이트해야 합니다.

7. 홈페이지 복제

문제:

웹 사이트에는 중복을 유발하고 링크 자산의 분할을 유발할 수 있는 여러 홈페이지 URL이 있는 경우가 있습니다. 일반적인 홈페이지 복제 URL은 다음과 같습니다.

www.example.com

www.example.com/home

www.example.com/index.html

www.example.com/home.html

해결책:

웹사이트에 여러 홈페이지 URL이 있는 경우 모든 중복 버전이 기본 홈페이지 버전으로 리디렉션되는 301 리디렉션을 설정하는 것이 좋습니다.

8. 모바일 및 데스크톱 버전의 사이트가 다름

문제:

모바일 사이트는 웹사이트의 데스크톱 버전과 동일한 콘텐츠를 포함해야 합니다. 웹사이트 감사를 수행하고 데스크톱과 모바일 웹사이트 크롤링을 비교할 때 모바일 버전이 특정 페이지의 데스크톱 버전보다 적은 콘텐츠를 포함하는 콘텐츠 차이를 발견했습니다.

이것은 웹사이트의 거의 모든 인덱싱이 모바일 버전에서 시작되고 우선 순위 콘텐츠가 누락된 경우 순위가 하락하기 시작할 수 있기 때문에 문제가 발생할 수 있습니다.

해결책:

사이트의 모바일 버전은 데스크톱 버전과 동일한 콘텐츠를 포함해야 하며 누락된 콘텐츠는 모바일 웹사이트에 추가되어야 합니다.

9. 국제 IP 추출

문제:

지리적 IP 리디렉션을 구현한 웹 사이트의 경우 가장 일반적인 문제는 구현이 봇을 포함한 모든 사용자에 대해 리디렉션된다는 것입니다.

Googlebot은 일반적으로 미국 IP에서 크롤링하며 봇이 지리적 위치를 기반으로 리디렉션되는 경우 Googlebot은 웹사이트의 미국 버전만 크롤링하고 색인을 생성합니다. 이렇게 하면 사이트의 다른 지리적 버전이 크롤링 및 색인화되는 것을 방지할 수 있습니다.

또한 모든 시장에는 미국 가격만 표시되므로 가격이 지리적 위치를 기반으로 업데이트되는 전자상거래 사이트에서 제품 가격 스키마 마크업에 문제가 발생할 수 있습니다. 예를 들어 아래 스니펫은 영국 내 웹사이트의 영국 버전에서 적용되는 미국 가격을 보여줍니다.

해결책:

지역 IP 리디렉션을 구현해야 하는 경우 리디렉션 규칙에서 모든 봇을 제외하는 것이 좋습니다. 이렇게 하면 Googlebot과 같은 봇이 모든 국제 버전을 크롤링하고 색인을 생성할 수 있기 때문입니다.

지리적 IP 리디렉션을 구현하지 않는 경우 모든 지리적 위치의 모든 사용자에게 웹사이트를 열어두고 사용자가 자신의 언어/위치를 선택할 수 있는 사용자 친화적인 JavaScript 배너를 표시하는 것이 좋습니다.

이것은 사용자가 잘못된 국제 웹사이트 버전을 방문했을 때 유용한 UX 기능입니다. 팝업은 IP 감지를 기반으로 나타납니다. 예를 들어 사용자가 영국 IP에서 미국 웹사이트를 방문하는 경우 영국 사이트가 더 적합할 수 있음을 알리는 배너가 나타납니다.

10. 국제 웹사이트 복제

문제:

회사가 전 세계 여러 국가에서 운영될 때 웹 사이트의 여러 버전을 보는 것이 일반적입니다. 이것은 이상적인 사용자 경험을 제공하고 이를 수행하기 위해 국가별 웹 사이트를 통해 회사에서 사용자가 전 세계에 있는 위치에 따라 사용자 여정을 맞춤화할 수 있도록 하는 일반적인 관행입니다.

그러나 회사는 웹사이트의 여러 버전을 만드는 실수를 저지를 수 있지만 특정 국가 또는 지역을 대상으로 해야 하는 웹사이트를 나타내는 신호를 검색 엔진에 보내지 않습니다.

웹사이트 소유자가 검색 엔진에 대한 지침 없이 여러 사이트 버전을 생성하면 웹사이트 복제 및 교차 도메인 잠식과 같은 혼란이 발생할 수 있습니다.

해결책:

웹사이트의 국제 버전을 만들 때 Hreflang 태그는 위치와 언어를 기반으로 사용자에게 제공할 올바른 웹페이지를 Google과 같은 검색 엔진에 알리는 데 사용해야 합니다.

Hreflang 태그는 기본적으로 X 언어 설정으로 X 위치의 사용자에게 서비스를 제공하기 위해 특정 페이지가 필요함을 나타내므로 Hreflang 태그는 웹사이트의 국제 버전이 검색 엔진에 중복으로 표시되는 것을 방지합니다.

Hreflang 태그를 설정하고 매핑하는 것은 혼란스러울 수 있으며 웹사이트의 크기에 따라 큰 작업입니다. 잘못 설정하면 웹 사이트 트래픽에 해로울 수 있습니다.

국제 웹사이트 확장을 계획 중이거나 국제 웹사이트에 문제가 있는 경우 국제 SEO 서비스 페이지를 방문하십시오.

11. 과거 URL과 스테이징 URL을 포함한 XML 사이트맵

문제:

우리가 생각하는 것보다 더 자주 접하게 되는 흥미로운 문제는 XML 사이트맵에 오래된 URL이 있거나 스테이징 URL이 어떻게든 스스로를 XML 사이트맵으로 압축하는 웹사이트입니다.

이로 인해 스테이징 URL이 사이트맵에 표시되고 스테이징 사이트가 검색 엔진에 의해 차단되지 않는 것처럼 문제가 발생할 수 있습니다. 이러한 URL은 색인이 생성되기 시작하여 결과적으로 불필요한 중복이 발생할 수 있습니다.

현재 4xx 또는 3xx 상태 코드를 제공하는 사이트맵의 이전 URL은 크롤링하거나 색인을 생성하려는 페이지가 있는 검색 엔진에 혼란스러운 신호를 보낼 수 있습니다.

해결책:

Search Console을 주시하고 나타나는 오류를 모니터링하거나 Deepcrawl과 같은 도구에서 정기적인 크롤링을 설정하여 XML 사이트맵을 정기적으로 감사해야 합니다.

Deepcrawl에서 XML 사이트맵의 정기적인 크롤링을 설정하면 사이트맵에 표시되어서는 안 되는 모든 URL에 신속하게 플래그를 지정할 수 있고 잠재적인 문제를 계속 파악할 수 있으므로 매우 유용합니다.

12. 스테이징 웹사이트가 인덱싱되고 있어 중복됨

문제:

놀랍게도 많은 회사에서 고의가 아니라 실수로 Google과 같은 검색 엔진에 색인을 생성할 수 있는 스테이징 웹사이트를 보유하고 있습니다. 스테이징 웹 사이트는 일반적으로 실제 환경의 복제본이 되므로 이로 인해 상당한 중복이 발생할 수 있습니다. Google에서 간단한 URL 프로토콜 검색을 수행하면 수백만 개의 스테이징 웹페이지가 라이브 및 색인 생성이 가능합니다.

해결책:

Semetrical에서는 스테이징 웹 사이트에 액세스하기 위해 사용자 이름과 암호를 입력해야 하는 인증 계층을 추가하는 것이 좋습니다. 허용 안 함 규칙을 추가하는 것도 준비 환경이 인덱싱되지 않도록 하는 옵션이지만 준비 사이트가 아직 인덱싱되지 않은 경우 이를 구현하는 것이 좋습니다. 예를 들어:

사용자 에이전트: *

허용하지 않음: /

대부분의 웹 사이트 크롤러 도구에는 robots.txt 덮어쓰기 기능이 있으므로 스테이징 환경에서 테스트를 수행할 때 허용 안 함 규칙을 쉽게 재정의할 수 있습니다.

13. 인덱싱되는 내부 검색

문제:

웹사이트의 내부 검색 URL은 웹사이트가 롱테일 검색어에 대해 순위를 매길 수 있도록 하거나 순위를 매길 기본 URL이 없는 키워드에 대해 순위를 매길 수 있는 SEO에 유용할 수 있습니다.

그러나 많은 경우 내부 검색 페이지는 웹사이트에서 많은 중복을 유발할 수 있으며 대규모 웹사이트에서 크롤링 예산 문제를 일으킬 수도 있습니다. 이 가이드에서는 내부 검색의 부정적인 측면에 중점을 둘 것입니다.

내부 검색 페이지는 일반적으로 최적화되지 않아 품질이 매우 낮고 많은 경우 제품과 같은 적은 수의 결과를 포함하기 때문에 씬 콘텐츠로 분류됩니다.

해결책:

내부 검색 페이지를 차단하기로 결정하기 전에 이 페이지가 현재 어떤 키워드에도 순위가 매겨지지 않았는지 또는 정기적인 트래픽을 가져오지 않는지 확인하는 것이 좋습니다.

또한 이러한 URL이 수년 동안 백링크를 구축하지 않았는지 확인합니다. 내부 검색 페이지에 신뢰할 수 있는 백링크가 없고 유기적 트래픽을 생성하지 않는 경우 Semetrical에서 다음 두 단계를 권장합니다.

1단계: NOINDEX,FOLLOW 태그를 모든 검색 페이지에 추가하여 검색 엔진이 해당 페이지의 색인을 해제할 수 있도록 합니다. 이러한 페이지가 몇 달에 걸쳐 색인이 제거되면 2단계를 구현합니다.

2단계: 내부 검색 디렉토리를 robots.txt 파일에 추가합니다(예: Disallow: */search*).

14. 중복을 유발하는 매개변수

문제:

정렬 및 필터링 매개변수 중복은 웹사이트를 감사할 때 일반적인 문제가 될 수 있습니다. 많은 웹사이트에서 사용자 경험을 향상시키고 사용자가 검색 결과를 필터링할 수 있도록 필터를 사용합니다. 그러나 주요 문제는 웹 사이트 전체에 상당한 양의 중복이 생성되기 때문에 웹 사이트에서 필터를 인덱싱할 수 있도록 유지하는 경우입니다. 예를 들어:

https://www.example.com/path1/path2?sort-by=size&sort-order=asc
https://www.example.com/path1/path2?view=grid

때때로 우리는 내부 링크의 URL 끝에 추적 매개변수를 추가하여 해당 링크가 클릭된 사이트의 위치를 ​​나타내는 웹사이트를 접하게 됩니다. 처음에는 이 설정을 권장하지 않지만 사이트에 이미 이 설정이 있는 경우 동일한 페이지의 여러 버전을 생성할 수 있으므로 웹사이트에 많은 중복이 발생할 수 있습니다. 예를 들어:

https://www.example.com/path-1/path-2?wa_origin=pa홈페이지
https://www.example.com/path-1/path-2?wa_origin=gnb
https://www.example.com/path-1/path-2?source=header

중복을 유발할 수 있는 또 다른 일반적인 추적 매개변수는 캠페인 실적을 추적하기 위해 특정 캠페인에 링크가 사용되는 UTM 추적 매개변수입니다. 예를 들어:

https://www.example.com/path-1/path-2?utm_source=creativeLIVE&utm_medium=email&utm_campaign=2020_Flash_Sale
해결책:

매개변수가 인덱싱되고 중복이 발생하는 것을 방지하는 여러 가지 방법이 있습니다. 여기에는 다음이 포함됩니다.

매개변수 URL을 깨끗한 URL 버전으로 정규화

특정 매개변수를 허용하지 않도록 robots.txt 파일에 규칙 추가

특정 매개변수를 크롤링하면 안 된다는 신호를 Google에 보내는 Search Console의 URL 매개변수 도구에 매개변수 추가

15. 제품 URL 복제

문제:

전자 상거래 웹사이트에서 제품 URL 복제는 게시자 웹사이트와 마찬가지로 큰 문제가 될 수 있습니다. 제품 URL 중복의 주된 이유는 제품이 URL 구조에서 카테고리/하위 카테고리를 상속할 수 있고 제품이 여러 카테고리/하위 카테고리에 있는 경우 여러 URL이 생성되기 때문입니다.

게시자 웹사이트에서 문서는 여러 영역에 있을 수도 있으며 문서 URL이 문서 위치를 상속하면 여러 버전이 생성됩니다. 예를 들어:

https://www.example.com/product/woman-collections-dresses/71hdo/bella-lula-floral-mini-dress
https://www.example.com/product/woman-collections-dresses-day-dresses/71hdo/bella-lula-floral-mini-dress
https://www.example.com/willsandprobate/document/introduction-to-wills
https://www.lexisnexis.com/privateclient/introduction-to-wills/
해결책:

이와 같은 중복을 발견하면 올바른 URL 버전이 크롤링되고 인덱싱되는지 확인할 수 있도록 이를 정리하는 다양한 방법이 있습니다.

URL 중복을 수정하려면 모든 제품 URL 변형을 상위 또는 일반 버전으로 정규화하는 것이 좋습니다. 예를 들어:

상위 표준 예

https://www.example.com/product/

여성 컬렉션 드레스 데이 드레스

/71hdo/bella-lula-floral-mini-dress

다음과 같이 정규화합니다.

https://www.example.com/product/

여성 컬렉션 드레스

/71hdo/bella-lula-floral-mini-dress

일반적인 표준 예:

https://www.example.com/product/

여성 컬렉션 드레스 데이 드레스

/71hdo/bella-lula-floral-mini-dress

https://www.example.com/product/

여성 컬렉션 드레스

/71hdo/bella-lula-floral-mini-dress

다음으로 정규화

https://www.example.com/product//71hdo/bella-lula-floral-mini-dress

대안:

개발자에 대한 액세스 권한이 있는 경우 대안 솔루션은 웹사이트 전체에서 제품 표준에 내부적으로 링크하고 카테고리/하위 카테고리에서 실행되는 모든 제품 URL을 일반 표준 제품 URL로 리디렉션하는 것입니다.

이렇게 하면 제품 복제가 중지되고 여러 경로를 통해 제품에 연결할 수 있습니다.

16. 웹사이트의 깊이

문제:

페이지 깊이는 웹 사이트의 홈페이지에서 특정 페이지가 클릭된 횟수입니다. 웹사이트 감사를 수행할 때 웹사이트 깊이가 10보다 큰 웹사이트를 발견합니다. 즉, 이 페이지는 홈페이지에서 10번의 클릭을 할 수 있음을 의미합니다!

웹 페이지를 찾는 데 필요한 클릭이 많을수록 검색 엔진이 해당 URL을 찾기가 더 어려워지고 웹 사이트의 상위 페이지만큼 자주 URL을 다시 방문하지 않을 가능성이 높아집니다.

또한 웹 사이트 아키텍처 내에서 페이지가 높을수록 검색 엔진에서 우선 순위 페이지로 표시될 가능성이 높아집니다. 아키텍처에서 우선 순위 페이지가 더 낮으면 순위가 좋지 않을 위험이 있습니다.

해결책:

웹 사이트 깊이를 개선하고 웹 사이트 아키텍처에서 우선 순위 페이지가 높은지 확인하는 주요 방법은 다음과 같습니다.

추천 상품, 관련 상품, 추천 페이지 등 웹사이트 전반의 내부 링크

웹사이트에서 이동 경로 사용

현재 있는 페이지의 첫 번째, 마지막 및 두 개의 결과 페이지를 포함하는 페이지 매김 설정

웹사이트의 메인 탐색 내에서 링크되어야 하는 최상위 카테고리 페이지를 찾기 위한 키워드 연구 수행 및 우선 순위 페이지에 대한 링크 추가

17. 자바스크립트 기술 SEO 문제

문제

오늘날 많은 웹 사이트에서 JavaScript를 사용하지만 JavaScript를 비활성화하면 일부 웹 사이트가 완전히 작동하지 않고 링크가 사라지고 검색 엔진에서 검색되지 않을 수 있습니다. 이것은 일반적인 기술 SEO 문제입니다.

종종 우리는 전자 상거래 제품 페이지의 "당신도 좋아할 수 있는" 모듈을 검색 엔진 크롤러가 볼 수 없어 내부 연결 모듈이 중복되는 것을 봅니다.

또한 키워드가 풍부한 UGC를 포함하는 리뷰 모듈은 크롤러에서도 검색할 수 없는 JavaScript 모듈 내에 있습니다.

다양한 전자 상거래 웹 사이트의 흥미로운 문제는 결과 페이지에서 JavaScript를 비활성화할 때 제품 링크는 계속 찾을 수 있지만 검색할 이미지에 대한 대체 옵션이 없기 때문에 모든 이미지가 사라진다는 것입니다.

해결책:

개발 팀과 협력하여 HTML을 통해 크롤링할 수 있는 JavaScript 모듈과 소스 코드에 이미지가 여전히 존재하는 JavaScript 대체를 시도하고 만듭니다.

JavaScript 콘텐츠가 어떻게 색인되는지 테스트하는 가장 좋은 방법은 웹페이지의 캐시된 버전으로 이동하여 페이지의 "전체 버전"이 어떻게 보이는지 확인하고 "텍스트 전용 버전"을 검토하는 것입니다.

18. 메타로봇 NOINDEX의 잘못된 사용

문제:

우리의 기술 SEO 팀은 웹사이트를 감사했으며 NOINDEX 태그가 실수로 페이지의 소스 코드에 추가되었음을 발견했습니다. 또한 과거에 NOINDEX 태그가 있는 트래픽을 가져온 페이지를 보았습니다.

놀랍게도 개발자가 소스 코드에 여전히 존재하는 NOINDEX 태그를 사용하여 스테이징 환경을 라이브로 푸시하는 개발자가 생각하는 것보다 더 자주 발생할 수 있는 문제입니다.

궁극적으로 NOINDEX 태그는 검색 엔진에 페이지를 인덱싱하지 않도록 지시하고 페이지가 검색 결과에 표시되지 않도록 합니다.

해결책:

웹사이트를 감사할 때 NOINDEX 태그가 있는 페이지를 발견했는데 태그가 있는 이유가 명확하지 않은 경우 개발 팀에 문의하여 해당 페이지에 태그가 포함된 시기와 이유를 확인하세요.

NOINDEX 태그가 실수로 추가된 경우 개발자에게 소스 코드를 업데이트하고 태그를 완전히 제거하도록 요청하거나 <meta name=”robots” content=” INDEX, FOLLOW”>를 읽도록 업데이트해야 합니다.

19. 소프트 404페이지

문제:

소프트 404 페이지는 웹사이트에 존재해서는 안 됩니다. 이는 404 상태 코드를 반환해야 하는 존재하지 않는 페이지가 200 OK 상태 코드를 반환할 때 발생합니다. 404 페이지가 200 상태 코드를 반환하는 경우에도 여전히 크롤링하고 색인을 생성할 수 있습니다.

이는 Google과 같은 검색 엔진이 귀중한 페이지에 시간을 집중하는 대신 크롤링 예산을 낭비하는 가치가 없는 이러한 페이지를 크롤링하는 데 시간을 낭비할 수 있기 때문에 궁극적으로 문제입니다. 이러한 페이지는 특히 웹사이트에 "페이지를 찾을 수 없음" 메시지를 표시하는 1,000개의 소프트 404 페이지가 있는 경우 웹사이트에서 중복 문제를 생성할 수 있습니다.

다음을 포함하여 소프트 404 페이지를 찾는 몇 가지 다른 방법이 있습니다.

소프트 404 페이지를 표시하는 Search Console 방문

웹사이트를 크롤링하고 "페이지를 찾을 수 없음"이라는 제목 태그가 있는 200개의 상태 코드 페이지를 찾습니다.

404 상태 코드 페이지와 해당 메시지가 있는 200 상태 코드 페이지에 있는 본문 사본 메시지를 찾는 사용자 지정 추출로 웹사이트를 크롤링하는 것은 소프트 404여야 합니다.

해결책:

웹사이트에서 소프트 404 페이지를 발견하면 구현할 수 있는 몇 가지 솔루션이 있습니다. 여기에는 다음이 포함됩니다.

301 소프트 404 페이지를 사용 가능한 경우 적절한 대체 페이지로 리디렉션

이 페이지의 상태 코드를 404 또는 410 상태 코드로 변경하되 링크 자산이 손실되지 않는지 확인하십시오.

웹사이트에 문제가 있거나 기술적인 SEO 감사가 필요한 경우 Semetrical이 어떻게 도움을 줄 수 있는지에 대한 자세한 내용은 기술적인 SEO 서비스 페이지를 방문하십시오.