ライブドアブログの記事情報一覧取得
Analytics でパラメータに記事の ID を入れても ID だけでどの記事なのか判断が難しいです
記事名も送っておけばいいのですが ID しか情報がないところでページ上で記事名まで取得して Analytics に送るのは違う気もします
とはいえ RDB のテーブルジョインみたいなことできなそうですし 見るときに自分で記事 ID から記事名を探してます

都度探すのも面倒なので記事一覧を手元に持っておきたいなと思って取得することにしました
エクスポートデータだとパースし辛いので別のところから取得します

ブログの一覧ページを使ってもいいのですが 今回は管理画面で内部的に使われている API を使うことにしました
一覧ページだとページ当たりの記事数がブログの設定依存になりますし ページ数が少ないと取得するページ数が多くなります
1000 記事あって 記事/ページ が 10 なら 100 回アクセスしないといけないです
あと HTML はパースが少し面倒です
管理画面で使われてるものだと JSON で受け取れますし 一度の取得数をパラメータで指定できるようでした
画面で設定可能な 200 が最大でしたが 200 あれば十分です
ただ内部的なものなので頻繁に仕様が変わってこのままだと使えなくなるかもしれません

記事一覧画面でコンソールを開いて↓のコードを貼り付けます

const request = (page) => {
const url = new URL(location.pathname + "api/articles_pager", location.origin)
url.searchParams.append("_", Date.now())
url.searchParams.append("keyword", "")
url.searchParams.append("attachment_id", "")
url.searchParams.append("category_id", "")
url.searchParams.append("monthly", "")
url.searchParams.append("entries_per_page", 200)
url.searchParams.append("rkey", window.rkey)
url.searchParams.append("p", page)

return fetch(url).then(res => res.json())
}

const pages = []
const updatePages = (entries) => {
for (const entry of entries) {
pages.push({
link: entry.permalink,
id: entry.id,
datetime: entry.regist_datetime,
title: entry.title,
})
}
}

let page = 1
while (true) {
const data = await request(page)
updatePages(data.entries)
if (data.pager.last_page <= page) break
page++
await new Promise(resolve => setTimeout(resolve, 100))
}
copy(pages)

非同期処理を挟むとコンソール上の copy が使えなくなるので copy だけ別に分けて実行します
異常なアクセス数
最近メインの方のブログで異常なアクセス数になってることがあります

many-access

サーバーはライブドアブログのものなので私にとってはどうでもいいことですが 1 人で同じページに数千回のアクセスってもう攻撃レベルですよね
自分でサーバーを管理する場合はこういうのに対応しないといけなくて大変そうなので やっぱりこういうサーバー管理は自分で行わないサービスがいいですね

にしてもここまでくれば IP をブロックしてもいいと思うのにこれだけのアクセス数が数えられてるってことはブロックせずレスポンスを返してたってことで緩めなんだなと思います
Google にインデックス登録されてない
ググって出てくるページと出てこないページがあるので Search Console で見てみるとインデックスに登録されてないページもありました
1 ヶ月以上前の記事でも登録されてないのがあったりで どこかからリンクされない限り登録されなそうです

一応ライブドアブログには ping 機能があって Google などには通知されてるはず と思ったのですが Google は ping のサポートを終了したという情報も出てきます
https://developers.google.com/search/blog/2023/06/sitemaps-lastmod-ping?hl=ja

エンドポイントとしては 6 月から 6 ヶ月後なので今年中は動いてそうですが あくまでエンドポイントが生きてるだけでレスポンスはエラーにならず返ってくるもののすでに意味はないという状態なんでしょうか

ただ これはサイトマップの ping であり 個別記事のものではない気がします
ライブドアブログが送信先として設定しているのはこれです
http://blogsearch.google.com/ping/RPC2

ググるとこれはもう何年も前に終了してるという情報も見かけます
どっちにしても ping 機能は意味ないと考えて良さそうです

そうなると Google のクロールに任せるしかないのですが その結果登録されてないのですよね
ブログですし トップページから新着記事へのリンクはあるのですけど
調べていると 小さいサイト (ページ数が 500 以下) はサイトマップが不要だけどページ数が多いならサイトマップを登録したほうが良さそうという情報もあります
https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview?hl=ja

このブログですら記事ページは 1000 近くありますし あったほうがいいのかもしれません

サイトマップは Atom や RSS で良いみたいです
ライブドアブログだと自動で作られていて atom.xml や index.rdf にアクセスすると見れます
でもこれらはトップページの HTML 内で参照されていますし自動認識されてるようにも思いますけど

<link rel="alternate" type="application/rss+xml" title="RSS" href="https://let.blog.jp/index.rdf" />
<link rel="alternate" type="application/atom+xml" title="Atom" href="https://let.blog.jp/atom.xml" />

ただ これは PC 版のみで モバイル版の HTML には含まれてませんでした
モバイルファーストでクロールしてるのなら Google はこれらの URL を知らないという可能性もあります
とりあえず Search Console からサイトマップとして登録してみました

atom.xml の方は Google が期待するフォーマットと一致しないみたいでエラーになりました
index.rdf だと問題なかったのでライブドアブログでサイトマップ登録するならこっちを使うと良さそうです
ライブドアブログのリッチリンク機能
特に使ってこなかったけど ライブドアブログの機能で通常のリンクとは別にリッチリンクって機能があります
一部のブログでは見かけるもので 大きめのブロックで記事タイトルや画像が表示されたりします

こんなの↓


テキストや画像をリンクにせず 単純に https://~~ みたいな URL をリンクにしてるのならこれのほうがよかったりするのかもとふと思いました

ですが中身を見てみると いまいちなものでした

iframe になっていて src には専用ドメインで UUID くらいしか情報がありません

<iframe  frameborder="0" scrolling="no" style="height: 120px; width: 580px; max-width: 100%; vertical-align:top;" src="https://richlink.blogsys.jp/embed/7a07f8d3-1c61-333f-b67f-31d0933ba2cd"></iframe>

https://richlink.blogsys.jp/embed/7a07f8d3-1c61-333f-b67f-31d0933ba2cd

です
UUID だけで元 URL の情報がないので扱いづらいです
元 URL を知るために上のページにアクセスしないといけません
それにもし将来的にこのリッチリンク機能が終了したら 復元手段がないです
変なことせず素直にパス部分に元 URL をそのまま入れる形式にしておいてくれればよかったのに
ライブドアブログの記事 ID
ライブドアブログの記事 ID は全ブログで共通の ID で連番になってると思ってたけど
このブログは 24387993 みたいに 2 千万番台
メインのブログは 83109131 みたいに 8 千万番台

どういう基準なんだろう?

単に分散処理にしてるのかな
ID が重複したらダメだから ID 作るところは並列処理できないはず
同時リクエストが多いとそこで待ち時間が長くなりそう
一千万ごととかでカウンタわければ カウンタの数で並列処理できるし待ち時間減りそう

とは言っても ID 振るのなんてミリ秒単位の処理だと思うし Twitter とかならともかくライブドアブログの規模で必要なのかなとも思う
https 化試してみた
ライブドアブログが https 対応したっぽいのでこっちのサブブログで試してみてます
こっちは余計なものは極力入れない作りにしてるので http のリソースのロードも特になくて問題なさそうです

個人的にブログみたいなものに https は不要だと思うのでメインの方は特に変える予定はないです
JavaScript の機能で http だと制限されるものもありますが そういう機能を使うツールなどはすでに Gist に置くようにしているので今更変えるの面倒ですし

ところで 証明書を見てみたところ Let's Encrypt でした
無料ですし 最近ならまぁそれですよね
ただ Let's Encrypt だと Android 7.1 以降は対応しないみたいな情報もあって 離れる人も多そうな気はします
当初の予定だと今月末の 9/29 で見れなくなるそうですが ルート証明書を古い方で作っていれば来年の 9/29 までは見れるそうです
ライブドアブログの証明書のルート証明書は古い方の DST Root CA X3 だったので来年までは見れそうです

今じゃ Android 11 が出ようとしてるのに 7.1 なんてと思いますが Android 端末はメーカーが更新を出さないので上げられないんですよね
少し前に買った Android タブレットは結局一度もアップデートが来ないで 6 か 7 でした
買った頃はすでに 8 か 9 が出ていたのに OS がリリースされても端末に搭載されるまで 1 年以上かかってたりです
ユーザの多いスマホならともかくその他の Android 搭載系端末じゃ基本アップデートはないものと考えていいくらいですし
1 年伸びたところで来年になってもまだ Android 7.1 以下のユーザはまだまだいそうですけどね
ライブドアブログのエディタ
普段 markdown のような 自作の独自フォーマットの記法から HTML 生成したのをブログエディタに貼り付けて最終的な見た目調整だけして記事公開してるけど一度 HTML 化したらあとから編集が面倒だし 改善したいなーと思うことも多め

ライブドアブログのエディタ自体の仕組みがわかれば拡張機能権限でいろいろ改造して機能追加や変更してカスタマイズできるけどいまいちなんの wysiwyg ツールなのかもわからない

ソース見てみると punymce というのが使われてるみたいだけど
ググってもあんまり情報なくて github には Java のプロジェクトがあるくらい
Star も 50 ないくらいだし本当にこれ?と思うようなもの
見た感じ昔からある古いやつみたいだし 時代を考えるとサーバ側で JavaScript 出力まで全部管理してるようなものでもなんか納得はできるけど……

と思ったのにサーバのレスポンス見たら 「Server: Plack::Handler::Starlet」 ってヘッダが
見たことなかったけど調べてみたら Perl のサーバで使われるみたい
やっぱりよくわからない

類似っぽいので tinymce というのがあってこっちは github で 7000 近くスターがあって npm でインストールもできて デモを見ても割と今風
https://github.com/tinymce/tinymce
https://www.tiny.cloud/docs/demo/full-featured/

もうこれにしてくれたらいいのに

結局 古すぎるのかまともに情報もなかったので 実体の textarea を元に自分で wysiwyg 部分を作って 標準の wysiwyg には触れないというのが一番楽になりそう
それなら好きなライブラリにできるし……
標準機能もフォントサイズやカラーくらいの基本機能しか使ってないからあんまり困らないと思う
ただ画像の追加だけが困りどころだなぁ