SEO最適化スキルは、ウェブサイト構築初心者にとって必須です

SEO最適化

SEO最適化 Google SEOどうやってやるの？百度でSEOどれくらいの違いがあるのでしょうか？本質的にはそれほど大きな違いはありませんが、細かい部分では若干の違いがあります。Google SEO数日前、国内大手の電子商取引 SEO 部門の友人が私に非常に興味深い質問をしました。グーグルランキングの問題は 1 つか 2 つの文だけでは説明できないため、他の SEO 担当者の役に立つかもしれない回答を投稿しました。

TDKの最適化

TDKタイトル,説明,キーワード3つを総称する用語です。もちろんタイトル最も有用であり、最適化する価値が非常に高いです。キーワードこれは過去に SEO 担当者によって過剰に使用されていたため、今これを最適化しても検索エンジンには役に立たないので、ここでは詳しく説明しません。説明説明文は検索導入部に直接表示されるため、ユーザーがクリックするかどうかの判断に非常に効果的です。

タイトルの最適化

タイトルセパレータは通常,,_,-など、その中には_それは百度にとってより友好的である、-Googleにとってより使いやすいです。4文字目はスペースです。英語のサイトでは使用できますが、中国語のサイトではほとんど使用されません。タイトル文字数は、PCでは約30文字、モバイルでは約20文字です。この長さを超える場合は、省略記号で切り捨てられます。

ビジネス関係上、当社は Baidu の検索エンジン最適化に重点を置いています。Baidu の検索エンジン最適化に関する提案をいくつかご紹介します。

タイトル形式：

表紙:ウェブサイト名 または ウェブサイト名_サービス紹介または商品紹介を掲載
チャンネルページ:チャンネル名_ウェブサイト名
記事ページ:記事タイトル_チャンネル名_ウェブサイト名

記事のタイトルがあまり長くない場合は、キーワード入って、記事タイトル_キーワード_ウェブサイト名

推奨される方法:

各ウェブページには固有のタイトルが必要です。すべてのページで同じデフォルトのタイトルを使用することは避けてください。
タイトルは明確で、この Web ページの最も重要なコンテンツを含んでいる必要があります。
簡潔に記述し、Web ページの内容に関係のない情報は記載しないでください。
ユーザーは通常、左から右に閲覧するため、重要なコンテンツはタイトルの先頭に配置する必要があります。
ユーザーが使い慣れている言語を使用してください。中国語と英語の両方のウェブサイト名がある場合は、タイトルの説明にはユーザーが使い慣れている言語を使用するようにしてください。

説明の最適化

説明重み付けの計算基準ではありません。このタグの有無はウェブページの重み付けに影響を与えません。検索結果の要約の選択対象としてのみ使用されます。長さはPC側で約78文字、モバイル側で約50文字です。これを超える場合は省略記号に切り捨てられます。

Baidu の推奨事項:

説明は、要約として使用できる長い段落のテキストがない、Web サイトのホームページ、チャンネルページ、製品パラメータページなどに最適です。
ページを正確に説明し、キーワードを詰め込みすぎない
すべてのページで同じ説明を使用することを避けるために、ページごとに異なる説明を作成します。
長すぎず短すぎず、適度な長さ

以下に、Baiduが比較のために推奨する2つの例を示します。1つ目はメタディスクリプションを適用しておらず、2つ目は適用しています。1つ目の検索結果の概要はユーザーにとってほとんど参考にならないのに対し、2つ目の検索結果の概要はより読みやすく、ユーザーがウェブサイトのコンテンツをより深く理解できることがわかります。

ページコンテンツの最適化

HTML5構造の使用

条件が許せば（携帯端末など、IE9+と互換性がある場合、IE8+の場合はIE8に導入）html5.jsHTML5 セマンティックタグの使用を検討する時期が来ました。ヘッダ,フッター,セクション,脇に,ナビ,記事ちょっと待ってください、ここで全体のレイアウトを確認するためにスクリーンショットを撮ります

ユニークな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」 相対=「ノーフォロー」>フォローリンクなし</1つの>

文章

コンテンツの考慮事項:

自然文学
高品質なオリジナルコンテンツ
読者を惹きつけるライティングテクニック
セールスポイントを強調する
信頼を高める
さらなる行動につながる

ユーザーエクスペリエンスの考慮事項:

レイアウトは合理的で、明確で、美しく、フォントと背景は読みやすいです。
実際のコンテンツはページの最も重要な位置にあり、ユーザーは一目でそれを見ることができる
実質的なコンテンツと広告を明確に区別できる
最初の画面には、スクロールダウンして見る必要もなく、充実したコンテンツが表示されている
広告の数は多すぎず、広告の配置がユーザーの閲覧を妨げないようにする必要があります。
画像や動画によってユーザーがページの内容を理解するのに役立つ場合は、画像や動画などを作成してみてください。
ポップアップを多用しない

URLの最適化

URL 設計の原則:

短ければ短いほど良い
パラメータが多すぎるのは避ける
ディレクトリレベルをできるだけ小さく保つ
説明的なファイル名とディレクトリ名を使用する
URLにキーワードを含める（中国語を除く）
すべて小文字
ハイフンの使用-それよりも_
ファイル形式ではなくディレクトリ形式

静的URL

現在の検索エンジンのクロール機能では、URL を静的にする必要はありませんが、組み込みやすさ、ユーザーエクスペリエンス、ソーシャル共有の観点から、静的で短い URL の方が有利です。

URL は静的ですか?

データベース駆動型のウェブサイトでは、URLを静的に保つ必要があります。これはSEOの最も基本的な要件であり、もはや常識と言えるでしょう。残念ながら、今ではデータベース駆動型ではないウェブサイトは存在しないでしょう。

近年、SEO業界では、URLに2～3個の疑問符があっても問題ないという意見が一致しています。検索エンジンは通常、特に権威の高いドメインであればインデックスできるためです。また、疑問符の数が増えても問題はありません。しかし、一般的にはURLを静的にすることが推奨されています。

2008年9月、Googleウェブマスターブログは動的URLと静的URLについて議論する投稿を公開し、この見解を覆しました。この投稿でGoogleは、動的URLを静的URLにするのではなく、疑問符パラメータを含む長い動的URLを維持することを明確に推奨しました。Google Blackboardと中国語ウェブマスターブログがこれを翻訳して再投稿しているので、ぜひご覧ください。

私が読んだコメントやブログから判断すると、実際にそれが理にかなっていると考え、Google の言うことを実行する用意がある人がかなりいるようです。

これは Google からの比較的珍しい SEO 提案であり、私はこれに強く反対します。

Google の投稿には重要なポイントがいくつかあります。

まず、Googleは動的なURLを完全にクロールすることができ、疑問符がいくつあっても問題ありません。これは基本的に信頼できるものです。しかし、URLに疑問符やパラメータが10個、20個以上含まれていたらどうなるでしょうか？Googleはどのように認識するのでしょうか？たとえクロールが可能だったとしても、クロールしてくれるでしょうか？他の検索エンジンはどのように対処するのでしょうか？

第二に、動的URLは、URL内のパラメータが示唆的なため、GoogleスパイダーがURLの意味を理解して識別するのに便利です。例えば、Googleは次の例を挙げています。

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 がどれが製品のシリアル番号でどれがサイズかを判断できなくなる可能性があります。

3つ目に、URLを静的にするとミスが発生しやすく、それが逆効果になることがあります。例えば、動的URLのパラメータの順序を変えても、表示されるページは実際には同じです。例えば、以下の2つの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を作成した後は、Googleが2つの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 を静的にしないことを推奨しています。

しかし、私は依然として静的化を推奨します。その理由は次のとおりです。

まず、GoogleのアドバイスはGoogle自身のものであり、他の検索エンジンの状況を考慮に入れていません。Googleが動的URLのクロールに問題がないからといって、Yahoo、Baidu、Microsoftなどが動的URLのクロールに問題がないわけではありません。特に中国のウェブサイトに関しては、Googleが全てを掌握しているわけではありません。実際、Baiduは2021年現在も、複数の疑問符が付いたURLのクロールに消極的です。

第二に、Googleが指摘する静的化のデメリットは、静的化が不適切に行われるという前提に基づいています。問題は、静的化を行うのであれば、正しく行う必要があるということです。不適切に行われると想定するのは無意味です。URLを静的化する際に、セッションIDを入力する人はどれくらいいるでしょうか？

3つ目に、Googleの提案は通常、Google自身にとって有利ですが、ユーザーにとって有利ではありません。疑問符パラメータを含むURLは、Googleがコンテンツを理解するのに役立つかもしれませんが、ユーザーがウェブサイトの構造や全体的なコンテンツを一目で理解するのは明らかに非常に困難です。次の2つの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

明らかに2番目です。

さらに、長い動的 URL は記憶に残りにくく、電子メールやソーシャルネットワーキングサイトなどで他の人にコピーするのにも不便です。

つまり、Google は動的 URL を維持することを明確に推奨していますが、私はその逆を行って、URL を可能な限り静的にすることをお勧めします。

URLの正規化

1. 統合された接続

http://www.ドメイン名.com
http://ドメイン名.com
http://www.ドメイン名.com/索引.html
http://ドメイン名.com/索引.html

上記の4つは実際にはホームページです。訪問者には何の問題もありませんが、検索エンジンにとっては同じ内容のURLが4つ並んでいるだけなので、不正行為と誤解される可能性があります。検索エンジンがURLを標準化する際には、これらの選択肢の中から最適なものを選ぶ必要がありますが、必ずしもあなたが望むものとは限りません。そのため、自分で標準化するのが最善です。

2. 301リダイレクト

1つ目は、URLが変更された場合です。古いアドレスを新しいアドレスに301リダイレクトする必要があります。そうしないと、以前の包含重み付けがすべて無駄になります。

2つ目はcmsシステムでは、複数のパスが同じ記事に対応する可能性が高くなります。ドルパルデフォルトのパスはノード/NIDただし、パストークンが有効になっている場合は、パスを自分でカスタマイズできます。これにより、同じ記事に対応するパスが2つ存在することになります。そこで、301トークンを有効にして、最終的に1つのパスにリダイレクトすることができます。

3. 正典

このタグはページの一意性を示します（以前はBaiduではサポートされていませんでしたが、現在はサポートされています）。以下のパラメータを渡す際に使用されます。

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

上記の3つは3つのページを表していますが、最後の2つは単に元のページを示すためだけのものなので、これら3つが同じページであることを確認するために、頭追加正統なラベル。

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

ロボット

robots.txt

検索エンジンのスパイダーがウェブサイトを訪問すると、まずロボット.txt ファイルである robots.txt は、検索エンジンスパイダーに、Web サイトの特定のコンテンツのクロール禁止、または特定のコンテンツのクロールのみ許可するように指示するために使用され、サイトのルートディレクトリに配置されます。

Tencent Classroom の robots.txt を例に挙げます。

ユーザーエージェントは、以下のルールがどのスパイダーに適用されるかを示します。*すべてを示す
#コメントを示す
Disallow は、ファイルまたはディレクトリのクロールを禁止することを示します。各行は個別に記述する必要があります。
Allow は、クロールを許可するファイルまたはディレクトリを示します。各行は個別に記述する必要があります。
サイトマップはサイトのXMLマップを意味します。大文字のSに注意してください。

以下は、すべての検索エンジンスパイダーがコンテンツをクロールすることを禁止することを意味します。

ユーザー-エージェント: *
許可しない: /

以下は、すべての検索エンジンスパイダーが任意のコンテンツをクロールすることを許可する

ユーザー-エージェント: *
許可しない:

注：ロボットによるクロールが禁止されているURLでも、インデックスに登録され、検索結果に表示される場合があります。このURLへの被リンクが存在する限り、検索エンジンはこのURLの存在を認識します。ページコンテンツはクロールされませんが、インデックスライブラリにはこのURLに関する情報が保持されます。Taobaoを例に挙げましょう。

Baidu検索エンジンのクロールを禁止する

百度検索で表示される

robots.txtの使い方とその詳細
中国では、ウェブサイト管理者はrobots.txtをあまり重視していないようです。友人からの要望もあり、本日はこの記事でrobots.txtの書き方について簡単に説明したいと思います。

robots.txt の基本的な紹介

Robots.txt はプレーンテキストファイルであり、Web サイト管理者は、ロボットによるアクセスを禁止する Web サイトの一部を宣言したり、検索エンジンが特定のコンテンツのみをインデックスするように指定したりできます。

検索ロボット（検索スパイダーと呼ばれることもあります）がサイトを訪問する際、まずサイトのルートディレクトリに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
許可しない: /

特定の検索エンジン（以下の例ではクローラー）からのアクセスのみを許可する

ユーザーエージェント: クローラー
許可しない:

ユーザーエージェント: *
許可しない: /

さらに、これを拡張してロボットメタを導入する必要があると考えています。

Robots METAタグは主に特定のページを対象としています。他のMETAタグ（使用言語、ページの説明、キーワードなど）と同様に、Robots METAタグもページの<head> </head>に配置され、検索エンジンにROBOTSがページコンテンツをどのようにクロールするかを伝えるために使用されます。

Robots METAタグの書き方:

Robots META タグでは大文字と小文字の区別はありません。name="Robots" はすべての検索エンジンを意味し、特定の検索エンジンの場合は name="BaiduSpider" と記述できます。コンテンツこのセクションには、index、noindex、follow、nofollow の 4 つのコマンドオプションがあり、コマンドは「,」で区切られます。

INDEX ディレクティブは、検索ロボットにページをクロールするよう指示します。

FOLLOW 命令は、検索ロボットがページ上のリンクに沿ってクロールを続行できることを示します。

Robots Meta タグのデフォルト値は INDEX と FOLLOW です。ただし、inktomi の場合、デフォルト値は INDEX、NOFOLLOW です。

したがって、組み合わせは次の 4 つになります。

＜META NAME="ROBOTS" CONTENT="INDEX,FOLLOW"＞
＜META NAME="ROBOTS" CONTENT="NOINDEX,FOLLOW"＞
＜META NAME="ROBOTS" CONTENT="INDEX,NOFOLLOW">
＜META NAME="ROBOTS" CONTENT="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のルールに準拠しているようです。Robots METAタグについては、対応しているものは多くありませんが、徐々に増えてきています。例えば、有名な検索エンジンであるGoogleはこれを完全にサポートしており、Googleは「アーカイブ」を使用すると、GOOGLEがウェブページのスナップショットを保持するかどうかを制限できます。例:

＜META NAME="googlebot" CONTENT="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 によるサイト上のページのクロールをブロックできます。例えば、特定のディレクトリ（例：private）内のすべてのページを 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 ファイル内のすべてのファイルを検索スパイダーでクロールするように設定すると、Web サイトの包含率が向上する可能性があります。
ウェブサイト内のプログラムスクリプト、スタイルシート、その他のファイルがスパイダーによってインクルードされたとしても、ウェブサイトのインクルード率は上がらず、サーバーリソースを浪費するだけです。そのため、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/ プログラムファイル
許可しない: /添付ファイル/
禁止: /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">

上記のコードは、すべての検索エンジンがこのページをインデックスし、このページ上のリンクを追跡することを禁止することを意味します。

もちろん他の種類のコンテンツもありますが、ブラウザごとにサポートされる種類が異なるため、ここでは無視されます。

サイトマップ

サイトマップには HTML と XML の 2 つの形式があります。

HTMLバージョンは通常のHTMLページですサイトマップ.htmlユーザーはサイト内のすべての主要リンクに直接アクセスして一覧表示できます。一覧表示するリンクは100件以下にすることをお勧めします。

XML版のサイトマップは2005年にGoogleによって提案され、次のようにエンコードされたXMLタグで構成されています。UTF-8は、ページのすべてのURLをリストします。形式は次のとおりです。

<?xmlバージョン="1.0" エンコーディング=「UTF-8」?>
<urlset xmlns=「http://www.sitemaps.org/schemas/sitemap/0.9」>
  <URL>
  <場所>//ke.qq.com
  <ラストモッド>2015-12-28</ラストモッド>
  <変化頻度>いつも</変化頻度>
  <優先度>1.0</優先度>
  </URL>
  ...
</URLセット>

でURLセット,URL,場所3 つは必須タグです。ラストモッド,変化頻度,優先度オプションのタグです。

ラストモッドページが最後に更新された時刻を示します。

変化頻度ファイルの更新頻度を、以下の値で示します：always、hourly、daily、weekly、monthly、yearly、never。always はページの内容が常に変化し、ページにアクセスするたびに内容が異なることを意味します。never はページの内容が全く変化しないことを意味します。

優先度URLの相対的な重要度を示します。値の範囲は0.0-1.0、1.0最も重要なものを示し、一般的にウェブサイトのホームページで使用され、0.0最も重要度が低い、デフォルトの重要度は0.5（ここでの重要度は私たちがマークしたものであり、検索エンジンが実際に私たちが設定した重要度に従ってランク付けすることを意味するものではないことに注意してください）

サイトマップ.xmlサイトマップファイルのサイズは10MB以下、また各サイトマップファイルに含まれるURLの数は50,000以下にしてください。サイトマップファイルのサイズが大きい場合は、複数のファイルに分割することができます。下図のように、基本ページ用と商品詳細ページ用の2つのファイルがあります。

<サイトマップインデックス xmlns=「http://www.sitemaps.org/schemas/sitemap/0.9」>
  <サイトマップ><場所>//ke.qq.com/サイトマップ-basic.xml2015年12月28日02:10Z
  <サイトマップ><場所>//ke.qq.com/サイトマップ-製品.xml2015年12月28日02:10Z
</サイトマップインデックス>