web-dev-qa-db-ja.com

Webページ内の複数の<!DOCTYPE html>

バックエンドのテンプレート言語でテンプレート用のテンプレートとサブアイテムに分かれているサイトがあります。

ただし、メインテンプレートに埋め込まれているサブテンプレートはそれぞれwith<!DOCTYPE html>で始まります。したがって、テンプレートをフロントエンドとしてレンダリングすると、複数の<!DOCTYPE html>があります。

SEOがページの中央の1つのページと上部に1つのページに複数の<!DOCTYPE html>を配置するのは悪いことですか?

それらを削除する必要がありますか?

1
Kotlinboy

複数の要素<!DOCTYPE html>を適用すると、HTML5バリデーターでエラーがスローされます。 Webページのエラーは、これらのWebページの検索エンジン最適化に直接または間接的に影響します。あなたの場合。

解析は、レンダリングエンジン内の非常に重要なプロセスです。ドキュメントの解析とは、コードが使用できる構造にドキュメントを変換することを意味します。解析の結果は通常、ドキュメントの構造を表すノードのツリーです。これは、解析ツリーまたは構文ツリーと呼ばれます。構文解析は、ドキュメントが準拠している構文規則(言語または形式)に基づいています。構文解析できるすべての形式は、語彙と構文規則で構成される決定論的な文法を持っている必要があります。

構文解析は、字句解析と構文解析の2つのサブプロセスに分けることができます。

字句解析は、入力をトークンに分割するプロセスです。トークンは言語の語彙であり、有効な構成要素の集合です。人間の言語では、その言語の辞書に表示されるすべての単語で構成されます。

構文分析は、言語の構文規則を適用することです。

パーサーは通常、作業を2つのコンポーネントに分割します。入力を有効なトークンに分割する役割を担うレクサー(トークナイザーと呼ばれることもあります)と、言語構文規則に従って文書構造を分析して解析ツリーを構築する役割を担うパーサーです。

解析プロセスは反復的です。パーサーは通常、レクサーに新しいトークンを要求し、トークンを構文ルールの1つと一致させようとします。ルールが一致した場合、トークンに対応するノードが解析ツリーに追加され、パーサーは別のトークンを要求します。

一致するルールがない場合、パーサーはトークンを内部に保存し、内部に保存されているすべてのトークンに一致するルールが見つかるまでトークンを要求し続けます。ルールが見つからない場合、パーサーは例外を発生させます。これは、ドキュメントが無効で、構文エラーが含まれていたことを意味します。

出典:ブラウザの仕組み:HTML5 Rockの最新のWebブラウザの舞台裏

Webページを開いたときにブラウザがどの程度の作業を行うかを確認できます。この解析には、ブラウザに時間がかかります。次に、開いているWebページのソースコードにエラーがあることを想像してください。したがって、ブラウザの解析時間は増加します。したがって、ウェブページのダウンロード速度は低下しますが、これはGoogleの検索ランキングのシグナルです-- デスクトップおよびモバイルしたがって、HTMLの標準(ソースコードエラー-これは受け入れられた標準の違反です) Webページの検索ランクの低下、つまり、ネガティブSEO。

この問題の可能な解決策は、タグコードの使用です。

0
nikant25

SEOには何の違いもありませんが、技術的に無効なマークアップであるため、私の主な関心事はブラウザーのレンダリングです。

ただし、ほとんどのブラウザは単にそれを無視すると思われます。

2
DocRoot

仕様では、<html>または<head>要素の前に、ドキュメントの最初のものにする必要があるとされています。

https://html.com/tags/doctype/

ページのさらに下にある場合はおそらく無視されますが、ブラウザの実装に依存します。

0
Rob Sedgwick