俺は、blog-sekkeiとは別に、ずみログというブログも運営している。
40代の投資、家事、暮らしについて、自分で試したことを書いているブログである。
blog-sekkeiで作ってきた記事DB、before、planned diff、GOの仕組みは、もともと記事制作を安全に進めるために整えてきた。
今回、その仕組みを使って、ずみログの既存82記事を見直した。
82記事すべてを書き直したわけではない。候補を調べ、必要な記事だけを直した。
きっかけは、Google検索で記事がどう扱われているかを確認できるSearch Consoleだった。
クロールされているのに、インデックスされていない記事がある。
1000字に届かない記事もある。
昔の文体のまま残っている記事もある。
最初は、そういう記事を順番に直せばいいと思っていた。
でも実際に始めると、それだけでは足りなかった。
短いから長くする。
インデックスされていないから書き直す。
古いから新しくする。
その基準だけで進めると、必要のない記事まで触ってしまう。
そこで使ったのが、これまでブログを作りながら少しずつ置いてきた仕組みだった。
公開記事のURLや状態を記録している記事DB。
変更前のbefore。
変更予定だけを書き出したplanned diff。
1本ずつ出すGO。
そして、直さないという判断。
新記事を作るために用意してきた設計が、82記事を見直すときにもそのまま使えた。
最初は、短い記事を直そうとしていた
ずみログには、公開済みの記事が82本あった。
その中には1000字未満の記事もある。
Search Consoleを見ると、クロール済みなのにインデックスされていない記事もあった。
だから最初は、「短い記事を厚くした方がいいのではないか」と考えた。
実際、候補を出すところまでは簡単だった。
文字数。
インデックス状態。
文体。
古い情報。
機械的に拾えば、直せそうな記事はいくらでも出てくる。
でも、ここで一度止まった。
短いことと、役に立たないことは同じではない。
逆に、3000字あっても、今の自分と内容がズレている記事もある。
直す前に必要だったのは、文字数ではなかった。
この記事は、今何のために残っているのか。
そこを決めることだった。
近い記事を並べて、それぞれの役割を決めた
たとえば、洗濯の記事がいくつかあった。
ドラム式洗濯機を買った話。
家を建てるときに物干し竿を作らなかった話。
洗濯物を畳むのをやめた話。
そのままだと、どれも「洗濯を楽にした話」に見える。
でも並べてみると、役割は違った。
ドラム式洗濯機の記事は、干す・取り込む作業が消えた話。
家づくりの記事は、そもそも干す場所を作らなかった話。
畳まない記事は、家電を入れたあとにも残った作業をやめた話。
ここまで分かると、リライトの方向が変わる。
内容を増やすのではなく、その記事にしかない役割が見えるように直せばいい。
ホットクックの記事でも同じことをやった。
料理を頑張るのをやめた入口。
献立を考えなくなった運用。
献立をパターン固定した途中の設計。
そこからOisixへ進んだ記録。
時短家電を増やしたら、手入れも増えた話。
全部を1本にまとめるのではない。
時間の流れとして分けた。
昔の記事が重複していたというより、役割が見えない状態で並んでいた。
WordPressだけを見て直したわけではない
今回、本文の正本として見たのはWordPressだった。
毎回、今公開されている本文を取得する。
変更前をbeforeとして残す。
その本文からplannedを作る。
ただ、WordPressだけでリライトしたわけではない。
記事のURLや関係を確認するときは、公開記事のURLや状態を記録している記事DBを見る。
制作中の判断は、記事ごとの判断を残しているarticle_stateを見る。
1本の記事をカルテ1枚で回してみた記録で整理したように、本文だけでは残らない判断もある。
読者向けの並びは目次を見る。
全部を1つのファイルに集めたわけではない。
情報ごとに、見る場所を決めていた。
その考え方は、前に正本を1つ決めたら、探す時間が減ったに書いた。
今回も、それがそのまま役に立った。
ある記事から別の記事へリンクを追加しようとしたとき、俺が想定していたURLを開くと、ページが見つからなかった。
そこで止めて、記事DBを確認した。
正しいURLが別に残っていた。
もし記憶だけでリンクを入れていたら、読者を「ページが見つかりません」と表示されるリンクへ送っていた。
記事DBを作ったときは、公開した記事を管理するためのものだと思っていた。
今回初めて、既存記事を安全に直すための台帳にもなっていると分かった。
beforeとplanned diffがあるから、1本ずつ直せた
今回、候補の記事をまとめて書き換えたわけではない。
毎回、1本ずつ確認した。
毎回やったことは同じだった。
最新本文を取る。
beforeを残す。
何を直すか決める。
変更予定だけを書き出したplanned diffを作る。
そこで止まる。
内容を確認してからGOを出す。
反映後はafterを取り、予定した差分だけになっているか確認する。
リンクも開く。
タイトルやURL、DBなど、触らないと決めた場所が変わっていないことも見る。
面倒に見える。
でも、この止まり方があったから、途中で方向を変えられた。
beforeを残す考え方は、変更する前にbeforeを残すようにしたで整理した。
変更を小さく切る考え方は、一度に全部直さない。1か所ずつGOを出すで書いた。
今回の82記事リライトでは、その二つが同時に効いた。
AIに慎重になってもらったというより、人間が途中で判断できる状態を残した。
一般論を減らして、当時の俺の判断へ戻した
古い記事には、今読むと少し強い表現も残っていた。
「オルカン一本でいい」。
「長期で持てば結果が出る」。
「40代からでも今日始める方が大事」。
当時は自分の経験を書いているつもりでも、文章だけを見ると一般的な投資アドバイスに見える。
自分の体験として書いた文章でも、前後の文脈が薄いと、時間が経ったあとに「みんなにも当てはまる答え」のように見えることがあった。
だから、全部を最新情報へ書き換えたわけではない。
俺が何を考えて、その選択をしたのか。
そこへ戻した。
「オルカンが正解」ではなく、FXで失敗した俺にはシンプルな投資の方が合っていた。
「節約をやめればお金が増える」ではなく、俺は機嫌や回復まで削る節約をやめた。
睡眠の記事も、原因を説明する文章ではなく、俺の場合に何をすると頭の中が静かになりやすかったかへ戻した。
新しい情報を足すより、一般論になってしまった文章を一次体験へ戻す修正の方が多かった。
直さない記事もあった
今回、一番大事だったのはここかもしれない。
候補に出た記事を、全部直したわけではない。
NISAの積立額を8万円にした記事も候補に出た。
一度は10万円まで増やした。
でも続けず8万円へ戻した。
残した2万円を、息子との外食など家族との時間に使う。
確認すると、その時系列は今も成立していた。
見出し構造も崩れていない。
文体も今の形だった。
全員に8万円を勧める内容にもなっていなかった。
だから直さなかった。
調査した結果、no changeで閉じた。
AIを使って記事を改善していると、何か変更した方が仕事をしたように感じる。
でも、今の状態で問題がないなら、触らない方がいい。
変更しないという判断も、リライトの一部だった。
最後に、「もう直さない」と決めた
82記事を見ていると、直そうと思えばいくらでも直せる。
もっと見出しを整えられる。
もっと内部リンクを増やせる。
もう少し文章を足せる。
でも、それを続けると終わらない。
今回、既知の主要候補を一巡したところで止めた。
新しく公開した記事は、Search Consoleの評価を待つ。
以前使っていた、今はページが見つからないURLも、今すぐ影響がないものは保留する。
次に見る日は決める。
それまでは、今回の監査を理由に既存記事を触らない。
ここまで決めて、ようやく終わった。
リライトを始める前は、古い記事を新しくする作業だと思っていた。
実際にやってみると違った。
必要だったのは、何を直すか、何を残すか、どの記事へ役割を渡すか、どこで止めるかを判断できる仕組みだった。
記事DBも、beforeも、planned diffも、1本ずつ出すGOも、別々に作ったときは小さな仕組みだった。
でも82記事を見直したら、全部つながった。
ブログの設計は、新しい記事を書くためだけのものではなかった。
古くなった記事を、壊さずに今へつなぎ直すためにも使えた。
コメント