GoogleがSERPの位置を決定するとき、W3標準は主要な要素ですか?


9

オンラインのw3バリデーターによると、インデックスに約800エラーしかない動的phpウェブサイトがあります。

ebay、stackoverflowなどの主要なWebサイトもチェックしてみましたが、すべて約400のエラーが発生しました。

だから私の最初の考えは、常にエラーを表示するときのバリデーターは何が良いのですか?

次に、エラーは私のSERPランキングに影響しますか?つまり、これらのエラーを修正して、Google検索の位置を上げることができますか?

ありがとう


2
stackoverflowはHTML 4.01 Strictに有効です!
haha

Google SEOスターターガイドをご覧ください。その中のアドバイスに従うだけで大丈夫です。また、SOには400個のエラーがあるといってみてください。:)
サイムVIDAS

インバウンドリンクは、ランクを決定する唯一の主要な要素です。
danlefree

私は同意しません。ドメイン名とページタイトルは、それ自体が非常に大きな重みを持っているようです。
John Conde

回答:


11

検証は私の結果を後押ししますか?

番号。

それが常にエラーを表示するとき、そのバリデーターは何が良いですか?

常にエラーが表示されるわけではありません。エラーがある場所にエラーを表示します。それはあなたの質問がどうあるべきかにつながる、つまり:

ひどい、無効なHTMLを書くことは害になりますか?

はい。ブラウザーには多くの非互換性があるため、害を及ぼします。フロントエンドのために私を雇ったことのある誰もあなたを雇わないでしょうから。DOM関連の処理が中断する可能性があるためです。あなたのアクセシビリティは人間の人口の2%を吸い込み、遮断するからです; なぜなら、ランキング自体は有効性の欠如による障害にはなっていませんが、意味のある整然としたコードによって確実に助けられているからです。

まだ終わっていません:それはあなたにとって悪いだけでなく、私たち全員にとって悪いことであり、私たちはあなたのせいにするべきです。あなたが毎日使う素敵なWebサービスは標準に依存しているし、それらの開発が遅くて潜在能力に到達できない場合は、ずさんなマークアップが原因です。

毎日目を覚ましてWebが完全にアーキテクチャ化された意味論的関係のネットワークではないことに気付いたとき、あなたはすべての謝罪を私たちに与えるでしょう。

また、幸せな休日。


すごい、選ばれた?@Camran、批判を受け入れることができます。また、@ people-who-voted-this-down:引数?

1

だから私の最初の考えは、常にエラーを表示するときのバリデーターは何が良いのですか?

すばらしい質問です。バリデーターは、マークアップ構文をW3C仕様(最近のHTMLまたはXHTMLのいずれか)と照合してチェックします。技術的に無効なマークアップがあることを通知するという意味で、完璧です(または、チェックで大きなエラーは検出されていませんが、ほぼ完璧です)。

それにもかかわらず、実際の無効なマークアップはゲームオーバーではありません。W3C標準を英語の特定の方言の非常に厳密な仕様と考えてください。仕様を念頭に置いてブラウザを開発する場合、その方言で学校に通い、この英語の方言を話し、読み、聞き、理解する適切な方法を身に付けていると考えてください。実際には、このブラウザは遊び場に出かけて世界中を旅し、標準的な規則のわずかな変更を理解することを学びます。ブラウザは古い映画も視聴するので、学校で厳密に教えられていなかったとしても(仕様では)、「古い」構文と語彙を理解する方法を学習します。一部のブラウザー(特にIE <9)には、通常のカリキュラムをより良いブラウザーに変更できると感じている親(開発者)がいました。彼らはまったく別の私立学校に送られました。結局のところ、さまざまなブラウザーがさまざまな言語を理解できます。それらのそれぞれにも非常に寛大な「ファッジ」要因があります。誰かが発言をスラーリングしたり、タイプミスを含めたりしたときの意味を知っているように、ブラウザーも同じことをします。さらに多くの場合、人々やコミュニティは、学校で(仕様に基づいて)正式に訓練されていなくても、ブラウザがたまたま理解できる革新的な発話方法(マークアップを書く)を考案します。その時点で、実際に機能する標準に準拠していないコードが数多く得られます。誰かが発言をスラーリングしたり、タイプミスを含めたりしたときの意味を知っているように、ブラウザーも同じことをします。さらに多くの場合、人々やコミュニティは、学校で(仕様に基づいて)正式にトレーニングされていなくても、ブラウザがたまたま理解できる革新的な発話方法(マークアップを書く)を考案します。その時点で、実際に機能する標準に準拠していないコードが数多く得られます。誰かが発言をスラーリングしたり、タイプミスを含めたりしたときの意味を知っているように、ブラウザーも同じことをします。さらに多くの場合、人々やコミュニティは、学校で(仕様に基づいて)正式に訓練されていなくても、ブラウザがたまたま理解できる革新的な発話方法(マークアップを書く)を考案します。その時点で、実際に機能する標準に準拠していないコードが数多く得られます。

次に、エラーは私のSERPランキングに影響しますか?つまり、これらのエラーを修正して、Google検索の位置を上げることができますか?

Google マークアップに準拠していることを推奨していますが、実験者がマークアップを厳しく改ざんしてコンテンツが適切に表示されない場合を除いて、何らかの形での決定的な証拠はほとんどありません。これはおそらく、Google独自のクローラーが標準仕様だけでなく、カジュアルなものから古いものまで、すべての方言に精通しているためです。また、小さな「間違い」を補うためのファッジ補正メカニズムもたくさんありました。

結局のところ、可能であれば、有効なマークアップを使用できるように頑張ってください。あなたがそれを優先させれば、そうすることは完全に可能です。私の経験では、あなたがルールを破るのに十分に進んでいるとき(私はそうではないことを知っています)、あなたはルールと解析について十分に知っており、元の質問はまったく質問ではないという意味合いを示しています。


HTML4には別の方言はありません。HTMLとXHTMLには異なるバージョンがありますが、人々が無効なマークアップを使用するのは、それが無効であることを知らないか、特定のブラウザーが有効なマークアップを許可しなかったためです(それらはより文化的であるためではなく、開発者がねじ込まれたためです)アップ)。プログラミング言語は人間の言語と同じではありません。文法と構文のルールは主観的ではありません。Webが正しく機能するためには、開発者はブラウザーによって実装されたルールに従う必要があります。また、ブラウザはW3Cによって設定された仕様に従う必要があります。
Lèseはmajesté

1

SERPランキングには影響しません。Googleウェブマスターセントラルの公式YouTubeチャンネルから:

そのため、妥当性が確認された場合、ページに何らかのブーストを与えることはありません。あなた自身の内部の目的のために行うのは良いことかもしれませんが、それはあなたの階級やそのようなものでどんなGoogleブーストも受けません。そして単純な理由は、現在のようにWeb上のページの大部分が検証されないことです。

http://www.youtube.com/watch?v=FPBACTS-tyg

ただし、コードのエラーが発生しにくくなり、保守が容易になるため、ページを検証することをお勧めします。


0

ほとんどのSEOは、適切にネストされていないコードや大きなエラーがあるコードがあることはSEOにとって悪いことであることに同意しているようです。彼らは皆、あなたが本当に有効なHTMLを持っているときは、より良いランキングを得ることにはならないことにも同意します。

したがって、私の最終的な結論は次のとおりです。WebデザインとSEOの両方の理由から、レンダリングまたはパーサーの問題を引き起こす可能性があるすべての露骨なエラーを修正する必要があります。ただし、許可されていない属性や、の代わりにタグを使用する1つのプラグインについては心配しないでください。それはあなたの時間やお金の価値がないだけです。

- W3C検証:あなたが気に、そしてなぜべきではない理由でyoast.com


これは実用主義です!

-1

それはまったく要因ではありません。HTMLは非常に柔軟な言語です。このようなことをしても問題はありません。

< ul >
 < li >< a xtooltip='Go to homepage' href='index.php' >Home< /a >< /li >
< /ul >

次に、お気に入りのJavaScriptエンジンを使用して、ツールチップ付きのメニューを用意します。もちろんそれは検証されません。

もう1つは、W3Cバリデーターが残念ながら壊れていることです。いくつか例を挙げると、コンテンツタイプ、jsコード、jsコードhtml出力、ajaxなどを検証できません。content-typeをチェックしないことに加えて、重大な欠陥があります。XHTML DOCTYPEがあるがcontent-type:text / html HTMLに対して検証する必要がある場合、ほとんどの人は(誤って)XHTMLに対して検証し、「エラー」を修正します...

[br] => [br /]

しかし、[br /]はHTMLのエラーです...そのため、バリデーターが誤って伝えていることを実行し、コードにバグを追加するだけです。


W3Cバリデーターの目的は、JavaScriptを検証することではありません。それはそれが「壊れた」というわけではありません。

document.write( "<divこれは私のdivコンテンツです</ div>"); 私が言おうとしていることはすべて、結果が何で何がそうでないかを正確に知る前に、あまり頼りにしてはいけません。例えば。仕様に基づくユーザー定義属性は、実際にはエラーではありません。たぶん壊れているのは正しい言葉ではないかもしれませんが、私はあなたが私が何を意味するのか知っていると思います...それは通常、「エラー」があるとして完全に正しいコードにフラグを立て、たとえば取得に失敗します。content-typeおよびJS HTMLで生成されたバグ。

はい、本当です:-)その場合、ページの事前JSレンダリングではなく、ページの最終出力(ビュー生成ソースなど)を検証するのが賢明です。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.