8

rel=canonical タグを生成したい C# で記述された MVC3 アプリがあります。これを自動的に達成する方法を探しているときに、この投稿に出くわしました。

開発環境に実装したところ、意図したとおりに機能し、次のようなタグが生成されます

<link href="http://localhost/" rel="canonical" />.

私の質問は、これが何の役に立つのかということです。カノニカル URL は、たまたま URL が何であれではなく、明示的に指定したい場所 (つまり、本番サイト) を指すべきではないでしょうか?

私がこれを持ち出す理由は、私のホスティング プロバイダー (今のところ無名のままです) が、私のサイトを指す別の URL も生成するためです (同じ IP アドレスは別のホスト名です。理由はわかりません。逆引き DNS の目的であると彼らは主張しています)。 -- これは別の問題です)。しかし、私のページがこのミラーリングされた URL の下の Google 検索結果に表示されるようになりました。「重複コンテンツ」であるため、SEO には適していません。現在、サイトのドメインへの要求のみに応答するように IIS サイトを構成するだけで問題を解決しましたが、正規 URL がここでどのようなソリューションを提供できたかを調べる良い機会に思えました。

上記の投稿の解決策を使用すると、誰かがミラーリングされたサイトにアクセスした場合、rel=canonical リンク タグはミラーリングされた URL を含む正規の URL を出力しますが、これは私が望むものではありません。アドレスバーの URL に関係なく、常に である必要が<link rel="canonical" href="http://www.productionsite.com" />あります。つまり、それが正規の URL のポイントではないでしょうか、それとも何か不足しているのでしょうか?

私が正しいと仮定すると、MVC3 アプリの正規 URL を生成するための受け入れられた一般的な方法はありますか? もちろん、ページごとに個別に定義することもrawUrl.Host、ハードコードされたドメイン名にリンクしたソリューションのパラメーターを単純に置き換えることもできます。目的に合わないようです（少なくとも私の例では）。現在の URL を rel=canonical リンク要素に挿入するだけで、彼らはどのような問題を解決しようとしているのでしょうか?

4

3 に答える 3

4

素晴らしい質問です。ミラーリングされたサイトがまだ正規としてマークされていることについて、あなたは大騒ぎしています。実際、「リンク ジュース」がこれ以上大きくなる前に、いくつかの問題を修正する必要があります。

主な理由は、MVC が設計上、URL 書き換え/ルーティング システムであるためだと思われます。そのため、最初に要求された URL に発生するメッセージに応じて、人々は正規リンクを「解決済み」の最終 URL 形式に設定しようとしています。とはいえ、ほとんどの人が抱えている見落としにダイヤルインしたと思います-それは、「ページに到達した、予期されておらず、URLへの正規のパスになるために再書き込みされたURLはどうですか?」というものです。ここでの答えは、これらの「悪い要求」を見つけたら書き直すことです。例: ISP のミラーリングされたドメイン要求を書き直した場合、ロードされたページに到達するまでに、それは有効な URL になります。これは、書き換えルールによって「修正」されたためです。わかる？だからあなた」ISP によって作成された不正なルートを処理するには、MVC ルートを更新する必要があります。注: 正規リンク値を作成するときは、最初に要求された URL を使用するのではなく、最終的に書き換えられた URL を使用するようにしなければなりません。

私の WWW と非 WWW のヒント、および無効な URL を処理しないことに関してあなたが言及したことについての懸念を続けてください。

あなたのサイトは、人々がいつも忘れている別のドメインをすでに「ミラーリング」しているため、人々はこれを行います. 「WWW」サブドメイン。

信じられないかもしれませんが、議論はされていますが、www.yourdomain.com/mypage.htm と yourdomain.com/mypage.htm を使用すると、「重複した」コンテンツが原因で実際​​にページのランキングが低下していると多くの人が述べています。これが、実際には「WWW」が取り除かれたドメインであるため、「同じドメイン」が表示されている理由だと思います。(私は書き換えルールを使用して、www と no-www の一貫性を保ちます。)

また、「サイトのドメインへのリクエストのみに応答するように IIS サイトを構成する」ことにも注意してください。なぜなら、Google がまだそこにリンクを見つけてサイトの一部であると見なした場合、実際にはページの読み込みに失敗したことでペナルティを受ける可能性があるからです (つまり、404s) それらを「実際の」ドメインに送信する書き換えルールを設定するか、少なくとも「実際の」ドメインのみを使用するように正規リンクを設定して、一貫してそこにある、またはそこにない WWW を使用することをお勧めします。（どちらが優れているかは議論されていますが、一貫している限り問題ではないと思います。）

于 2012-04-08T01:57:56.613 に答える
1

現在の URL を rel=canonical リンク要素に挿入するだけで、彼らはどのような問題を解決しようとしているのでしょうか?

なし！彼らは事態をさらに悪化させるだけです！彼らは誤解されているだけです

この問題には誤解を招くような回答があります。ここでは、受け入れられて賛成票が投じられたスタック オーバーフローについても説明しています。

全体のコンセプトは、canonical タグ内の異なるコンテンツを持つ各ページに一意のリンク IDを生成することです。

そのため、canonical タグに固有のリンクを作成する良い方法は、に基づいています。

Controller Name、Action Name、およびLanguage 。これら 3 つのバリエーションは、異なるコンテンツを提供します。

Domain、Protocol、およびLetterの大文字と小文字は違い ます。

理解を深めるために、こちらの質問と私の回答を参照してください。

MVC rel="canonical" の自動生成

于 2016-12-15T16:59:21.993 に答える