ドメインに重複ページがいくつかあります。重複ページの正規化タグをJavaScriptを使って元のページに参照させる必要があります(重複ページには相当なトラフィックがあるため、削除は選択肢ではありません)。DiscourseでJavaScriptを使ってaタグのhref属性を更新する方法をご教示ください。
@KranthiKiranGude さん、こちらが JavaScript で href 属性を変更する方法です。まず DOM 要素を選択し、その後で属性を変更します。
<script>
var uC = document.querySelectorAll("link[rel='canonical']")[0];
var newURL = "https://my.coolforum.com/newlink";
uC.setAttribute("href", newURL);
</script>
もちろん、操作対象のページに応じて何らかのロジックを追加する必要があります。
一般的なロジックの例:
<script>
if("the_actual_page_url_or_id" == "my_interesting_page_url_or_id")
{
var uC = document.querySelectorAll("link[rel='canonical']")[0];
var newURL = "https://my.coolforum.com/newlink";
uC.setAttribute("href", newURL);
}
</script>
お役に立てれば幸いです。
@neounix さん、こんにちは。
コードを試してみましたが、href が更新される代わりに、新しい script タグが生成されてしまいました:
![]()
このスクリプトを「/head」セクションで更新しました。
ご使用になった正確なコードと、どこに追加されたのかを明記して投稿してください。また、ご指摘の <head> セクション内のエントリーのスクリーンショットも添付してください。
ありがとうございます!
JavaScript を追加すれば新しい JavaScript が生成されるのは当然です。
なお、ページソースコードではなく、Web 開発者ツールのコンソール(要素)で DOM を確認する必要があります。
了解しました。
ところで、スクリプトの条件文に開始クォートが抜けていますね……
@neounix さん、こんにちは。
Dev Console では機能しましたが、Page Source では実際の URL が参照されたままになっています。
私の理解が間違っていなければ、検索エンジンは DOM 要素ではなく Page Source から情報を取得します。もし間違っていたら、ご指摘ください。
正直なところ、その点については確信がありません。以前は、現代の検索エンジン(GoogleBot)は DOM を読み取ると考えていましたが、よく考えてみると、検索エンジンがソースコードのみを読み、DOM は読み取らないという可能性もあるかもしれません。
しかし、これを Google で確認すると、以下のように書かれています:
DOM 内の SEO シグナル(ページタイトル、メタ説明、正規化タグ、メタ robots タグなど)は尊重されます。DOM に動的に挿入されたコンテンツもクロール可能でインデックス可能です。さらに、特定のケースでは、HTML ソースコード内の矛盾する記述よりも DOM シグナルが優先される場合もあります。これはさらに検証が必要ですが、いくつかのテストではそのようでした。
参考:
https://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157
@neounix さん、こんにちは
ご支援いただき、誠にありがとうございます。こちらでもこの部分について調査いたします。本当にありがとうございます。
ようこそ!
調査の結果については、改めて投稿して教えてください。
最近、私の空いた時間に検討しているもう一つの方法は、この Discourse の Ruby ライブラリファイルを直接修正することです。
DOM 操作の JS 手法でうまくいかない場合は、このようなアプローチもご検討ください、@KranthiKiranGude
@neounix さん、こんにちは。
URL 検査ツールを使用してページをテストしたところ、Google が更新された URL を認識していることが確認できました。
完璧です… 機能して何よりです。
テストして報告してくださり、ありがとうございます。
追伸:その JS DOM メソッドは、canonical_url.rb を操作するよりもはるかに簡単ですね ![]()
JavaScriptでcanonicalを上書きしても機能するかどうかは確信が持てません。これは、インデクサーレベル(データを解釈して検索インデックスに格納する部分)よりも、スパイダーレベル(データを取得・収集する部分)に関わる問題だからです。
余計なお世話かもしれませんが、このトピックをお読みになり、オーバーライドをプラグイン内で実装することをお勧めします:
はい、私も同じく確信が持てません。まだ結論は出ていません。
ただし、このトピックに関する Google 検索では多くの有益な情報が見つかります。多くの人がこの手法を実践しており、Google が DOM の変更を尊重すると述べる人もいれば、尊重しないと述べる人もいます。つまり、この点について明確で圧倒的な合意は存在しないようです。例を挙げると以下の通りです:
もし私がこの手法を採用するなら、(1) ページソースから元の canonical タグを削除し、その後 (2) JavaScript で DOM に新しい canonical タグを挿入します。
その後、時間をかけて Google 検索コンソールを確認し、Google がどの URL をカノニカルとして選択したかを確認できます。
参考リンク:
多くの人が SEO にとってこれが重要だと考えているため、@KranthiKiranGude によるこの確認を踏まえ、改めて確認しました。
developers.google.com によると、JavaScript SEO の基礎を理解するには:
Googlebot は Web コンポーネントをサポートしています。Googlebot がページをレンダリングする際、シャドウ DOM とライト DOM のコンテンツを平坦化します。つまり、Googlebot が見えるのは、レンダリングされた HTML 上で表示されているコンテンツのみです。レンダリング後も Googlebot がコンテンツを認識できるようにするには、モバイルフレンドリーテスト または URL 検査ツール を使用し、レンダリングされた HTML を確認してください。
(1) @KranthiKiranGude がテストに URL 検査ツール を使用したこと、および (2) その方法でカノニカルが期待通りに変更されたことを確認したことから、Google の見解では、Googlebot はページがレンダリングされた後にこの DOM 内容の変更を「見て」登録していることがわかります。
参考:
はい、Google がインデックス作成時に DOM 内容をそのように平坦化するというアイデアには完全に賛成です。
ただし、いくつかまたはほとんどのmetaタグは、HTML 内に存在しているにもかかわらず、その意味は HTML プロトコルレベルではなく HTTP プロトコルレベルにあります。「インデックス作成時」と強調したのは、クロール時に DOM をそのように平坦化し、更新された正規 URL を考慮しているのかどうか確信が持てないからです。
(言い換えると、DOM 内容が「コンテンツに埋め込まれたメタデータ」も意味するかどうか確信が持てません。確かにそれをそのように「認識」しているようですが、そのように「利用」するかどうかはわかりません)。
もしかしたらこの記事の方がよく説明しているかもしれません:How Google Crawls Your Website and Indexes Your Content
Google が JavaScript サイトをクロールする必要がある場合、従来の HTML コンテンツには不要な追加の段階が必要です。これをレンダリング段階と呼び、何らかの追加時間を要します。インデックス作成段階とレンダリング段階は別々のフェーズであり、これにより Google はまず非 JavaScript コンテンツをインデックス化できます。
いいえ、残念ですがそうではありません。www.hillwebcreations.com のこの記事は、DOM やその検査方法などについて全く言及していませんし、少なくとも私にとっては「時代遅れで主観的」(現在の事実を反映していない)と読めます。
個人的には、以下の 2 つの参考資料の方が、より権威があり、事実に基づき、信頼できる参考文献だと考えています:
そして、実際にテストを行った最初の資料です(これは、GoogleBot が Chromium コアに切り替わり、DOM(JavaScript)をより効果的に読み取れるようになるずっと前の話です):
Googlebot が JavaScript をどのようにクロールするかをテストした結果
私の調査に基づくと、Google 開発者の見解に賛同します。つまり、URL 検査ツールで確認できる内容がインデックスされ、SEO シグナルとして取得されるということです。したがって、SEO シグナルやコンテンツを「評価」できるのは、このツールによる確認結果に基づきます。Google の議論は明確で、事実に基づき、権威があり、推測に頼っていません。
@KranthiKiranGude 氏は、Google が「これだけで十分」と述べている URL 検査ツールを使用して、正規リンクを更新したことを確認しました。これは、SEO の観点から Google がページをどのように捉えているかを見るための唯一必要な手段です。
技術的まとめ
Google が URL 検査ツールから見える内容に基づいて SEO シグナルを使用していること、また Google 開発者が URL 検査ツールで直接 SEO シグナルを分析できると明確に述べていること、さらに @KranthiKiranGude 氏が DOM に対して行った JavaScript の変更が URL 検査ツールで確認できるという事実を考慮すると、私にとっては「これで十分すぎるほど良い」と言えます。
参考になれば幸いです。
はい、その記事では確かに、ソースコード内に存在する場合と全く同じように振る舞う動的に挿入された canonical タグを「確認した」と明記されています。あなたの言う通りです(あなたが最初に投稿した際にもっと詳しく読むべきでした)。
[quote=“RGJ, post:18, topic:159527”]
はい、その記事は確かに、ソースコード内に記述されているかのように、動的に挿入されたカノニカルタグが同じように機能することを「確認した」と明確に述べています。おっしゃる通りです(初めて投稿された際にもっとよく読むべきでした)。[/quote]
余談ですが @RGJ、「現在のものではない」という点について混乱させてしまい申し訳ありません。
私が「時代遅れ」や「現在のものではない」という言葉を使う場合、記事の物理的な日付ではなく、概念やアイデアについて話しています。
「今日」の日付が付けられた記事でも、その概念は「時代遅れ」(そして誤り)であることがあり、逆に10年前に書かれた記事でも、現在でも非常に関連性が高いものがあります。
私が「時代遅れ」や「現在のものではない」と言うとき、意味しているのは紙やウェブ記事に書かれた物理的な日付ではなく「概念」に基づいているということです。このように用語を使用してしまったことで混乱を招いた場合は申し訳ありません。
少なくとも私の考えでは重要なのは、@KranthiKiranGude さんに解決策を提供し、それが機能することを確認してもらったことです。また、あなたの懐疑的な投稿をきっかけに、私たちはこの問題についてさらに追加調査を行いました。
私たちは以下の3点を検証しました:(1) JavaScript を使用してカノニカルリンクを変更する方法は有効であること、(2) Google の開発者がこれを確認していること、(3) ユーザーとして URL 検査ツール(@KranthiKiranGude さんが使用し共有してくれたもの)を使って確認する方法があること。
この興味深いトピックについて「行き来」をしてくださり、解決策をさらに確実で強力なものにするお手伝いをしてくださり、心より感謝申し上げます。
私は他のタスクに移ります(10年以上の PHP コーディング経験にもかかわらず、まだ Ruby on Rails の習得に苦労しています);このトピックは完全に「任務完了」です ![]()
また次の機会まで、皆様のご健勝をお祈りします!
