2019년 가을 기술 SEO 체크리스트
게시 됨: 2019-10-16여름이 끝났고 풍선 백조와 선탠 로션을 싸서 웹사이트를 검색 엔진 친화적으로 만들기 위해 바로 뛰어들 시간입니다! 꽤 많은 작업이 될 수 있으므로 작업을 조금 단순화하기 위해 간략한 설명과 함께 14가지 핵심 사항에 중점을 둔 목록을 작성했으며 공간이 제한적이므로 모범 사례 및 유용한 팁을 설명하는 리소스 링크를 작성했습니다.
다음은 우리가 확인할 14가지 항목의 목록입니다.
– HTTPS, HTTP/2, www
– 페이지 상태 2xx, 3xx, 4xx, 5xx
– 고아 페이지
– 로봇.txt
– 사이트맵
– 모바일 친화적
– 페이지 속도 TTFB,
– 축소 자원
– 캐시
– Canonical 및 Hreflang
– 제목, 설명, H1
– 이미지 : 크기, 대체, 제목 및 그림
– Schema.org 구조화된 데이터
– 시맨틱 HTML5 구조
시작하기 전에 OnCrawl 또는 기타 크롤러 애플리케이션을 사용하여 사이트를 크롤링해야 합니다.
심호흡을하고 시작합시다!
#1 HTTPS, HTTP/2, www, HSTS
HTTPS
HTTPS는 Google 및 기타 검색 엔진의 최우선 순위입니다.
사이트를 크롤링하지 않고도 다음을 통해 https 처리의 견고성을 쉽게 테스트할 수 있습니다.
- 먼저 주소 표시줄에 "https://" 없이 도메인만 입력하면 다음과 같이 자물쇠가 표시됩니다.
둘째, 도메인을 입력하되 이번에는 "http://"를 입력하고 "https://" 프로토콜로 리디렉션해야 합니다.
크롤링 결과를 보고 http://로 시작하는 내부 URL을 찾습니다. 찾으면 모두 https://로 리디렉션되어야 하며(또는 .htaccess 파일에서 재작성 사용) 사이트 코드를 살펴보고 href 링크에서 https://로 교체해야 합니다. .
www / 비 www
Google의 Search Console은 웹사이트 URL의 www 버전과 www가 없는 버전의 데이터를 구별하는 데 사용되지만 도메인 속성을 도입한 이후에는 데이터가 결합됩니다. 그러나 사이트 전체에서 www 또는 www가 없는 URL을 일관되게 사용하는 것은 품질의 지표이므로 크롤링 결과를 살펴보고 잘못된 버전의 리디렉션이 있는지 확인하고(또는 .htaccess 파일에서 재작성을 사용) 사이트 코드에서 잘못된 URL을 업데이트하십시오.
HTTP/2
사이트에서 HTTP 요청을 많이 하는 경우(이상적으로는 그렇게 해서는 안 됨) 요청을 차례로 보내는 것이 아니라 동시에 보내는 HTTP/2를 사용하여 페이지 로드 속도를 높일 수 있습니다. 여기에서 서버가 HTTP/2를 지원하는지 확인할 수 있으며, 지원하지 않는 경우 구성 변경에 대해 사이트 개발자에게 문의하세요.
HSTS
보안은 웹사이트에서 항상 문제가 되지만 조금 더 나아가고 싶다면 HSTS(Http Strict Transfer Security) 헤더와 함께 HTTPS를 강제로 사용하는 것을 고려하십시오.
#2 페이지 상태 2xx, 3xx, 4xx, 5xx
크롤링 결과를 보면 각 URL(페이지, 이미지, CSS 파일, 자바스크립트 파일 등)에 대한 상태 코드가 표시됩니다.
- 200 은 성공을 의미합니다!
- 301 은 영구 리디렉션입니다. 301을 제공하는 내부 링크는 가능한 한 적어야 하므로 사이트의 html을 살펴보고 리디렉션되는 URL을 리디렉션의 대상 URL로 바꾸십시오.
- 302 는 임시 리디렉션이므로 필요한 경우 대신 301을 사용해야 합니다.
- 400, 410 등의 코드는 파일을 찾을 수 없음을 의미합니다. 이들 중 아주 적은 비율을 갖는 것은 큰 문제가 아니지만(어쨌든 Google 색인에서 제거될 것입니다) 색인을 생성하려는 파일일 수 있으며 해당 파일에 대한 액세스가 차단되거나 URL이 예를 들어 악센트가 있는 문자 또는 기타 비표준 문자가 포함되어 있습니다.
- 5xx 상태의 URL은 0개여야 합니다!
자세한 내용은 다양한 https 상태 코드에 대한 이 문서를 참조하십시오.
#3 고아 페이지
고아 페이지는 사이트의 다른 페이지와 연결되지 않은 페이지로 사이트가 매우 크거나 수년 동안 온라인 상태였거나 재구성되었을 때 발생할 수 있습니다. 그들은 당신의 SEO를 위한 낭비된 기회입니다! 스프레드시트를 사용하여 Search Console에서 내보낸 페이지 목록과 함께 사이트를 통해 크롤링된 페이지 목록을 상호 참조하거나(Google에서 색인을 생성한 고아 페이지 가져오기) Oncrawl을 사용하여 상호 참조하여 수동으로 찾을 수 있습니다. 인덱싱 여부에 관계없이 한 번 이상 방문한 모든 고아 페이지에 대한 로그 분석을 사용합니다. 사이트 소유자는 종종 사이트의 어두운 구석에 얼마나 많은 물건이 숨어있을 수 있는지에 놀라곤 합니다!
#4 Robots.txt
사이트 루트에 robots.txt 파일이 있어야 합니다(예: https://mydomain.com/robots.txt). 여기에는 일반적으로 사이트의 어떤 부분이 검색 엔진 로봇에 액세스할 수 있고 어떤 부분이 액세스할 수 없는지 설명하는 지침이 포함되며 지나치게 광범위한 제한으로 인해 사이트의 일부가 인덱싱되지 않을 수 있습니다. 또한 다음과 같은 사이트의 사이트맵에 대한 링크도 포함해야 합니다.
#5 XML 사이트맵
페이지의 전체 목록이 포함된 사이트맵이 있어야 하며 최신 상태여야 합니다. 일부 플러그인 및 크롤링 소프트웨어는 사이트맵을 생성하지만 수동으로 수행할 수 있으며 필요한 기본 구조는 다음과 같습니다.
속성은 페이지가 마지막으로 업데이트된 날짜이며 중요합니다. 여기에서 사이트맵에 대한 더 많은 정보를 찾아보십시오.
#6 모바일 친화적
이것은 그 자체로 전체 주제입니다! Google 색인은 모바일 우선이므로 최근 변경사항으로 인해 모바일 친화적이지 않은 사이트인지 정기적으로 확인해야 합니다. 여기에서 Google 모바일 봇이 사이트를 어떻게 보는지 테스트하세요.
페이지가 전 세계적으로 모바일 친화적인 것으로 간주되더라도 종종 발견한 문제에 대한 힌트를 제공합니다.
#7 페이지 속도: TTFB
페이지 속도는 매우 중요합니다. 여기에 영향을 미치는 여러 요인이 있으며 이 기사에서 몇 가지 더 살펴보겠습니다. 그러나 가장 기본적인 요인 중 하나는 TTFB(Time To First Bite)입니다. 즉, 링크를 클릭할 때와 데이터의 첫 번째 바이트가 브라우저에 수신되는 순간. Page Speed Insights, Pingdom 또는 Chrome 개발자 도구에서 확인할 수 있으며 이상적으로는(Google의 의견으로는) 200밀리초 미만이어야 합니다.
느린 서버에 사이트가 부풀려져 있다면 그 속도는 쉽게 10배가 될 수 있습니다. 귀하의 비즈니스에 가치가 있다면 좋은 호스팅을 받으십시오. 이제 WordPress와 같은 CMS를 위해 고도로 최적화된 초고속 호스팅 서비스가 증가하고 있습니다.
#8 페이지 속도: 페이지 리소스 최소화
많은 사이트에서 페이지 렌더링 및 상호 작용, 특히 WordPress와 같은 플러그인이 많이 사용되는 CMS에 필요한 많은 추가 리소스(예: CSS 및 자바스크립트 파일)를 로드합니다. 따라서 홈페이지의 페이지 소스를 열고 ".js"를 검색(Ctrl+F)하십시오.
이러한 파일 각각에는 별도의 http 요청이 필요하며 다운로드할 데이터가 더 많습니다.
따라서 먼저 "모든 플러그인과 기타 자바스크립트 상호 작용이 실제로 사용자 경험을 향상시키는가?"라고 자문해 보십시오. 그렇다면 훌륭하지만 가능한 한 많은 js 파일을 하나의 단일 파일로 결합한 다음 크기를 줄이기 위해 축소해야 합니다. 플러그인이 없으면 온라인 도구가 많이 있습니다. 그런 다음 CSS 파일에 대해 동일한 작업을 수행합니다.
#9 페이지 속도: 캐시 및 CDN
특정 상황에 따라 구현하는 여러 방법이 있으므로 캐시를 사용하여 자주(또는 전혀) 변경되지 않는 페이지와 파일을 제공하는 것은 그 자체로 또 다른 주제이지만 속도를 높이는 좋은 방법입니다. 사이트 로딩.
CDN은 이미지와 같은 사이트에 대한 모든 정적 파일 전송을 처리하는 빠른 콘텐츠 전달 서버로 구성된 서비스로, 훨씬 더 가벼운 워크로드인 html을 생성하기 위해 자체 사이트 서버를 남겨둡니다. 일부 CDN은 요청에 특정 치수가 전송되는 경우 즉시 이미지 크기를 조정합니다.
캐시 시스템이 있는지 여부와 이를 구현할 가능성에 대해 사이트 개발자에게 문의하십시오.
#10 정식 및 Hreflang
hreflang 속성은 같은 페이지의 다른 언어 버전이 있는 경우 가장 중요하지만 Google이 단일 언어 페이지에서도 검색하기 때문에 표준 태그와 함께 어쨌든 넣어야 합니다. 여기에서 표준 태그 사용에 대해 자세히 알아보세요.
페이지의 소스 코드 섹션을 살펴보십시오. 표준 태그에는 해당 페이지의 URL이 포함되어야 하고 hreflang 속성은 각 언어 버전의 URL을 가리켜야 합니다. 다음과 같이 현재 페이지의 언어:
#11 제목, 설명, H1
사이트 페이지를 크롤링하여 이를 확인할 수 있습니다. 이 3가지 요소를 작성하는 방법에 대한 자세한 내용은 여기를 참조하세요.
제목
모든 페이지에는 고유한 제목이 있어야 합니다. 길이는 15~40자여야 하며 "멋진", "미친" 및 "믿을 수 없는"과 같은 단어를 피하고 키워드를 포함해야 하며 사람들이 검색 결과에서 가장 먼저 보게 되는 것이므로 사용자의 질문에 정확하게 대답해야 합니다. 검색어.
설명
순위를 매길 페이지에는 독특하고 매력적인 메타 설명이 있어야 합니다. 설명 자체는 순위 요소가 아니지만 매력적이고 클릭 유도문안이 있는 경우 검색 결과 페이지에 표시되는 설명 텍스트로 Google에서 자주 사용하기 때문에 클릭률이 더 높아집니다.
H1
<h1>태그는 주요 콘텐츠 헤더 제목이며 모든 페이지에서 고유해야 합니다. 이 페이지는 사용자가 페이지에서 가장 먼저 보게 되는 것이어야 하며 이 페이지가 필요한 정보를 제공할 것임을 사용자를 안심시켜야 합니다.
#12 이미지: 크기, 대체, 제목 및 그림
크롤링 데이터의 이미지 섹션을 보고 아래 사항을 고려하십시오. 여기에서 이미지에 대한 훨씬 자세한 정보를 얻을 수 있습니다.
- 표준 페이지 이미지는 상단 100k보다 커서는 안 됩니다. 그렇지 않으면 특히 모바일에서 페이지 로딩 속도가 느려집니다. 특히 기여자가 업로드한 이미지를 보십시오. 블로그 페이지에서 5MB의 이미지를 보았습니다!
- 특수 문자가 없는 유용한 이름인지 확인하십시오("404 파일을 찾을 수 없음" 상태가 아님).
- 이미지에는 "alt" 속성 값이 있어야 하며 이미지를 설명해야 합니다.
- 제목 속성은 필수는 아니지만 기회이기도 합니다.
- 다음과 같이 HTML5 시맨틱 태그 <Figure>를 이미지 주위에 사용하고 </Figure>를 추가합니다.
Google의 John Mueller는 Google 이미지 검색이 alt와 figcaption을 보고 별개의 개체로 취급한다고 말했습니다.
#13 Schema.org 구조화된 데이터
Schema.org 구조화된 데이터는 검색 엔진에 정보를 전달하는 필수 수단이 되었으며 그 자체로 또 다른 방대한 주제이지만 구조화된 데이터 테스트 도구에서 페이지 URL을 테스트하여 정보가 존재하고 올바르게 사용되는지 확인할 수 있습니다.
다음과 같은 구조화된 데이터가 있어야 합니다.
- 홈페이지 및 회사 소개 페이지에는 최소한 조직 유형에 대해 최대한 구체적으로 전체 마크업이 있어야 합니다. LocalBusiness인 경우 하위 유형을 살펴보십시오. 설립자 식별, 소셜 계정 연결, 공식 회사 식별 사이트, 회사가 속한 모든 전문 조직 등의 특정 데이터를 최대한 많이 포함하여 Google의 이해도와 신뢰를 높이고 순위를 높일 수 있습니다.
- 제품 및 서비스 페이지에는 제공자(또는 다른 회사에서 제공하는 서비스를 나열하는 경우 브로커) 및 서비스에 대한 areaServed 속성으로 귀하의 회사에 연결하는 전체 데이터가 포함됩니다.
- 사이트에 리뷰 플랫폼에 대한 리뷰가 있는 경우 스키마에서 리뷰를 표시하고, LodgingBusiness 또는 FoodEstablishment이고 별이 있는 경우 starRating을 사용하십시오.
- 블로그 기사는 DatePublished 및 DateModified를 포함하여 완전히 마크업되어야 하며 작성자에 대한 전체 정보와 사이트 또는 소셜 계정 페이지에 대한 링크가 포함되어 있어 전문 지식을 보여야 합니다.
이는 Schema.org 구조화된 데이터 마크업이 제공하는 가능성 중 일부일 뿐입니다. 페이지 html 태그에 인라인으로 포함하는 대신 JSON-LD 형식을 사용해야 합니다.
[전자책] 비기술적 사상가를 위한 기술 SEO
전자책 읽기#14 시맨틱 HTML5 구조
이것이 우리 목록에서 확인할 마지막 사항입니다. Semantic HTML5 태그에 대한 내 기사에서 설명했듯이 이러한 태그를 사용하는 한 가지 목표는 페이지의 어느 부분에 고유하고 중요한 콘텐츠가 포함되어 있는지 정확하게 알려줌으로써 Google의 삶을 더 쉽게 만드는 것입니다. 따라서 기사 등이 포함된 섹션을 포함하는 섹션이 지나치게 복잡한 구조를 갖고 있다면(이미지에서처럼) 상황을 더 복잡하게 만들고 있는 것입니다! 좋은 간단한 구조의 예를 보려면 기사를 살펴보고 Semantic HTML5 뷰어에서 테스트하십시오.
마지막 한마디
휴, 꽤 탔습니다! 이 모든 사항을 확인했다면 검색 엔진 알고리즘이 좋아할 세련된 고성능 정보 시스템으로 웹사이트를 만드는 것입니다!
한 가지 더: 일반 사용자인 것처럼 사이트를 테스트합니다 . "잠깐, 뭐?!"라고 생각할 수도 있습니다. 그러나 사람들이 자신의 사이트를 테스트하는 경우가 얼마나 드물고 주문하고 문의 양식을 찾는 등의 작업이 매우 어렵다는 사실을 알게 되면 놀라실 것입니다. 지금 하십시오!
좋은 가을 보내세요!