昔作ったWordPressブログが、そのまま残っていませんか？
記事はある。
ドメインも残っている。
少しだけ検索流入がある記事もある。
でも、
「デザインが古い」
「何の記事を書いたか自分でも覚えていない」
「WordPressやテーマを何年も更新していない」
「今からこのサイトを育て直す価値があるのかわからない」
そんな状態になると、
いっそ新しいサイトを作った方が早いのでは？
と思うことがあります。
私にも、長いあいだ更新していなかったWordPressブログがありました。
最初は新しく作り直すことも考えました。
でも、昔の記事やドメインまで全部捨ててしまう前に、一度中身を調べてみることにしました。
そこでやったのが、
古いブログを監査して、残せるものと変えるものを分け、AIを使いながら少しずつ再構築すること
でした。
結果として、そのブログは現在の「SAKIのAI実践室」へ生まれ変わりました。
この記事では、単なるデザイン変更ではなく、
古いWordPressブログをもう一度使えるサイトにするために、どんな順番で考えたのか
をまとめます。
- 1 まずやったのは「新しく作ること」ではなく、古いサイトを調べること
- 2 過去記事は「残す・書き直す・表から外す」で考える
- 3 サイトの「これから何を書くのか」を先に決める
- 4 WordPress・テーマ・PHPは、一気に全部変えない
- 5 リニューアルでは「戻せる状態」を先に作る
- 6 本番サイトを直接触らず、先に試せる場所を作る
- 7 SEOは「リニューアル後に考える」のではなく、最初から守る
- 8 サイトマップやcanonicalは「誰が出しているか」を決める
- 9 デザインは「きれいにする」より「このサイトらしくする」
- 10 AIは「全部作ってもらう」より「確認と整理」にかなり使える
- 11 ただし、AIへ渡さないものを先に決める
- 12 新しい記事を増やす前に、トップページの役割を決める
- 13 公開したら完成ではなく、ここから数字を見る
- 14 古いブログは「作り直す」より「再利用できるものを探す」
- 15 もし今から古いWordPressブログを再生するなら、この順番で進める
まずやったのは「新しく作ること」ではなく、古いサイトを調べること
古いブログを見ると、すぐにデザインを変えたくなります。
テーマを変える。
トップページを作り直す。
ロゴを変える。
昔の記事を削除する。
でも、私は今回はそこから始めませんでした。
最初にやったのは、
今このサイトに何が残っているのかを確認すること
でした。
たとえば、
- 公開記事は何本あるのか
- どんなカテゴリがあるのか
- 今でも読まれている記事はあるのか
- 検索結果に残っているページはあるのか
- 古いプラグインは何個あるのか
- WordPressやテーマはどれくらい古いのか
- 広告やアクセス解析はどうなっているのか
こういうものを一度整理します。
古い部屋をリフォームするときに、いきなり壁を壊さないのと同じです。
何が使えて、何が危なくて、何を残したいのか。
まず現状を知る。
この作業をしておくと、
「古いから全部捨てる」ではなく、「使える資産は残す」
という判断ができるようになります。
過去記事は「残す・書き直す・表から外す」で考える
何年も前の記事を読み返すと、
「これはもういらないかな」
と思うものがたくさん出てきます。
でも、私は古いという理由だけで一括削除しない方がいいと思っています。
過去記事には、
今でも検索されているもの。
外部サイトからリンクされているもの。
少しだけでもアクセスがあるもの。
が残っている可能性があるからです。
そこで私は、過去記事を大きく、
残せるもの
書き直せるもの
新サイトの表側から外したいもの
に分けて考えました。
ここで大事なのは、
「トップページに見せたくない」と「URLを削除する」は別
ということです。
新しいサイトの世界観には合わなくても、検索資産として残した方がいい記事もあります。
だから、
まずナビゲーションやトップページから外す。
検索データを確認する。
そのあとで、本当に不要か判断する。
この順番の方が安全です。
サイトの「これから何を書くのか」を先に決める
古い記事を整理するだけでは、サイトは再生しません。
次に必要なのは、
これからこのサイトを何のために使うのか
を決めることです。
以前のブログと、これから作りたいブログが同じテーマとは限りません。
私の場合は、リニューアルをきっかけに、
AI活用。
ブログ・SEO。
自動化・仕組み化。
収益化。
実践記録。
という軸でサイトを作り直しました。
この軸を先に決めておくと、
トップページの構成も、
カテゴリも、
新しく書く記事も、
同じ方向を向くようになります。
デザインはそのあとです。
サイトのテーマが決まっていないのに先に見た目だけ作ると、あとから必要なページが変わって作り直すことになります。
WordPress・テーマ・PHPは、一気に全部変えない
古いWordPressサイトでは、
WordPress本体。
テーマ。
PHP。
プラグイン。
いろいろなものが古くなっていることがあります。
全部最新にしたくなります。
でも、ここで一気に変更すると、
何か壊れたときに、
何が原因なのかわからなくなる
ことがあります。
だから私が今回かなり意識したのは、
1段階ずつ変えて、毎回確認すること
でした。
たとえば、
WordPressを更新する。
↓
表示を確認する。
↓
テーマを更新する。
↓
もう一度確認する。
↓
PHPを変える。
↓
また確認する。
というように進めます。
時間はかかります。
でも、一度全部壊して原因を探し続けるより、結果的には早いことがあります。
リニューアルでは「戻せる状態」を先に作る
古いサイトを触るときに、一番重要だったのがバックアップです。
私は今回、
失敗しないことより、失敗しても戻せること
を重視しました。
変更前の状態を保存する。
大きな変更をしたら、また保存する。
問題が起きたら、直前の正常な状態まで戻す。
これができれば、
「壊れたらどうしよう」
と怖がって何も触れない状態から抜けられます。
AIに作業を手伝ってもらう場合も同じです。
AIは作業を速くしてくれます。
でも、速く変更できるからこそ、
変更前の状態を残しておくこと
がより重要になります。
本番サイトを直接触らず、先に試せる場所を作る
今回のリニューアルでは、できるだけ本番環境だけで実験しないようにしました。
本番サイトは、読者が見る場所です。
そこで、
表示されなくなる。
デザインが崩れる。
SEO設定がおかしくなる。
ということが起きると困ります。
だから、大きな変更はまず検証環境で試します。
うまくいかなければ戻す。
問題がなければ次へ進む。
そして、本番へ反映する前にもう一度確認する。
この流れです。
すべての個人ブログに大がかりな検証環境が必要とは思いません。
でも少なくとも、
本番へ反映する前に確認できる場所
があると安心感がかなり違います。
SEOは「リニューアル後に考える」のではなく、最初から守る
サイトリニューアルで意外と怖いのが、
見た目はきれいになったのに、検索上の設定が変わってしまうことです。
たとえば、
URLが変わる。
canonicalが変わる。
noindexが入る。
サイトマップが変わる。
ページタイトルが変わる。
こうしたものは、見た目だけ確認していても気づきにくいです。
だからリニューアルでは、
デザイン確認とSEO確認を別々にする
方が安全だと思っています。
私の場合も、
「見た目が正常」
だけで完了にはしませんでした。
ページが表示される。
スマホでも崩れない。
そのうえで、
検索エンジン向けの設定も変になっていないか確認する。
ここまでセットで考えます。
サイトマップやcanonicalは「誰が出しているか」を決める
WordPressでは、テーマやプラグイン、本体が似た機能を持っていることがあります。
それぞれが同じものを出力すると、
同じcanonicalが複数出る。
サイトマップが複数ある。
同じ計測コードが二重に入る。
ということがあります。
問題なのは、
「機能があること」
ではなく、
同じ仕事を複数のものが担当していること
です。
そこで私は、
「これは誰が担当するのか」
を決めるようにしました。
SEO設定ならこのプラグイン。
サイトマップならこれ。
広告コードならこれ。
というように、
1つの役割に1つの責任者
を決めるイメージです。
これはWordPressだけでなく、AIを使った仕事でも同じだと思っています。
デザインは「きれいにする」より「このサイトらしくする」
今回、サイトの見た目も大きく変えました。
でも目的は、
「今風にする」
だけではありませんでした。
SAKIのAI実践室では、
AI。
実験。
改善。
ひとり仕事。
というテーマが、一目で伝わる世界観にしたかったからです。
そこで、
暗いネイビー。
シアン。
ブルー。
紫。
ネオン。
を中心にした、少し未来的なデザインにしました。
ただ、デザインを作っていると、
「見た目としては正しいけれど、なんか違う」
ということがあります。
AIや自動チェックではPASSでも、自分で見ると好きではない。
そんなこともありました。
だから最終的には、
技術的に壊れていないかはAIに確認してもらい、好きかどうかは自分で決める
ようにしています。
AIは「全部作ってもらう」より「確認と整理」にかなり使える
古いブログを再生するとき、AIにできることは記事作成だけではありません。
私はむしろ、
現状整理。
問題点の分類。
変更手順の整理。
確認項目の作成。
比較。
文章の整理。
こういう部分でAIの便利さを強く感じます。
たとえば、
「今のサイトにはこの問題がある」
という情報がたくさん出てきたとき、
重要度順に整理してもらう。
一度に全部変えないように、順番を作ってもらう。
作業後に、
「どこを確認すればいい？」
とチェックリストを作ってもらう。
こういう使い方です。
AIは「代わりにブログを作る人」というより、
一人で運営するときの整理役・確認役
としてかなり使えます。
ただし、AIへ渡さないものを先に決める
AIを使うと作業は便利になります。
でも、サイト運営には、
ログイン情報。
APIキー。
非公開コード。
顧客情報。
内部設定。
など、公開したくない情報もあります。
だから私は、
「AIに何をやってもらうか」
だけでなく、
「AIや記事の中に何を出さないか」
も決めています。
特に、ブログでAI活用について発信するときは、
自分が実際に使っている内部の仕組みを全部公開する必要はありません。
読者に役立つ考え方は共有する。
でも、安全性や競争力に関わる内部実装は出さない。
この線引きは大切です。
新しい記事を増やす前に、トップページの役割を決める
サイトを作り直したあと、
すぐ記事を大量に増やしたくなります。
でも、その前に私はトップページを整えました。
トップページには、
どんなサイトなのか。
何が読めるのか。
まず何を読めばいいのか。
が必要です。
だから、
カテゴリ。
最新記事。
まず読んでほしい記事。
このサイトでわかること。
などを配置しました。
新しい読者が来たとき、
「何のサイトかわからない」
状態を減らすためです。
記事をたくさん作ることより、
記事同士をどう見せるか
も大切だと思っています。
公開したら完成ではなく、ここから数字を見る
リニューアルを終えると、
「完成した」
と思いたくなります。
でも、本当の意味ではここからです。
実際に公開して、
検索されるのか。
クリックされるのか。
どの記事が読まれるのか。
どの導線が使われるのか。
を見ていきます。
見た目として気に入っていても、読者が使いにくければ直す。
狙った記事が読まれなければ、タイトルや内容を見直す。
検索結果に出なければ、その原因を考える。
作る → 公開する → 測る → 改善する
ここまでがリニューアルだと思っています。
古いブログは「作り直す」より「再利用できるものを探す」
何年も止まっているブログを見ると、
古い。
ダサい。
記事も今の自分とは違う。
そんなふうに感じるかもしれません。
でも、そこには、
長く使っているドメイン。
昔書いた記事。
検索履歴。
自分が試してきた記録。
が残っています。
全部捨てる前に、
今の自分のテーマに使えるものはないか
を一度確認してみてもいいと思います。
私は今回、古いブログを消すのではなく、
その上に新しいサイトを作ることを選びました。
昔の自分が作ったものを土台にして、
今の自分がもう一度育てる。
それも、ブログを続ける一つの方法だと思います。
もし今から古いWordPressブログを再生するなら、この順番で進める
最後に、私なら今この順番で進めます。
STEP 1｜現状を全部調べる
記事、カテゴリ、アクセス、WordPress、テーマ、プラグインを確認。
STEP 2｜これからのサイトテーマを決める
誰に何を届けるサイトなのかを決める。
STEP 3｜過去記事を分類する
残す、書き直す、表から外す。
すぐ大量削除しない。
STEP 4｜バックアップを作る
変更前へ戻せる状態を確保する。
STEP 5｜基盤を一段ずつ更新する
WordPress、テーマ、PHPなどを分けて確認する。
STEP 6｜SEOの役割を整理する
canonical、サイトマップ、robotsなどの担当を明確にする。
STEP 7｜デザインを新しいテーマへ合わせる
サイトの目的に合った世界観へ変更。
STEP 8｜新しい柱記事を作る
各カテゴリの入口になる資産記事を用意する。
STEP 9｜トップページで記事をつなぐ
読者が次に何を読めばいいかわかる状態にする。
STEP 10｜公開後のデータを見る
検索・クリック・回遊・収益を見ながら改善する。
一度で完璧にしなくても大丈夫です。
小さく変えて、確認して、また次へ進む。
古いサイトだからこそ、このやり方が合っていると思います。