Zennに48本出していいねは11。新しく書くのをやめて、在庫が尽きるまで流して畳むことにした

技術寄りの記事は Zenn、それ以外はこのブログ、と分けて書いてきました。
Zenn には書きためた記事の待ち行列を作り、1日1本ずつ自動で公開していました。

9月中旬、その Zenn に新しい記事を足すのをやめると決めました。
すぐに止めるのではなく、待ち行列に残っている分を流し切ってから決め直す形です。
決めた理由と、流しているあいだに起きたことを残しておきます。

目次

技術の記事は Zenn、ほかはブログに分けていました

7月から React と TypeScript を学びはじめて、技術のネタが一気に増えました。
エラーで詰まった話や、調べて分かった仕様の話です。
そういう記事は Zenn に、仕事や生活の話はこのブログに置いていました。

Zenn のほうは、書いた記事を待ち行列に入れておくと、1日1本ずつ自動で公開される仕組みにしていました。
まとめて出すのをやめて、毎日1本にしました。
その経緯はブログに書いています。

仕組みが回りはじめると、記事はどんどん溜まっていきました。
9月中旬の時点で、待ち行列には43本が入っていました。

9月中旬に数字を見たら、48本でいいねは11でした

9月中旬、Zenn に記事を足す処理が2日続けて投稿数の上限で弾かれました。
その片付けが終わったところで、Zenn の使い方そのものを見直すことにしました。

Zenn は自分のサイトではないので、どうしても使いにくさがある。
ブログのほうが自分には合っている。
ポートフォリオの制作も一段落して、記事の在庫も溜まった。
これから就職活動に進むなら、長く育てられるブログの投稿を増やしたほうがいいかもしれない。
そう考えていました。

数字を数えてみたら、9月中旬の時点で Zenn の公開記事は59本でした。
いいねの数が取れた48本で、合計は11です。
直近の15本に絞ると、13本が0でした。

一方のブログは、同じ時期の直近30日で86本を出していました。
1日3本のペースです。

「ブログの投稿を増やしたほうがいいかも」と考えていましたが、ブログはもう毎日3本出ていました。
本数を増やす余地は、あまり残っていません。
効きそうなのは、Zenn に回していた分をブログへ戻すことでした。

読まれている数が少ないのは、ブログも同じです。
違うのは、書いたものが自分のドメインに積み上がっていくかどうかでした。

新しく足すのをやめて、残りは流し切ることにしました

決めたのは次の3つです。

  • Zenn に新しい記事を足すのをやめる。長い記事はこれから全部ブログに出す
  • 待ち行列に残っている43本は、1日1本のまま流す
  • 待ち行列が空になったら、Zenn を続けるかどうかを決め直す

ブログの本数は1日3本のまま変えていません。
Zenn に行くはずだった技術のネタを、ブログの枠で書くことにしました。

すぐに止めて、43本をブログに回す案もありました。
ただ、そうすると43本ぶん、どの媒体に出すかの振り分けをやり直すことになります。
10月からは就職活動の準備に時間を使いたかったので、この案は見送りました。

止めるための作業を作らなかったので、決めた日からそのまま移れました。
待ち行列は止めずに動かし、新しく足さないだけです。
終わりの条件も、日付ではなく「待ち行列が空になったら」にしています。

1つの記事を両方に置けないことも、理由の1つでした

本当は、同じ記事をブログと Zenn の両方に置けたらいいと思っていました。
読む人がどちらから来るかは選べないからです。

同じ本文を2か所に置くときは、canonical という指定で「正本はこちら」と示すのが一般的です。
ところが8月に確かめた範囲では、Zenn 側から canonical をブログの URL に向けることはできませんでした。
ブログを正本にして Zenn に転載する、という形は取れません。

そのため、1つの記事はブログか Zenn のどちらか一方に置くしかありませんでした。
どちらか一方なら、自分のドメインに積み上がるブログに置いておきたい。
これも、新しい記事を Zenn に足すのをやめた理由の1つです。

流しているあいだも、投稿数の上限に弾かれ続けました

畳むと決めたあとも、待ち行列を流すだけで手がかかりました。

Zenn には、一定の時間に投稿できる記事の数に上限があります。
初めてこの上限に当たったときの話は、Zenn に書きました。
それ以来、記事を足す間隔を24時間より少し長くあける仕組みにしていました。

それでも、25時間あけた回が弾かれました。
弾かれると、その記事の公開は1日以上遅れます。

9月19日の朝、X に予約していた Zenn の告知が出ていないかもしれない、と気づきました。
告知は「毎日1本公開される」前提で予約していたので、公開がずれた日は、まだ開けない記事を指していました。
告知の仕組みは投稿の直前にリンクが開けるかを確かめていたので、開けない記事の告知は出ずに見送られていました。

記事を足した時刻と公開された時刻を並べてみました。
すると「前の記事の公開から24時間あければ通る」ように見えました。
ところがこの表は、弾かれはじめた9月15日から作っていて、それより前を見ていませんでした。
9月上旬まで広げて並べ直してもらうと、前の公開から1〜5時間後に足した5回は全部通っていました。
説明はそこで崩れました。

全部並べると、弾かれたのは前の公開から6時間・9時間・12時間後に足した3回だけでした。
3回しかないので、決まりとしては読めません。
Zenn の判定のしくみは公開されていないので、どの説明も仮説のままです。

対処として、記事を足す時刻を毎日20時に固定しました。
毎日少しずつ後ろへずれていく仕組みをやめて、通っていたころと同じ夜の時間帯にそろえました。

固定したあとも、9月22日と24日は弾かれ、23日と25日は通りました。
その後も9月30日と10月2日の分を、待ち行列の最後へ戻しています。
弾かれた記事をそのままにすると翌日以降も連鎖するので、最後尾へ戻して次の日に備える、という手当てを続けています。

弾かれたかどうかは、Zenn の記事の管理画面に登録されているかを自分で見て確かめていました。

合わなかったのは Zenn より、自分の使い方のほうでした

振り返ると、Zenn そのものが悪かったわけではありません。
毎日1本ずつ自動で流す、ブログを正本にして転載もしたい、という自分の使い方が合っていませんでした。

ブログは自分のサーバーの WordPress なので、検索からの数字も自分で見られます。
1日に何本出すかも、自分で決められます。
判定のしくみが見えない場所に自動化を組むと、通ったか落ちたかを毎日確かめる手間が残ります。

10月はじめの時点で、待ち行列には31本残っています。
1日1本で流れれば、空になるのは11月4日ごろの見込みです。
途中で弾かれれば、そのぶん後ろへ延びます。

空になったら、そのときのブログの検索からの流入や、就職活動の進み方を見て決め直します。
再開することになっても、記事の振り分けのルールは消さずに残してあるので、そのまま使えます。

目次