てがろぐ
- Fumy Otegaru Memo Logger -
No.3495, No.3494, No.3493, No.3492, No.3491, No.3490, No.3489［7件］
てがろぐでは、投稿内に含まれる1つ目の画像をOGPの og:image に出力する機能がありまして、デフォルトで有効になっています。
この機能では、投稿内にある1つ目の画像を問答無用で採用するので、1つ目の画像が「Twitter側がCardに求める様式」に該当していない場合は、Twitter Cardには画像が表示されないことになります。#🌱豆知識
一番よくありそうなケースは、SVGな気がします。Twitter CardはSVG形式の画像をサポートしていないので、SVG画像が1枚目にあるとTwitter Cardに画像は出ません。WebPは使えます。
あと、Twitter側が指定している条件は下記の通りです。
▼summary(小画像の場合)：Twitterのドキュメント
▼summary_large_image(大画像の場合)：Twitterのドキュメント
この機能では、投稿内にある1つ目の画像を問答無用で採用するので、1つ目の画像が「Twitter側がCardに求める様式」に該当していない場合は、Twitter Cardには画像が表示されないことになります。#🌱豆知識
一番よくありそうなケースは、SVGな気がします。Twitter CardはSVG形式の画像をサポートしていないので、SVG画像が1枚目にあるとTwitter Cardに画像は出ません。WebPは使えます。
JPG, PNG, WEBP and GIF formats are supported. Only the first frame of an animated GIF will be used. SVG is not supported.
https://developer.twitter.com/en/docs/twitter-for-webs...
あと、Twitter側が指定している条件は下記の通りです。
▼summary(小画像の場合)：Twitterのドキュメント
Images for this Card support an aspect ratio of 1:1 with minimum dimensions of 144x144 or maximum of 4096x4096 pixels. Images must be less than 5MB in size. The image will be cropped to a square on all platforms.
➡ 縦横比 1:1、最小サイズ 144x144、最大サイズ 4096x4096 ピクセル。画像サイズは 5MB まで。画像は正方形にトリミングされる。
▼summary_large_image(大画像の場合)：Twitterのドキュメント
Images for this Card support an aspect ratio of 2:1 with minimum dimensions of 300x157 or maximum of 4096x4096 pixels. Images must be less than 5MB in size.
➡ 縦横比 2:1、最小サイズ 300x157、最大サイズ 4096x4096 ピクセル。画像サイズは 5MB まで。
この動作試験場(兼サポート場)では、先頭固定投稿の投稿日時が「本来の投稿日時」ではなく「アクセスした瞬間の日時」になっています。先頭固定投稿の日時表示をどうするかは、管理画面の［設定］→［ページの表示］→【先頭に固定表示する投稿】の「先頭に固定する投稿の日付表示」欄で下図のように選択できまして、ここでは下図のように「現在日時(アクセスされた瞬間の日時)を表示」に設定してあります。
このような設定項目を設けているのは、先頭に固定された投稿の投稿日時が古い場合は、「アクセス者が最初に見る(可能性の高い)投稿日時」が古いことになるので、そこを見ただけで「なんだ、このページはさっぱり更新されていないではないか」と誤解されてしまう可能性があるかなと思いまして、それを避けるためです。
他にも、そもそも投稿日時を出力しない設定とかにもできます。デフォルト設定は「本来の投稿日時」です。#🌱豆知識
詳しくは、ヘルプドキュメントの「先頭に固定した際にだけ投稿日時の文字列を自動変更する方法」をご覧下さい。
このような設定項目を設けているのは、先頭に固定された投稿の投稿日時が古い場合は、「アクセス者が最初に見る(可能性の高い)投稿日時」が古いことになるので、そこを見ただけで「なんだ、このページはさっぱり更新されていないではないか」と誤解されてしまう可能性があるかなと思いまして、それを避けるためです。
他にも、そもそも投稿日時を出力しない設定とかにもできます。デフォルト設定は「本来の投稿日時」です。#🌱豆知識
詳しくは、ヘルプドキュメントの「先頭に固定した際にだけ投稿日時の文字列を自動変更する方法」をご覧下さい。
さくらソイラテを飲みました。🌸🌸🌸
🍓Re:3489◆Perlで書けば書くほど他の言語に移植しにくくなると思うので、PHPに置き換えるのが最終目標なら、先に現状をPHPに移植するところから始めた方が良いのではないかな……という気もします。ある機能を作るとき、Perlで書くのとPHPで書くのとではPHPの方が圧倒的に便利なので、（最終的にPHP化しようという考えがあるなら）Perlで機能追加はしない方がトータルでは楽なのではないかな……と思います。いや、もちろん開発者次第ではありますが。^^;
🍓Re:3490◆ご表明をどうもありがとうございます！ あれから全く製作は進んでいないんですが(^_^;)、製作再開しても良いかな……という気もしつつあります。
🍓Re:3491◆何か対処法があれば良いのですが、なかなかなさそうな気がしているのですよね……。対策としては rel=canonical でURLを正規化する方法があるわけですけども、だからといって、特定のハッシュタグ限定ページや日付別ページを、特定の単独ページに正規化して良いわけではないですよね……。postid=のパラメータがないURLのクロールをブロックする手はあるかも知れませんが。(^_^;) 何か良い方法はないですかね？？ ある条件での限定ページで、対象投稿が1件しかなかった場合には、その単独投稿ページのURLを rel=canonical で指定するようにする、という手はありそうな気もするのですが。
(追記)
🍓Re:3492◆おっと、回答を書いている間にレスが。rel=noindex でブロックした場合も「noindex タグによって除外されました」という理由でリストアップされるので、正攻法としては rel=canonical しかないのかな、という気もしています。というか、そういう重複ってCMSではどこでも発生しそうなので、何かそれ専用の対策をGoogleが用意してくれても良いのではないかと思うのですけどもね……。^^; rel=canonical みたいに正規化はせずに、しかし「このページには他のページと同じコンテンツが含まれていますよ」と示すだけに留めておくmeta指示みたいな……。^^;
(さらに追記)
Search Consoleをよく見たら、rel=canonical で正しく正規化できている場合でもなお、「代替ページ（適切な canonical タグあり）」という理由で『ページがインデックスに登録されなかった理由』欄にリストアップされていますので、これはもうCMS的なツールでは避けようがない、という解釈で居るのが良いのではないでしょうか。(^_^;;; >>3492,3491
「登録されたいのに登録されない」という場合は問題ですが、そうでないなら（検索上不利になるエラーとかそういうわけではないので）No.3492さんのおっしゃるように気にしないのが良いのではないかな……と思います。
🍓Re:3489◆Perlで書けば書くほど他の言語に移植しにくくなると思うので、PHPに置き換えるのが最終目標なら、先に現状をPHPに移植するところから始めた方が良いのではないかな……という気もします。ある機能を作るとき、Perlで書くのとPHPで書くのとではPHPの方が圧倒的に便利なので、（最終的にPHP化しようという考えがあるなら）Perlで機能追加はしない方がトータルでは楽なのではないかな……と思います。いや、もちろん開発者次第ではありますが。^^;
🍓Re:3490◆ご表明をどうもありがとうございます！ あれから全く製作は進んでいないんですが(^_^;)、製作再開しても良いかな……という気もしつつあります。
🍓Re:3491◆何か対処法があれば良いのですが、なかなかなさそうな気がしているのですよね……。対策としては rel=canonical でURLを正規化する方法があるわけですけども、だからといって、特定のハッシュタグ限定ページや日付別ページを、特定の単独ページに正規化して良いわけではないですよね……。postid=のパラメータがないURLのクロールをブロックする手はあるかも知れませんが。(^_^;) 何か良い方法はないですかね？？ ある条件での限定ページで、対象投稿が1件しかなかった場合には、その単独投稿ページのURLを rel=canonical で指定するようにする、という手はありそうな気もするのですが。
(追記)
🍓Re:3492◆おっと、回答を書いている間にレスが。rel=noindex でブロックした場合も「noindex タグによって除外されました」という理由でリストアップされるので、正攻法としては rel=canonical しかないのかな、という気もしています。というか、そういう重複ってCMSではどこでも発生しそうなので、何かそれ専用の対策をGoogleが用意してくれても良いのではないかと思うのですけどもね……。^^; rel=canonical みたいに正規化はせずに、しかし「このページには他のページと同じコンテンツが含まれていますよ」と示すだけに留めておくmeta指示みたいな……。^^;
(さらに追記)
Search Consoleをよく見たら、rel=canonical で正しく正規化できている場合でもなお、「代替ページ（適切な canonical タグあり）」という理由で『ページがインデックスに登録されなかった理由』欄にリストアップされていますので、これはもうCMS的なツールでは避けようがない、という解釈で居るのが良いのではないでしょうか。(^_^;;; >>3492,3491
「登録されたいのに登録されない」という場合は問題ですが、そうでないなら（検索上不利になるエラーとかそういうわけではないので）No.3492さんのおっしゃるように気にしないのが良いのではないかな……と思います。
>>3491 google seach console で未登録のページが多数存在している件について
現状できるのはrobots.txtで該当パラメータをブロックするくらいだと思いますがこれをしてもgoogle seach console「robots.txtによりブロックされました」とリストアップされてしまいます。タグや区分のリンクをインデックスに登録したい（検索結果に表示されるようにしたい）、というのでなければそんなに気にしなくてもいいのではと思います
設定でタグや区分のリンクにrel=noindex,nofollowを付加できるようになったらいいのかなぁと思いますが…
現状できるのはrobots.txtで該当パラメータをブロックするくらいだと思いますがこれをしてもgoogle seach console「robots.txtによりブロックされました」とリストアップされてしまいます。タグや区分のリンクをインデックスに登録したい（検索結果に表示されるようにしたい）、というのでなければそんなに気にしなくてもいいのではと思います
設定でタグや区分のリンクにrel=noindex,nofollowを付加できるようになったらいいのかなぁと思いますが…
いつも、てがろぐ cgi をありがたく使わせて頂いております。ありがとうございます。
ご質問があるのですが、google seach console で、ページが重複しているためインデックスに登録できないとの理由で未登録のページが多数存在します。
どうもタグや区分のリンクを全てクロールしているみたいです。実際のページ数は250なのに1500ページが未登録になっています。対処方があれば教えて下さい。よろしくお願い致します。
ご質問があるのですが、google seach console で、ページが重複しているためインデックスに登録できないとの理由で未登録のページが多数存在します。
どうもタグや区分のリンクを全てクロールしているみたいです。実際のページ数は250なのに1500ページが未登録になっています。対処方があれば教えて下さい。よろしくお願い致します。
てがろぐユーザーリンク集、作られたら登録します！
他の方のてがろぐサイトも沢山見てみたいです。
他の方のてがろぐサイトも沢山見てみたいです。
Perlでできた5ch風掲示板スクリプトの改良を行っていますが、人が集まって手分けしてやっても難しいですね・・・
にしし様のスクリプトを参考に改良していきたいと思っています。参考になります。
https://github.com/PrefKarafuto/New_0ch_Plus
にしし様のスクリプトを参考に改良していきたいと思っています。参考になります。
https://github.com/PrefKarafuto/New_0ch_Plus
