SEO 최적화 기술, 초보 웹사이트 구축자에게 꼭 필요한 기술

SEO 최적화

SEO최적화 구글 SEO어떻게 하나요? 바이두 SEO와 어떻게 다른가요? 기본적으로 큰 차이는 없지만, 세부적인 부분에서는 약간의 차이가 있습니다.Google SEO는 매우 중요합니다. 며칠 전, 국내 대형 전자상거래 회사의 SEO 부서 친구가 구글 검색 순위에 대해 매우 흥미로운 질문을 했습니다. 한두 문장으로 설명하기가 어려워서 글을 작성했는데, 다른 SEO 담당자분들께 도움이 될 것 같습니다.

TDK 최적화

티디케이(TDK)제목,설명,키워드세 가지를 모두 포괄하는 용어입니다. 물론제목가장 유용하며 최적화할 가치가 매우 높습니다.키워드과거에 SEO 담당자들이 과도하게 사용했기 때문에 지금 이것을 최적화해도 검색 엔진에는 쓸모가 없으므로 여기서는 설명하지 않겠습니다.설명설명은 검색 소개에 바로 표시되므로 사용자가 클릭할지 여부를 판단하는 데 매우 효과적입니다.

타이틀 최적화

제목분리기는 일반적으로,,_,-등, 그중_바이두에 더 친화적입니다.-Google에서 더 사용하기 편리합니다. 네 번째 문자는 공백입니다. 영어 사이트에서는 사용할 수 있지만 중국어 사이트에서는 거의 사용되지 않습니다.제목길이는 일반적으로 PC에서는 약 30자, 모바일에서는 약 20자입니다. 이 길이를 초과하는 경우 생략 부호로 처리됩니다.

사업 관계로 인해 우리는 Baidu 검색 엔진 최적화에 더욱 집중하고 있습니다. 따라서 Baidu 검색 엔진 최적화에 대한 몇 가지 제안을 드리겠습니다.

제목체재:

첫 페이지:웹사이트 이름 또는 웹사이트 이름_서비스 소개 또는 제품 소개 제공
채널 페이지:채널 이름_웹사이트 이름
기사 페이지:기사 제목_채널 이름_웹사이트 이름

기사 제목이 너무 길지 않은 경우 다음을 추가할 수도 있습니다.키워드들어가다,기사 제목_키워드_웹사이트 이름

권장 사례:

각 웹 페이지는 고유한 제목을 가져야 합니다. 모든 페이지에 동일한 기본 제목을 사용하지 마세요.
제목은 명확해야 하며 이 웹페이지의 가장 중요한 내용을 담고 있어야 합니다.
간결하게 작성하고 웹페이지의 내용과 관련이 없는 정보는 나열하지 마세요.
사용자는 일반적으로 왼쪽에서 오른쪽으로 탐색하며, 중요한 콘텐츠는 제목의 앞쪽에 배치해야 합니다.
사용자에게 친숙한 언어를 사용하세요. 웹사이트 이름이 중국어와 영어가 모두 있는 경우, 사용자에게 친숙한 언어를 제목 설명으로 사용하는 것이 좋습니다.

설명 최적화

설명가중치 계산의 기준이 되지 않습니다. 이 태그의 존재 여부는 웹페이지의 가중치에 영향을 미치지 않습니다. 검색 결과 요약을 위한 선택 기준으로만 사용됩니다. 길이는 PC에서는 약 78자, 모바일에서는 약 50자입니다. 초과 시 생략 부호로 처리됩니다.

바이두에서는 다음을 추천합니다.

설명은 요약으로 사용할 수 있는 긴 텍스트 문단이 없는 웹사이트 홈페이지, 채널 페이지, 제품 매개변수 페이지 등에 가장 적합합니다.
페이지를 정확하게 설명하고 키워드를 채우지 마세요.
모든 페이지에 동일한 설명을 사용하지 않으려면 각 페이지에 대해 다른 설명을 만드세요.
적당한 길이, 너무 길지도 짧지도 않음

아래는 바이두에서 비교를 위해 추천하는 두 가지 예시입니다. 첫 번째 예시는 메타 설명을 적용하지 않는 반면, 두 번째 예시는 메타 설명을 적용합니다. 첫 번째 결과 요약은 사용자에게 실질적으로 참조 가치가 없는 반면, 두 번째 결과 요약은 가독성이 더 뛰어나 사용자가 웹사이트 콘텐츠를 더 잘 이해할 수 있도록 도와줍니다.

페이지 콘텐츠 최적화

HTML5 구조 사용하기

조건이 허락하는 경우 (예: 모바일 단말기, IE9+ 호환, IE8+인 경우 IE8로 도입)html5.js이제 HTML5 의미 태그를 사용할 것을 고려할 때입니다.헤더,보행인,부분,곁에,내비게이션,기사잠깐, 여기서 전체 레이아웃을 보기 위해 스크린샷을 찍습니다.

고유한 H1 제목

각 페이지에는 고유한 h1 제목이 있어야 하지만 모든 페이지의 h1 제목이 사이트 이름은 아닙니다. (그러나 HTML5에서는 h1 제목이 여러 번 나타날 수 있으며 구조적 윤곽이 있는 각 태그는 다음과 같이 자체적인 독립적인 h1 제목을 가질 수 있습니다.헤더,보행인,부분,곁에,기사）

홈페이지의 h1 제목은 사이트 이름이고, 내부 페이지의 h1 제목은 각 내부 페이지의 제목입니다. 예를 들어, 카테고리 페이지는 카테고리 이름을 사용하고, 상세 페이지는 상세 페이지 제목을 h1 제목으로 사용합니다.

<!-- 첫 페이지 -->
<h1 수업="페이지-tt">텐센트 교실</h1>
<!-- 카테고리 페이지 -->
<h1 수업="페이지-tt">프런트엔드 개발 온라인 교육 비디오 튜토리얼</h1>
<!-- 세부 정보 페이지 -->
<h1 수업="페이지-tt">HTML5+CSS3</h1>

이미지 설정`대체`재산

이미지필수의대체속성의 너비와 높이가 고정되어 있는 경우 고정된 값을 동시에 설정해 주세요.

<img src="" alt="seo优化实战" width="200" height="100" />

노팔로우

추적 및 크롤링이 필요하지 않은 링크의 경우 설정하세요.노팔로우블로그 댓글, 포럼 게시물, 소셜 네트워킹 사이트, 메시지 게시판 등에 사용할 수 있습니다. 또한 광고 링크, 개인정보 보호정책, 사용자 약관, 로그인 등에도 사용할 수 있습니다. 다음 코드는 링크를 추적하고 크롤링할 필요가 없음을 나타내며, 이를 통해 스파이더가 크롤링하고 가중치를 이전하는 것을 방지할 수 있습니다.

<a href="http://example.com" 상대="노팔로우">팔로우 링크 없음</에이>

텍스트

콘텐츠 고려 사항:

자연 글쓰기
고품질의 오리지널 콘텐츠
독자를 끌어들이는 글쓰기 기술
판매 포인트를 강조하세요
신뢰를 강화하다
추가적인 행동으로 이어짐

사용자 경험 고려 사항:

레이아웃은 합리적이고 명확하며 아름답고 글꼴과 배경은 읽기 쉽습니다.
실제 콘텐츠는 페이지의 가장 중요한 위치에 있으며 사용자는 한눈에 볼 수 있습니다.
실질적인 콘텐츠와 광고는 명확하게 구별될 수 있습니다.
첫 번째 화면에는 스크롤을 내려서 볼 필요 없이 상당한 양의 콘텐츠가 있습니다.
광고의 개수는 너무 많아서는 안 되며, 광고의 위치가 사용자의 독서를 방해해서는 안 됩니다.
만약 사진과 비디오가 사용자가 페이지의 내용을 이해하는 데 도움이 될 수 있다면, 사진과 비디오 등을 만들어 보세요.
팝업을 너무 많이 표시하지 마세요

URL 최적화

URL 디자인 원칙:

짧을수록 좋다
매개변수를 너무 많이 사용하지 마세요
디렉토리 수준을 가능한 한 작게 유지하세요
설명적인 파일 및 디렉토리 이름을 사용하세요
URL에 키워드를 포함하세요(중국어 제외)
모든 소문자
하이픈 사용-오히려_
파일 형식이 아닌 디렉토리 형식

정적 URL

현재 검색 엔진 크롤링 기능을 사용하면 URL을 정적으로 만들 필요는 없지만 포함의 용이성, 사용자 경험 및 소셜 공유 측면에서 정적이고 짧은 URL이 더 유리합니다.

URL은 정적인가요?

데이터베이스 기반 웹사이트는 URL을 고정해야 하는데, 이는 SEO의 가장 기본적인 요건이자 상식입니다. 안타깝게도 지금은 데이터베이스 기반이 아닌 웹사이트가 거의 없습니다.

최근 몇 년 동안 SEO 업계는 URL에 물음표가 2~3개 있어도 문제가 되지 않는다는 데 만장일치로 동의했습니다. 검색 엔진이 일반적으로 URL을 인덱싱할 수 있기 때문이며, 특히 권한이 높은 도메인의 경우 더욱 그렇습니다. 또한 물음표가 더 많아도 문제가 되지 않습니다. 하지만 일반적으로 URL은 정적인 URL로 만드는 것이 좋습니다.

2008년 9월, 구글 웹마스터 블로그는 동적 URL과 정적 URL을 비교하는 게시물을 게시했는데, 이는 이러한 관점을 뒤집는 것이었습니다. 이 게시물에서 구글은 동적 URL을 정적 URL로 만들지 말고, 물음표 매개변수가 있는 긴 동적 URL을 유지할 것을 명시적으로 권고했습니다. 구글 블랙보드와 중국 웹마스터 블로그에서 이 게시물을 번역하여 다시 게시했으니, 확인해 보세요.

제가 읽은 댓글과 블로그를 보면, 실제로 많은 사람들이 그것이 합리적이라고 생각하고 Google이 말하는 대로 할 준비가 되어 있는 것 같습니다.

이건 구글에서 제안한 비교적 드문 SEO 제안인데, 저는 이에 강력히 반대합니다.

Google의 게시물에는 몇 가지 핵심 내용이 있습니다.

첫째, 구글은 동적 URL을 크롤링할 수 있는 충분한 역량을 갖추고 있으며, 물음표가 아무리 많아도 문제가 되지 않습니다. 이는 기본적으로 신뢰할 수 있는 정보입니다. 하지만 URL에 물음표와 매개변수가 10개 또는 20개 이상 있다면 어떨까요? 구글은 이를 어떻게 인식할까요? 크롤링할 수 있다고 해도 기꺼이 크롤링할까요? 다른 검색 엔진들은 이를 어떻게 처리할까요?

둘째, 동적 URL은 구글 스파이더가 URL의 의미를 이해하고 식별하는 데 더 유용합니다. URL의 매개변수가 암시적인 의미를 갖기 때문입니다. 예를 들어 구글은 다음과 같은 예를 제시했습니다.

http://www.example.com/article/bin/answer.foo?language=en&answer=3&sid=98971298178906&query=URL

URL의 매개변수는 Google이 URL과 웹페이지의 내용을 이해하는 데 도움이 됩니다. 예를 들어, language 뒤의 매개변수는 프롬프트 언어, answer 뒤의 매개변수는 기사 번호, sid 뒤의 매개변수는 세션 ID를 나타냅니다. 일반적으로 사용되는 다른 매개변수로는 color 뒤의 매개변수가 색상을 나타내고, size 뒤의 매개변수가 크기를 나타내는 등입니다. 이러한 매개변수를 통해 Google은 웹페이지를 더 쉽게 이해할 수 있습니다.

URL이 정적이면 이러한 매개변수의 의미가 명확하지 않게 되는 경우가 많습니다. 예를 들어 다음 URL은 다음과 같습니다.

http://www.example.com/shoes/red/7/12/men/index.html

이로 인해 Google에서는 어떤 것이 제품 일련번호이고, 어떤 것이 크기인지 등을 파악하는 것이 불가능해질 수 있습니다.

셋째, URL을 정적으로 만들면 실수를 하기 쉽고, 이는 더욱 비생산적입니다. 예를 들어, 동적 URL에서 매개변수 순서를 변경하면 결과 페이지는 실제로 동일합니다. 예를 들어, 다음 두 URL은 동일한 페이지일 가능성이 높습니다.

http://www.example.com/article/bin/answer.foo?language=en&answer=3

http://www.example.com/article/bin/answer.foo?answer=3&language=en

동적 URL을 유지하면 Google에서 두 URL이 동일한 웹페이지임을 더 쉽게 파악할 수 있습니다. 정적 URL을 생성한 후에는 Google에서 두 URL이 동일한 페이지인지 판단하기 어려워 중복 콘텐츠가 발생할 수 있습니다.

http://www.example.com/shoes/men/7/red/index.html

http://www.example.com/shoes/red/7/men/index.html

또 다른 일반적인 실수는 세션 ID인데, 이는 URL에 정적으로 인코딩될 수도 있습니다.

http://www.example.com/article/bin/answer.foo/en/3/98971298178906/URL

이렇게 하면 URL은 다르지만 내용은 동일한 수많은 페이지가 생성됩니다.

따라서 Google에서는 URL을 정적으로 만들지 않는 것을 권장합니다.

하지만 저는 여전히 정적인 방법을 권장합니다. 그 이유는 다음과 같습니다.

우선, 구글의 조언은 다른 검색 엔진을 고려하지 않은 구글 자체의 조언입니다. 구글이 동적 URL 크롤링에 아무런 문제가 없다고 해서 야후, 바이두, 마이크로소프트 등이 동적 URL 크롤링에 전혀 문제가 없다는 뜻은 아닙니다. 특히 중국 웹사이트의 경우, 구글이 절대적인 우위를 점하고 있지 않습니다. 실제로 바이두는 2021년 현재까지도 의문부호가 여러 개 붙은 URL 크롤링을 꺼리고 있습니다.

둘째, 구글이 언급한 정적화의 단점은 정적화가 잘못 수행되었다는 가정에 기반합니다. 문제는 정적화를 하려면 올바르게 수행해야 한다는 것입니다. 정적화가 잘못 수행될 것이라고 가정하는 것은 의미가 없습니다. URL을 정적화할 때 세션 ID를 입력하는 사람이 얼마나 될까요?

셋째, Google의 제안은 일반적으로 Google 자체에는 유리하지만 사용자에게는 유리하지 않습니다. 물음표 매개변수가 있는 URL은 Google이 콘텐츠를 이해하는 데 도움이 될 수 있지만, 사용자가 웹사이트 구조와 전반적인 콘텐츠를 한눈에 파악하기는 매우 어렵습니다. 이 두 URL 중 어느 것이 더 명확하고, 읽기 쉽고, 클릭 가능성이 더 높을까요?

http://www.example.com/product/bin/answer.foo?language=en&productID=3&sid=98971298178906&cat=6198&&query=URL

http://www.example.com/product/men/shoes/index.html

당연히 두 번째죠.

게다가 긴 동적 URL은 기억에 도움이 되지 않으며, 이메일이나 소셜 네트워크 사이트 등에 다른 사람에게 복사하기에도 편리하지 않습니다.

간단히 말해서, Google에서는 동적 URL을 유지하는 것을 분명히 권장하지만, 저는 그 반대로 URL을 최대한 정적으로 만드는 것을 권장합니다.

URL 정규화

1. 통합 연결

http://www.도메인 이름.닷컴
http://도메인 이름.닷컴
http://www.도메인 이름.닷컴/색인.HTML
http://도메인 이름.닷컴/색인.HTML

위 네 가지는 실제로는 홈페이지입니다. 방문자에게는 아무런 문제가 없지만, 검색 엔진에게는 동일한 콘텐츠를 가진 네 개의 URL일 뿐이므로 부정행위로 오인될 수 있습니다. 검색 엔진이 URL을 표준화하려면 이러한 옵션 중 가장 적합한 URL을 선택해야 하지만, 그들이 선택한 URL이 사용자가 원하는 URL이 아닐 수도 있습니다. 따라서 직접 표준화하는 것이 가장 좋습니다.

2. 301 리다이렉션

첫 번째는 URL이 변경될 때입니다. 이전 주소 301을 새 주소로 연결해야 합니다. 그렇지 않으면 이전의 모든 포함 가중치가 무효화됩니다.

두 번째는 일부입니다센세이션시스템에서는 여러 경로가 동일한 문서에 해당할 가능성이 매우 높습니다.드루팔기본 경로는 다음과 같습니다.노드/니드하지만 경로 토큰이 활성화되어 있다면 경로를 직접 설정할 수 있습니다. 이렇게 하면 동일한 게시물에 해당하는 두 개의 경로가 생성됩니다. 따라서 301을 활성화하고 최종적으로 하나의 경로로 리디렉션할 수 있습니다.

3. 정식

이 태그는 페이지의 고유성을 나타냅니다(이전에는 Baidu에서 지원하지 않았지만, 현재는 지원됩니다). 다음과 같은 매개변수를 전달할 때 사용됩니다.

//:ke.qq.com/download/app.html
//:ke.qq.com/download/app.html?from=123
//:ke.qq.com/download/app.html?from=456

위의 세 가지는 세 페이지를 나타내지만 마지막 두 가지는 단지 출처를 보여주기 위한 것일 뿐이므로 이 세 가지가 같은 페이지인지 확인하기 위해머리추가하다정식상표.

<link rel="cononical" href="//:ke.qq.com/download/download/app.html" />

로봇

로봇.txt

검색 엔진 스파이더가 웹사이트를 방문하면 먼저 다음을 방문합니다.로봇.txt 파일인 robots.txt는 검색 엔진 스파이더에게 웹사이트의 특정 콘텐츠 크롤링을 금지하거나 해당 콘텐츠만 크롤링하도록 허용하는 데 사용되며, 사이트의 루트 디렉토리에 저장됩니다.

Tencent Classroom의 robots.txt를 예로 들어 보겠습니다.

사용자 에이전트는 다음 규칙이 어느 스파이더에 적용되는지 나타냅니다.*모두를 나타냅니다
#주석을 나타냅니다
Disallow는 파일이나 디렉터리의 크롤링이 금지됨을 나타냅니다. 각 줄은 별도로 작성해야 합니다.
Allow는 크롤링이 허용되는 파일이나 디렉터리를 나타냅니다. 각 줄은 별도로 작성해야 합니다.
사이트맵은 사이트 XML 맵을 의미하며 대문자 S에 주의하세요.

다음은 모든 검색 엔진 스파이더가 콘텐츠를 크롤링하는 것을 금지한다는 것을 의미합니다.

사용자-대리인: *
허용하지 않음: /

다음은 모든 검색 엔진 스파이더가 모든 콘텐츠를 크롤링할 수 있도록 허용합니다.

사용자-대리인: *
허용하지 않음:

참고: 로봇 크롤링이 금지된 URL도 색인 생성되어 검색 결과에 나타날 수 있습니다. 해당 URL을 가리키는 수신 링크가 있는 한, 검색 엔진은 해당 URL의 존재를 인식합니다. 페이지 콘텐츠는 크롤링되지 않지만, 색인 라이브러리에는 해당 URL에 대한 정보가 남아 있습니다. Taobao를 예로 들어 보겠습니다.

바이두 검색엔진 크롤링 금지

바이두 검색 결과

robots.txt 사용 방법 및 세부 정보
중국에서는 웹사이트 관리자들이 robots.txt에 그다지 신경 쓰지 않는 것 같습니다. 몇몇 친구의 요청에 따라 오늘 이 글을 통해 robots.txt 작성에 대해 간략하게 이야기해 보려고 합니다.

robots.txt에 대한 기본 소개

Robots.txt는 웹사이트 관리자가 로봇이 접근하지 않기를 원하는 웹사이트 부분을 선언하거나, 검색 엔진이 지정된 콘텐츠만 색인하도록 지정할 수 있는 일반 텍스트 파일입니다.

검색 로봇(검색 스파이더라고도 함)이 사이트를 방문하면 먼저 사이트 루트 디렉터리에 robots.txt 파일이 있는지 확인합니다. 파일이 있으면 검색 로봇은 파일 내용을 기반으로 접근 범위를 결정합니다. 파일이 없으면 링크를 따라 크롤링합니다.

또한, robots.txt는 사이트의 루트 디렉토리에 있어야 하며, 파일 이름은 모두 소문자여야 합니다.

Robots.txt 작성 구문

먼저 robots.txt의 예를 살펴보겠습니다. https://www.example.com/robots.txt

위의 구체적인 주소를 방문하면 robots.txt의 구체적인 내용을 다음과 같이 볼 수 있습니다.

# Robots.txt 파일 https://www.example.com
# 모든 로봇이 도메인을 스파이더링합니다.

사용자 에이전트: *
허용하지 않음:

위의 텍스트는 모든 검색 로봇이 https://uzbox.com 사이트의 모든 파일에 액세스할 수 있음을 의미합니다.

특정 구문 분석: # 뒤의 텍스트는 설명 정보입니다. User-agent: 뒤에는 검색 로봇 이름이 옵니다. 뒤에 *가 오면 모든 검색 로봇을 나타냅니다. Disallow: 뒤에는 접근이 허용되지 않은 파일 디렉터리가 옵니다.

아래에서 robots.txt의 구체적인 사용법을 나열해 보겠습니다.

모든 로봇이 액세스하도록 허용

사용자 에이전트: *
허용하지 않음:

또는 빈 파일 "/robots.txt" 파일을 생성할 수 있습니다.

모든 검색 엔진이 사이트의 어떤 부분에도 접근하지 못하도록 차단합니다.

사용자 에이전트: *
허용 안 함: /

모든 검색 엔진이 사이트의 여러 섹션(아래 예시의 디렉토리 01, 02, 03)에 액세스하는 것을 차단합니다.

사용자 에이전트: *
허용 안 함: /01/
허용 안 함: /02/
허용 안 함: /03/

검색 엔진(아래 예시의 BadBot)에 대한 액세스 차단

사용자 에이전트: BadBot
허용 안 함: /

특정 검색 엔진(아래 예시에서는 크롤러)에서만 액세스를 허용합니다.

사용자 에이전트: 크롤러
허용하지 않음:

사용자 에이전트: *
허용 안 함: /

또한, 이것을 확장하여 로봇 메타를 도입하는 것이 필요하다고 생각합니다.

로봇 메타 태그는 주로 특정 페이지에 사용됩니다. 다른 메타 태그(사용된 언어, 페이지 설명, 키워드 등)와 마찬가지로 로봇 메타 태그도 페이지의 <head> </head>에 배치되며, 특히 검색 엔진에 로봇이 페이지 콘텐츠를 크롤링하는 방식을 알려주는 데 사용됩니다.

로봇 META 태그를 작성하는 방법:

로봇 META 태그에는 대소문자 구분이 없습니다. name="Robots"는 모든 검색 엔진을 의미하며, 특정 검색 엔진의 경우 name="BaiduSpider"로 작성할 수 있습니다. 콘텐츠이 섹션에는 index, noindex, follow, nofollow라는 네 가지 명령 옵션이 있으며 명령은 ","로 구분됩니다.

INDEX 명령어는 검색 로봇에게 페이지를 크롤링하라고 지시합니다.

FOLLOW 명령어는 검색 로봇이 페이지의 링크를 따라 계속 크롤링할 수 있음을 나타냅니다.

로봇 메타 태그의 기본값은 INDEX와 FOLLOW입니다. 단, inktomi의 경우 기본값은 INDEX, NOFOLLOW입니다.

따라서 네 가지 조합이 있습니다.

〈메타 이름="로봇" 콘텐츠="인덱스,팔로우"〉
〈메타 이름="로봇" 콘텐츠="인덱스 없음,팔로우"〉
〈메타 이름="로봇" 콘텐츠="인덱스,노팔로우">
〈메타 이름="로봇" 콘텐츠="NOINDEX,NOFOLLOW">

~에

〈META NAME="ROBOTS" CONTENT="INDEX,FOLLOW"〉는 〈META NAME="ROBOTS" CONTENT="ALL"〉로 작성할 수 있습니다.

〈META NAME="ROBOTS" CONTENT="NOINDEX,NOFOLLOW"〉는 〈META NAME="ROBOTS" CONTENT="NONE"〉으로 작성할 수 있습니다.

현재 대부분의 검색 엔진 로봇은 robots.txt 규칙을 준수하는 것으로 보입니다. 로봇 메타 태그의 경우, 지원하는 로봇이 많지는 않지만 점차 늘어나고 있습니다. 예를 들어, 유명 검색 엔진인 구글은 이 태그를 완벽하게 지원하며, "보관소GOOGLE에서 웹 페이지 스냅샷을 보관할지 여부를 제한할 수 있습니다. 예:

〈메타 이름="googlebot" 콘텐츠="index,follow,noarchive"〉

즉, 사이트의 페이지를 크롤링하고 페이지의 링크를 따라가는 것을 의미하지만, GOOLGE에 페이지의 스냅샷을 보관하지 않는 것을 의미합니다.

robots.txt를 사용하는 방법

robots.txt 파일은 웹을 크롤링하는 검색 엔진 로봇(봇이라고 함)을 제한합니다. 이러한 봇은 자동화되어 있으며, 웹페이지를 방문하기 전에 특정 페이지 방문을 제한하는 robots.txt 파일이 있는지 확인합니다. 웹사이트의 특정 콘텐츠를 검색 엔진으로부터 보호하려면 robots.txt가 간단하고 효과적인 도구입니다. 사용 방법에 대한 간단한 가이드를 소개합니다.

Robots.txt 파일을 배치하는 방법

robots.txt 파일 자체는 텍스트 파일입니다. 도메인의 루트 디렉터리에 위치해야 하며 파일 이름은 "robots.txt"여야 합니다. 하위 디렉터리에 있는 robots.txt 파일은 작동하지 않습니다. 로봇은 도메인의 루트 디렉터리에서만 이 파일을 찾기 때문입니다. 예를 들어, http://www.example.com/robots.txt는 유효한 위치이지만 http://www.example.com/mysite/robots.txt는 유효하지 않습니다.

robots.txt의 예는 다음과 같습니다.

사용자 에이전트: *

허용 안 함: /cgi-bin/

허용 안 함: /tmp/

허용 안 함: /~name/
robots.txt 파일을 사용하여 전체 사이트를 차단하거나 제거하세요.

검색 엔진에서 사이트를 제거하고 앞으로 모든 로봇이 사이트를 크롤링하지 못하도록 하려면 다음 robots.txt 파일을 서버의 루트 디렉토리에 넣으세요.

사용자 에이전트: *

허용 안 함: /

Google에서 귀하의 사이트만 제거하고 앞으로 Googlebot만이 귀하의 사이트를 크롤링하지 못하도록 하려면 다음 robots.txt 파일을 서버의 루트 디렉터리에 넣으세요.
사용자 에이전트: Googlebot

허용 안 함: /

각 포트마다 별도의 robots.txt 파일이 있어야 합니다. 특히 http와 https를 통해 콘텐츠를 호스팅하는 경우, 각 프로토콜마다 별도의 robots.txt 파일이 필요합니다. 예를 들어, Googlebot이 모든 http 페이지는 색인하고 https 페이지는 색인하지 않도록 하려면 다음 robots.txt 파일을 사용합니다.
http 프로토콜의 경우 (http://www.example.com/robots.txt):

사용자 에이전트: *

허용하다: /

https 프로토콜의 경우 (https://www.example.com/robots.txt):

사용자 에이전트: *

허용 안 함: /

모든 로봇이 귀하의 페이지에 액세스하도록 허용
사용자 에이전트: *

허용하지 않음:

(다른 방법: 빈 "/robots.txt" 파일을 만들거나 robots.txt를 사용하지 마세요.)

robots.txt 파일을 사용하여 페이지 차단 또는 제거

robots.txt 파일을 사용하여 Googlebot이 사이트의 페이지를 크롤링하지 못하도록 차단할 수 있습니다. 예를 들어, Googlebot이 특정 디렉터리(예: 비공개 디렉터리)의 모든 페이지를 크롤링하지 못하도록 robots.txt 파일을 수동으로 생성하는 경우, 다음 robots.txt 항목을 사용할 수 있습니다.
사용자 에이전트: Googlebot

허용 안 함: /private
Googlebot이 특정 파일 형식(예: .gif)의 모든 파일을 크롤링하지 못하도록 하려면 다음 robots.txt 항목을 사용하세요.
사용자 에이전트: Googlebot

허용 안 함: /*.gif$
Googlebot이 ?가 포함된 모든 URL(특히 도메인 이름으로 시작하고 그 뒤에 아무 문자열이 오고, 그 뒤에 물음표가 오고, 다시 아무 문자열이 오는 URL)을 크롤링하지 못하게 하려면 다음 항목을 사용하세요.
사용자 에이전트: Googlebot

허용하지 않음: /*?

robots.txt로 차단된 페이지의 콘텐츠를 크롤링하거나 색인을 생성하지는 않지만, 웹의 다른 곳에서 해당 URL이 발견되면 크롤링하고 색인을 생성할 수 있습니다. 따라서 페이지 URL 및 사이트를 가리키는 링크의 앵커 텍스트와 같은 기타 공개 정보가 Google 검색 결과에 나타날 수 있습니다. 하지만 페이지의 콘텐츠는 크롤링, 색인 생성 또는 표시되지 않습니다.

Google은 웹마스터 도구의 일부로 robots.txt 분석 도구를 제공합니다. 이 도구는 Googlebot이 읽는 것과 동일한 방식으로 robots.txt 파일을 읽고 Google 사용자 에이전트(예: Googlebot)에 결과를 제공할 수 있습니다. 이 도구를 사용하는 것을 강력히 권장합니다. robots.txt 파일을 만들기 전에 사용자가 검색할 수 있는 콘텐츠와 검색해서는 안 되는 콘텐츠를 고려해야 합니다. 이렇게 robots.txt를 올바르게 사용하면 검색 엔진이 개인 정보가 포함되지 않도록 하면서 사용자를 웹사이트로 유도할 수 있습니다.

오해 1: 웹사이트의 모든 파일은 스파이더가 크롤링해야 하므로 robots.txt 파일을 추가할 필요가 없습니다. 파일이 없으면 모든 검색 스파이더가 기본적으로 비밀번호로 보호되지 않은 웹사이트의 모든 페이지에 접근할 수 있습니다.

사용자가 존재하지 않는 URL에 접근하려고 할 때마다 서버는 404 오류(파일을 찾을 수 없음)를 로깅합니다. 검색 스파이더가 존재하지 않는 robots.txt 파일을 찾으려고 할 때마다 서버는 404 오류를 로깅하므로, 웹사이트에 robots.txt 파일을 추가해야 합니다.
오해 2: 검색 스파이더가 robots.txt 파일에 있는 모든 파일을 크롤링하도록 설정하면 웹사이트의 포함률이 높아질 수 있습니다.
웹사이트의 프로그램 스크립트, 스타일 시트 및 기타 파일이 스파이더에 의해 포함되더라도 웹사이트의 포함률은 증가하지 않고 서버 리소스만 낭비할 뿐입니다. 따라서 검색 스파이더가 이러한 파일을 인덱싱하지 못하도록 robots.txt 파일에 설정해야 합니다.
제외해야 할 특정 파일은 "robots.txt 사용 팁" 문서에 자세히 소개되어 있습니다.
오해 3: 검색 스파이더는 웹페이지를 크롤링하는 데 너무 많은 서버 리소스를 낭비합니다. robots.txt 파일은 모든 검색 스파이더가 모든 웹페이지를 크롤링하지 못하도록 설정되어 있습니다.
이런 일이 발생하면 전체 웹사이트가 검색 엔진에 인덱싱되지 않습니다.
robots.txt 사용 팁

1. 사용자가 존재하지 않는 URL에 접근하려고 할 때마다 서버는 404 오류(파일을 찾을 수 없음)를 기록합니다. 검색 스파이더가 존재하지 않는 robots.txt 파일을 검색할 때마다 서버는 404 오류를 기록하므로 웹사이트에 robots.txt 파일을 추가해야 합니다.

2. 웹마스터는 서버 성능을 보장하기 위해 스파이더 프로그램을 서버의 특정 디렉터리에 두지 않아야 합니다. 예를 들어, 대부분의 웹 서버는 "cgi-bin" 디렉터리에 프로그램을 저장하므로 robots.txt 파일에 "Disallow: /cgi-bin"을 추가하여 스파이더가 모든 프로그램 파일을 인덱싱하는 것을 방지하고 서버 리소스를 절약하는 것이 좋습니다. 일반 웹사이트에서 스파이더가 크롤링할 필요가 없는 파일에는 백그라운드 관리 파일, 프로그램 스크립트, 첨부 파일, 데이터베이스 파일, 인코딩 파일, 스타일시트 파일, 템플릿 파일, 탐색 이미지, 배경 이미지 등이 있습니다.
VeryCMS의 robots.txt 파일은 다음과 같습니다.
사용자 에이전트: *
허용 안 함: /admin/ 백엔드 관리 파일
허용 안 함: /require/ 프로그램 파일
허용 안 함: /attachment/
허용 안 함: /images/ 이미지
허용 안 함: /data/ 데이터베이스 파일
허용 안 함: /template/ 템플릿 파일
허용 안 함: /css/ 스타일시트 파일
허용 안 함: /lang/ 인코딩된 파일
허용 안 함: /script/ 스크립트 파일
3. 웹사이트에 동적 페이지가 있고 검색 스파이더가 크롤링하기 쉽도록 이러한 동적 페이지의 정적 복사본을 만든 경우, robots.txt 파일에 이를 설정하여 스파이더가 동적 페이지를 인덱싱하는 것을 방지하고 이러한 페이지가 중복 콘텐츠를 포함하는 것으로 간주되지 않도록 해야 합니다.
4. robots.txt 파일에는 사이트맵 파일에 대한 링크를 직접 포함할 수도 있습니다. 다음과 같습니다.
사이트맵: sitemap.xml
이에 대한 지지를 표명한 검색 엔진 회사로는 Google이 있습니다. 야후, Ask 및 MSN. 중국 검색 엔진 회사들은 분명히 이러한 범주에 속하지 않습니다. 이 방법의 장점은 웹마스터가 각 검색 엔진의 웹마스터 도구나 유사한 웹마스터 섹션에 사이트맵 파일을 제출할 필요가 없다는 것입니다. 검색 엔진의 스파이더는 robots.txt 파일을 크롤링하고, 파일 내의 사이트맵 경로를 읽은 다음, 링크된 웹 페이지를 크롤링합니다.
5. robots.txt 파일을 적절히 사용하면 접속 시 발생하는 오류를 방지할 수 있습니다. 예를 들어, 검색자가 장바구니 페이지에 직접 접속하는 것을 허용하지 않도록 설정할 수 있습니다. 장바구니는 포함될 이유가 없으므로, robots.txt 파일에 설정하여 검색자가 장바구니 페이지에 직접 접속하는 것을 방지할 수 있습니다.

메타 로봇

URL이 검색 결과에 전혀 나타나지 않게 하려면 메타 로봇을 설정해야 합니다.

<meta name="robots" content="onindex,nofollow">

위 코드는 모든 검색 엔진이 이 페이지를 인덱싱하고 이 페이지의 링크를 추적하는 것을 금지한다는 것을 의미합니다.

물론 다른 유형의 콘텐츠도 있지만, 각 브라우저가 지원하는 유형이 다르므로 여기서는 무시합니다.

변경 빈도파일 업데이트 빈도를 나타내며, 값은 항상, 매시간, 매일, 매주, 매월, 매년, 절대 안 함입니다. "항상"은 페이지 콘텐츠가 항상 변경되며, 페이지를 방문할 때마다 콘텐츠가 달라짐을 의미하고, "절대 안 함"은 페이지 콘텐츠가 전혀 변경되지 않음을 의미합니다.

우선 사항URL의 상대적 중요도를 나타냅니다. 값 범위는 다음과 같습니다.0.0-1.0,1.0홈페이지에서 가장 일반적으로 사용되는 가장 중요한 것을 나타냅니다.0.0기본 중요도는 다음과 같습니다.0.5(여기서 중요도는 우리가 표시한 내용이며, 검색 엔진이 실제로 우리가 설정한 중요도에 따라 순위를 매긴다는 의미는 아닙니다.)

사이트맵.xml사이트맵 파일의 크기는 10M를 초과할 수 없으며, 각 사이트맵 파일에 포함된 URL 수는 50,000개를 초과할 수 없습니다. 사이트맵 파일이 매우 큰 경우 여러 파일로 분할할 수 있습니다. 아래 그림과 같이 기본 페이지용 파일과 제품 상세 정보 페이지용 파일, 총 두 개의 파일이 있습니다.

<사이트맵 인덱스 xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <사이트맵><위치>//ke.qq.com/sitemap-basic.xml2015-12-28T02:10Z
  <사이트맵><위치>//ke.qq.com/사이트맵-제품.xml2015-12-28T02:10Z
</사이트맵 인덱스>