Web c '＃！'を壊す （ハッシュバン）

以下は、私の意見では、Web 2.0の時代におけるかなり深刻な問題、つまりURLの純度に注意を向ける記事の翻訳です。

Lifehacker.comを例にとると、SEOを追いかけ、「プログレッシブエンハンスメント」の原則を否定し、最先端のテクノロジーを盲目的に追跡することにどのような問題が生じる可能性があるかが示されています。

先週月曜日、Lifehacker.comはJavaScriptが壊れていたため利用できませんでした。 Lifehacker.comは、他のGawkerサイトとともに、コンテンツ、広告、その他何もない空白のホームページを表示しました。 Googleの検索結果からメインページにリダイレクトされるサブページへの移行。

JavaScriptに依存するURL

Gawkerは、以前のTwitterと同様に、ページのURLを含むJavaScriptに完全に依存してサイトを再構築しました。 JavaScriptをロードできなかったため、コンテンツが不足し、URLが壊れています。

新しいページアドレスは、 http://lifehacker.com/#!5753509/hello-world-this-is-the-new-lifehacker ： http://lifehacker.com/#!5753509/hello-world-this-is-the-new-lifehacker / http://lifehacker.com/#!5753509/hello-world-this-is-the-new-lifehacker this- http://lifehacker.com/#!5753509/hello-world-this-is-the-new-lifehacker the-new- http://lifehacker.com/#!5753509/hello-world-this-is-the-new-lifehackerようになります。 月曜日まで、アドレスは同じでしたが、＃！..

フラグメントID

＃は、アドレスの次の部分がそのIDまたは現在のページの名前付きアンカーを持つHTML要素へのリンクであることをブラウザに伝える特別なURL文字です。 lifehacker.comの場合、現在のページがメインページです。

月曜日まで、サイトは100万ページで構成されていましたが、現在は1ページに100万のフラグメント識別子があります。

なんで？ 知りません Twitterは、Googleがそのようなツイートを索引付けできるのと同じテクノロジーに切り替えたときにこの質問に答えました。 これはそうですが、同じことが以前の正しいアドレス構造でより少ないコストで達成できました。

問題解決

アドレス構文c＃！ （ハッシュバン）は、GoogleがWeb開発者がロボットによるインデックス作成のためにサイトにアクセスできるようにする方法を発表したときに、最初にWeb開発の分野に入りました。

これ以前は、正しい決定についてはよく知られていなかったため、コンテンツを読み込むためのAjaxのような美しいテクノロジーを備えたサイトでは、JavaScript呼び出しの背後に隠されたコンテンツをボットが検出できないため、関連キーワードの低レベルのインデックス付けまたは評価が観察されました

Googleはこの問題を解決するために多くの時間を費やしましたが、これに成功せず、もう一方の端から行くことにしました 。 この架空のコンテンツを見つけようとする代わりに、サイトの所有者自身に報告させてください。 このために、 仕様が開発されました。

Googleは、開発者が「進歩的な改善」を備えたサイトを作成し、コンテンツの一部としてJavaScriptに依存しないという事実に注意を集中しているという事実に敬意を表さなければなりません。

最初から始める場合は、HTMLのみを使用してサイトの構造とナビゲーションを構築することをお勧めします。 次に、サイトのページ、リンク、およびコンテンツを適切に配置したら、外観とAjaxとのインターフェイスを強化できます。 GooglebotはHTMLを見て満足していますが、最新のブラウザを使用しているユーザーはAjaxボーナスを楽しむことができます。

つまり c＃アドレス構文！ Web開発の基本原則に基づいてデバイスを配置するサイト向けに特別に設計されており、そのようなWebサイトに命を吹き込み、コンテンツがボットによって検出されるようにしました。

そして今、このライフラインはFacebook、Twitter、そして今やLifehacker.comのエンジニアによって唯一の真のWeb開発パスとして受け入れられているようです。

ネットURL

Google仕様では＃！-アドレスは「prettyURL」と呼ばれ、ボットによってよりグロテスクなものに変換されます。

先週の日曜日、Lifehackerのアドレスは次のようになりました： http://lifehacker.com/5753509/hello-world-this-is-the-new-lifehacker : http://lifehacker.com/5753509/hello-world-this-is-the-new-lifehacker

いいね 真ん中の7桁のコードは理解できない唯一のフラグメントですが、記事を一意に識別するためにCMSで必要です。 したがって、実際には「クリーン」アドレスです。

今日、同じ記事はhttp://lifehacker.com/#!5753509/hello-world-this-is-the-new-lifehacker入手できますが、＃！の追加により、アドレスは以前のものよりも「クリーン」ではなくなりました。 住所の構造を根本的に変更します。

• 住所/ 5753509 / hello-world-this-is-the-new-lifehackerはシンプルになります/
• 新しいフラグメント識別子が追加されました！5753509 / hello-world-this-is-the-new-lifehackerがアドレスに追加されました。

何か達成できましたか？ いや しかし、住所のゆがみはこれで終わりではありません。

Googleの仕様では、アドレスはパラメーター付きのアドレスに再作成されます。 で： http://lifehacker.com/?_escaped_fragment_=5753509/hello-world-this-is-the-new-lifehacker : http://lifehacker.com/?_escaped_fragment_=5753509/hello-world-this-is-the-new-lifehacker / http://lifehacker.com/?_escaped_fragment_=5753509/hello-world-this-is-the-new-lifehacker

したがって、コンテンツを返すのはこのアドレスです。 このアドレスは正規です。つまり、 ボットがインデックスするもの。

同様： http://example.com/default.asp?page=about_us : http://example.com/default.asp?page=about_us

Lifehacker.comとGawkerは、単純な住所で10年の経験を積んだだけで、典型的なASPサイトに戻ってきました（Frontpageはさらに多くを獲得できますか？）。

問題は何ですか？

主な問題は、Lifehacker.comのアドレスがコンテンツを指していないことです。 各URLはホームページを指します。 幸運でJavaScriptを使ってうまくやっていれば、必要なコンテンツはメインページに依存します。

通常のアドレスよりも複雑で、エラーが発生しやすく、脆弱です。

コンテンツに関連付けられたアドレスを要求すると、要求のイニシエーターはコンテンツを受信しません。 つまり 破損は設計にあります。 Lifehacker.comは、ボットが興味深いコンテンツのリンクをたどることを意図的に禁止しています。 もちろん、Googleが発明したフープを飛び越えなければ。

では、なぜこのフープが必要なのでしょうか？

目的地＃！

では、なぜ＃！-アドレスが、コンテンツを直接配信する別のアドレスに再作成する必要がある合成アドレスである場合、アドレスを使用するのでしょうか？
すべての理由の中で、最も強いのは「とてもクールだから！」 私は最強ではなく最強だと言った。

エンジニアは、Ajaxアプリケーションの状態を保存することについてつぶやくでしょう。 そして、正直なところ、これはこの方法でアドレスを壊すばかげた理由です。 href属性内のアドレスは、コンテンツへの通常の形式のリンクのままにすることができます。 とにかくJavaScriptを使用しているので、クリックハンドラーでリンクをクリックして、＃！を適切な場所に追加することで、後で台無しにすることができます。状態維持があり、ボットや一般的に非JavaScriptからサイトを不必要に閉じることなく、 ov。

すべてのボットを拒否する（Googlebotを除く）

もちろん、HTTP / 1.1とURL仕様（RFC-2396など）の両方を完全にサポートするすべての非ブラウザエージェント（スパイダー、アグリゲーター、インデックススキャナー）は、Googlebotを除き、Lifehacker.comを経由できません。

したがって、次の結果を考慮する必要があります。

1. 中間サーバーにはコンテンツの正規表現がないため、キャッシュは機能しないため、キャッシュは機能しません。 これにより、Lifehackerがより長く開くことになり、Gawkerはトラフィックの増加により大きな損失を被ります。
2. HTTP / 1.1およびRFC-2396互換のクローラーには、空のホームページ以外は表示されません。 つまり このようなクローラー上に構築されたアプリケーションとサービスは、対応する効果をもたらします。
3. microformatsの潜在的な使用は大幅に削減されます。 ブラウザとGoogleアグリゲーターのみがマイクロフォーマットデータを表示できます。
4. ページIDを使用するFacebook Likeウィジェットは、ページがLike'nになるための追加のアクションを必要とします（デフォルトでは、メインページは直接URLで指し示されている唯一のものであり、＃のあるすべての「曲線」は再びメインページへのリンクとして理解されます）

JavaScriptの完全な依存関係

URLでコンテンツを取得できない場合、サイトは壊れています。 ゴーカーはリンクを壊すことで意識的にこのステップを踏んだ。 彼らは、あらゆる種類のJavaScriptエラーのせいで、サイトの可用性を残しました。

• JSのダウンロードに失敗すると、先週の月曜日（2011年2月7日）にすべてのGawkerサービスが5時間利用できなくなりました。
• リテラルとして宣言されたオブジェクトまたは配列の最後にセミコロン（;）がないと、Internet Explorerでエラーが発生します。
• ランダムに残されたconsole.log（）により、ユーザーは開発者ツールを使用せずにクラッシュします。
• 広告挿入は常に間違っていることが判明しました。 広告ユニットのエラー-サイトがありません。 そして、経験豊富なWeb開発者は、最も退屈なコードがバナー広告にあることを知っています。

本当の理由と利益のないこのような脆弱性は、すべての欠点を上回っていません。 Lifehackerが使用した方法よりも優れた方法があります。 HTML5とそのHistory APIでさえ、より良いソリューションです。

建築の悪夢

Gawker / Lifehackerは「漸進的な改善」の原則に違反し、発売日にスタイツを落としてすぐに支払いをしました。 JavaScriptのミスはすべて失敗につながり、Gawkerの収入と視聴者の信頼に直接影響します。

さらに読む

• http://www.tbray.org/ongoing/When/201x/2011/02/09/Hash-Blecch
• http://blog.benward.me/post/323​​1388630