WordPress（ワードプレス）ブログ運営ブロガーの備忘録～忘れがちだけど大事なことメモ

2019年からWordPressでこのブログを始めました、ここちです。

 

現在4年目に突入したものの、日々の更新ペースがスーパー亀子なため、WordPressの操作といえば日常的な投稿やよく触る編集画面以外の部分がイマイチあやしかったりします。

ここでは、日々の運営でおろそかになりがちだったり、忘れがちだけど実は大事なポイントなど、（ほぼ）自分に向けての備忘録として、WordPress運用上のメンテナンスで欠かせない事をまとめていきます！

修正やメンテナンスの対象は

各記事ごとの場合とサイト全体の場合がありますので分けて書いていきます。

既存ページ（各記事）メンテナンス

記事数が増えると、修正が必要になるページ、頻度が増えていきますが、重要度が最高なのが不具合の解消。なので、具体的な不具合項目ごとに実際行う作業をメモしていきます。

デッドリンク修正

1ページずつのチェックは現実的ではないので、プラグインを利用。

デッドリンクが検出されるとメールが来るように設定されているので、メールを受信したら速やかに修正していきます。

【プラグイン】Broken Link Checker

WordPress　サイトメンテナンス

WordPress内で行う記事投稿など各種変更作業において発生していく不要なファイルが蓄積されて動作に影響がでるほど重くなっていくことを解消する目的で、プラグインを入れて不要ファイルを適宜削除していきます。

処理の自動化の設定部分については無料版では簡易な設定のみとなりますので、適宜手動で最適化の作業をするなど、自分でも管理が必要になります。

【プラグイン】WP-Optimize

ちなみにこのプラグインはセキュリティ関連の設定もあるので、他のセキュリティ関連のプラグインと機能的にかぶらないが確認のうえ、活用します。

低品質被リンクチェック

Google Search Consoleで「リンク」をチェック。

見覚えのないドメインから被リンクを受けていたら、あやしいサイトかどうかを確認して、サーチコンソールに「否認」リストをアップロード。

※2回目以降は上書きになるので、付け足し分だけをアップロードではなく、手元で最新版のリストを作成しアップロード。

1. step1.Google Search Console「リンク」から被リンクリストをダウンロード
2. step2.リスト内で否認するサイトのみを残す
3. step3.リストの各行頭に「domain:」を追加
4. step4.（2回目以降は）現在設定されているリストをリンク否認ツールページでダウンロード
5. step5.（2回目以降は）ダウンロードしたリストに新規追加ドメインを加える
6. step6.整えたリストをリンク否認ツールページでアップロード（2回目以降は「置き換える」）

サイトへのリンクを否認する（公式ヘルプ）

リンク否認ツールページ（公式）

バックアップ

失ってからでは遅い、バックアップのお話しです。

WordPressでのブログ運用をしていて感じているていことの一つに、WordPress本体以外に実装したプラグインごとにもアップデートが必要になってくる管理上の煩雑さがあるな、ということがあります。

ブログを更新のたびに、連動して変更修正が必要なメニュー部分等を手動で書き換えなくても良い、という最大の利便性と引き換えに受け入れている部分ですね。

記事ページが増えれば増えるほど、プラグインの実装数が増えれば増えるほど、つまり運用歴が長くなるほど、WordPress管理上何かしらの変更やカスタマイズを加えた際に不具合が起きるリスクは高まっていきます。

そして、トラブルを解決するとなると専門的な知識が必要になることもあり、原因を突き止めることが難しく、個人でできる解決施策には限界があります。

 

個人でできるトラブル解決のファーストステップとしては、バックアップデータを利用して、トラブルが起きる手前の状態にブログをロールバックすることが一番安心安全な解決策と言えるかな、と個人的に思っています。

WordPressでのブログ運用を前提にお話しすると、方法としては2つ。

1. プラグインによる自動バックアップ
2. 手動バックアップ

バックアップする領域としては、WordPressがインストールされている領域のみのバックアップを前提に解説していきいます。

WordPressプラグインによる自動バックアップ

WordPressのプラグインを利用する場合はWordPressのデータに関してのみのバックアップになります。（WordPress以外のデータをバックアップする場合プラグイン以外の方法でバックアップが必要になる）

私が使用しているプラグインについてです。プラグインでスケジュールを設定するので、プラグイン利用が必須の方法です。

UpdraftPlus

このブログの運用を開始したころに参加したWordPressのミーティングでたまたま居合わせた方に教えていただいて以降ずっと利用しています。

教えていただいた後は自分なりに調べ、無料版と有料版があるうち、現在無料版にて運用中です。

選定理由

1. バックアップデータの格納先を複数選択肢の中から選べる（私はGoogle driveを使用）
2. スケジュール設定さえすれば自動。DBとファイルは分けて指定OK。（「いますぐバックアップ」で手動バックアップにも対応しています）
3. 復元がボタンでできる。（プラグインならでは）
4. ダウンロード数が多く信頼できそう。

いまのところバックアップデータを利用する機会がないので、一度実際にバックアップ試してみたいと思いつつ、、、、（試す場合サイトコピーして作業環境を作って試さないとです）

手動バックアップ

プラグインにてスケジュールを設定する以外に、自分がバックアップしたいと思ったタイミングでバックアップをとる場合が手動バックアップです。

自動バックアップの場合は、サーバーの中のWordPressのデータ領域限定でのバックアップですが、手動の場合は個別にデータをバックアップすることも可能になります。

方法

1. プラグインの機能を使う。
   バックアップ可能領域：WordPressのデータ領域限定
   方法：プラグインによる。（UpdraftPlusの場合は、ボタンクリック。）
2. サーバーの機能を使う（契約しているサーバーで提供されている場合）
   バックアップ可能領域：サーバー契約領域全体。
   方法：サーバーによる。（エックスサーバーのUIだと、DBとファイルを別の場所で操作）
3. FTPソフト等でサーバーにログインし、データを個別にローカルにコピー
   バックアップ可能領：サーバー契約領域全体。
   方法：FTPでバックアップしたいフォルダかファイルをコピー。
4. テキストデータをファイルで保存
   バックアップ可能領域：WordPress記事データ、cssデータ（テキスト）
   方法：記事作成作業中に、テキスト表示部をコピーし、テキストファイルで保存しておく。

WordPress以外のデータをサーバーに置いている場合にFTPでバックアップする必要があります。

WordPressしか利用していない場合は、1か2の方法になります。

大きな変更を加える前、ですが具体的な例を挙げてみます。

1. プラグインやWordPressのアップデート前
2. プラグインで何かしらサイト全体に変更を及ぼすようなアクションをかける前
   ファイル名の一括置換など
3. サーバー以降前
4. カスタマイズ前
   phpファイルに変更を加える時など

これは結構頻繁に行いますが、WordPressの作業中にマシントラブルやブラウザの強制終了で編集中のデータを失ってしまう場合を想定してテキストモード表示でテキストを全選択し、自分のPCに保存しながら作業しています。

CSSも同様に、変更を加える前にテキストファイルに保存しておくと何かあっても保存s手置いたテキストでロールバックできて安心なので、ちょっと面倒に感じるかもしれませんがオススメです。

ワードプレステーマを変更したい（JIN→SWELL）

WordPressでブログをはじめて3年くらいたって、テーマを変更したいとなり実際新規でテーマも購入。WordPressテーマ「SWELL」

JINから「SWELL」へ変更の際に使えるプラグインがあるため、JIN特有のコードで実現していた吹き出しや囲みがグッチャリと崩れる心配はなさそうだけど、不安すぎてコピーサイトを作って検証してからにしようか、とかモヤモヤと時間だけが過ぎて行ってるのですが。。。

いい加減購入から1年近くも経つし、取り組まないといけないと、、、自分にムチを当てたところです。

事前にチェックしたこと（乗り換えサポートプラグイン注意点）

JINからSWELLへの乗り換えサポート用プラグインがあるのはすごく助かるけど、万能ではないし、事前に最低限抑えること頭に入れようと公式をチェック！

タイトル（title）、ディスクリプション（discription）に注意！

JINは、それぞれ投稿ページ内で個別に手入力できたのですが、SWELLはできないとのことで対策が必要。

乗り換えサポートプラグインを入れると挙動としては

1. 「SEO SIMPLE PACK」を導入している場合、は、プラグインを有効化している間はJINで各記事に設定していたSEO用のタイトル・ディスクリプション ・noindex設定が自動で引き継がれる（SEO SIMPLE PACKにデータが渡されるわけではない）
2. SEO SIMPLE PACKの設定ではなく、JINで設定している場合は、JINでの設定内容が出力される

ということは、私は2が当てはまっているので、サポートプラグインを無効化した後の対策も必要になるということです。

サポートプラグインを無効化した後に必要になる対策

公式から提供されているコードを子テーマのfunctions.phpに追記すればよいことがわかり一安心。ですが…

確認を進めるとその先にも注意点があり、

コードの追記＝SEO SIMPLE PACKにデータが渡されるわけではないことがわかりました。

つまり最終的には各個別ページのSEO SIMPLE PACKの設定エリアへの入力が必要になるということ

がわかりました。ふぅ。

title、discription表示に必要な一連の作業ステップ

JINでSEO SIMPLE PACK未導入で運用していた場合の、SWELL移行後のtitle、discription表示に必要な一連の作業ステップとしては

1. ひとまず乗り換えサポートプラグインで対策
2. JINでSEO SIMPLE PACKインストール
3. 子テーマにコード追記
4. 投稿記事ごとにSEO SIMPLE PACKの設定エリアへtitle,discription情報入力
5. 全記事、上記step3の入力完了後、追加したコードを削除

の流れになりそうです。（※いま情報確認段階です）

 

---

このページは備忘録的に随時更新していきます。

ここち（@kokochi_upd）でした！