SEOリライトの進め方｜改善する記事の選び方と見直すポイント

どの記事を直すかを先に決める

候補は、主力サービスに関係する記事、情報が古くなった記事、表示されているのに内容が検索語句に合っていない記事などです。データの増減だけでなく、事業上の重要度と修正の必要性を並べて判断します。

たとえば、利用終了したサービスの手順が残っている記事は、アクセスが少なくても修正の優先度が高いと考えられます。一方、公開直後でデータが少ない記事は、すぐに全面変更するより、誤りや不足がないかを確認してから推移を見る選択肢があります。

関連する解説：検索意図とは？読者が求める内容を記事に反映する方法

関連する解説：SEOを意識した記事タイトルの付け方｜改善例と注意点

関連する解説：テクニカルSEOの点検｜検索に表示されないときの確認手順

文章表現より先に、回答の不足を直す

リライトでは「結論」「根拠」「条件」「行動」の順で点検する方法を提案します。言い回しを整える前に、読者が知りたい答えが本当にあるかを確かめます。

たとえば、問い合わせフォーム改善の記事に「入力項目を減らしましょう」とだけ書かれている場合、なぜ必要か、削れない項目をどう扱うか、変更後に何を確認するかを補います。単純に短くするのではなく、判断できる説明を増やす作業です。入力項目を減らせば必ず成果が上がる、と断定しないことも重要です。

• 結論：記事の中心の質問に、明確な答えがあるか。
• 根拠：数値・仕様・制度の出典と確認時点が示されているか。
• 条件：対象外のケースや前提条件が抜けていないか。
• 行動：読者が次に何をすればよいか、具体的か。

参考：Google：有用で信頼性の高いコンテンツ

変更履歴と比較条件をそろえる

修正前に、記事の内容、対象キーワード、主要な数値を保存します。修正後は、リンクや表示、フォームの動作を確認し、変更日と内容を記録します。複数の修正を行った場合も、どこを変えたかわかるように残します。

効果を見るときは、同じ長さの期間を比較し、季節性やキャンペーンなど別の要因も考えます。変化と修正が同じ時期に起きても、それだけで因果関係は確定しません。「何が変わったか」と「なぜ変わったと考えるか」を分けて記録すると、次の改善に使えます。

参考：Google：検索パフォーマンスレポート

修正候補を、症状ごとに分類する

リライト候補は、流入が減った記事だけではありません。よく読まれているのに相談につながらない記事、古い条件が残る記事、営業で何度も補足している記事も対象です。症状を分けると、文章を増やすべきか、タイトルを直すべきか、導線を見直すべきかを考えやすくなります。

表示回数が減った場合は、検索需要や掲載状況を先に確かめます。表示はあるがクリックが少ないなら、検索語句とタイトルの関係を見ます。記事を読んだ人が次のページへ進まないなら、本文の回答とリンクの案内を見ます。同じクリック減少でも原因の仮説が違うため、すべての記事を同じ手順で書き直さないようにします。

作業表には症状、対象URL、比較期間、想定読者、原因の仮説、確認方法を書きます。推測を事実のように扱わないための記録です。原因が複数ありそうなときは、明確な誤情報やリンク切れから直し、その後に内容の改善を進めます。緊急の不具合と長期の内容改善を分けると、担当者間の優先順位も揃います。

変更前に残すデータと文章

変更前の本文、タイトル、見出し、内部リンク、画像を保存します。加えて、Search Consoleの検索語句とページ別の傾向、問い合わせ内容、社内で把握している問題を記録します。画面の写真だけでは、後から細かな文言の違いを確かめにくいため、文章自体も残しておきます。

数値を比較する期間は、修正の直前だけでなく、季節や営業日の違いも考えて選びます。法人サービスなら休暇期間や繁忙期が影響する場合があります。一つの期間で結論を出すのではなく、条件の近い期間でも傾向が同じかを確認します。比較の目的と限界を報告に残すと、社内で数字を過大評価しにくくなります。

計測設定が変わっている場合は、その日付も記録します。フォームのイベントを増やした後に問い合わせ件数が伸びたように見えても、実際には集計方法が変わった可能性があります。記事の修正と計測の変更が重なったときは、営業の受付記録など別の情報でも確かめます。

本文を増やす前に、回答の順番を直す

読者の質問に対する答えが後半にあるなら、冒頭へ移すだけでも読みやすくなる場合があります。主題と関係の薄い説明が長いなら、関連記事へ分けます。文字数を増やすことだけを改善と考えると、必要な条件が埋もれます。最初に結論と適用条件を示し、理由や具体例を続ける構成を検討します。

実例を追加するときは、架空のケースか実際の事例かを明記します。実際の成果なら、期間、対象、集計方法、同時に行った施策を説明します。数字を載せられない場合も、どの資料を確認し、なぜその判断をしたかを説明できます。読者が手順を自社へ置き換えられることを重視します。

不要な箇所を削ったら、別の章から参照していないかを確認します。古い説明へリンクする関連記事も点検します。リライトは一ページの文章の作業に見えますが、サービス条件や記事の関係を更新する作業でもあります。公開画面と関連するページまで確認して完了とします。

結果が伸びないときの次の判断

公開後に変化が小さくても、すぐ元へ戻すのではなく、検索への反映、需要の変化、計測の状態を確かめます。読者の反応が十分に集まっていない段階で変更を重ねると、何が問題だったかを振り返れません。確認する期間は固定の日数で決めず、流入量と事業の検討期間に合わせます。

問い合わせの質が上がった一方で閲覧数が減った場合は、記事の目的に沿って評価します。対象外の読者を減らすために条件を明記した結果なら、アクセスの減少だけで失敗とは言えません。反対に、閲覧数だけが増えても相談が対象外なら、読者設定やタイトルの広さを見直します。

次の修正は、最初の仮説が否定されたのか、修正が足りなかったのか、別の要因が強かったのかを分けて決めます。担当者が変更履歴を共有していれば、同じ修正を繰り返すことも防げます。リライトを一度の納品で終えず、確認と改善を続ける運用へ組み込みましょう。

着手前に作る確認シート

既存記事の更新を始める際は、最初に「今回変えたい状態」を一文で書きます。「成果を上げる」だけでは、作業の終わりを決められません。公開済みで説明が古いページについて、現在わかっていること、まだ判断できないこと、担当者に確かめることを分けます。目的が揃っていれば、途中で別の改善案が出たときも、今回の範囲へ含めるかを判断しやすくなります。

確認シートには、対象、目的、根拠、作業、確認者、再確認する日を設けます。根拠の欄には現在のサービス条件と検索データの所在を書き、作業の欄には具体的に変更する部分を記載します。資料の名称だけでなく、どの期間、どのページ、どの条件を見たかも残します。別の担当者が同じ資料を開いた際に、今回の判断を追えることが目的です。

次に、更新する理由と残す情報を点検します。説明の不足と計測の不足を一緒に扱うと、何を直せば確認できるのかが曖昧になります。内容に関する作業は編集担当、設定に関する作業は制作や運用担当に分けても、確認の表は共通にします。部署ごとに別の前提で話が進まないよう、変更した条件を一つの場所に残しましょう。

この段階でアクセスが少ない記事をすぐ削除することを避けます。すぐに変更できる部分が見つかっても、原因の仮説と対応するかを考えます。作業のしやすさだけで優先順位を決めると、目立つ箇所は直っても相談や運用の問題が残る場合があります。事実の修正と構成の変更を分けるという方針を、確認シートの冒頭へ記載しておくと、判断がぶれにくくなります。

具体例：社内で判断を揃える進め方

以下は、手順を理解するための架空の例です。法人向けサービスを提供する会社で、公開済みで説明が古いページを見直すことになったとします。営業担当は相談の内容を、運用担当は閲覧や配信のデータを、制作担当は現在の表示や設定を持ち寄ります。実際の企業や成果を示す事例ではなく、役割を分けて確認するための例として読んでください。

最初の会議では、各担当の資料をそのまま比較せず、対象期間と対象の範囲を揃えます。営業が見ているのは契約した案件だけ、運用が見ているのは全体のアクセスだけ、という状態では同じ話ができません。現在のサービス条件と検索データから今回の対象に関係する部分を選び、わからない情報は未確認として残します。数字を合わせるために推定値を足す必要はありません。

そのうえで、現在のページで答えられる疑問が明確かを議題にします。営業の感覚も、画面上の数字も、どちらか一方で結論を決めません。たとえば対象外の相談が増えたという意見があれば、相談の分類方法と該当する説明を確認します。計測できない部分があれば、まず記録の仕方を決めます。改善案は、確認できた問題と対応する形で書き出します。

作業を始める前に、以前の情報と変更理由を保存することを担当者同士で確認します。担当と期日が曖昧だと、本文を直しても関連する案内が古いまま残るなど、変更が途中で止まります。公開や配信へ進む担当、内容を確認する担当、結果を見る担当を決め、引き継ぎに必要な資料を添えます。個人の記憶だけに頼らないための整理です。

終了の判断は、作業が済んだかと、目的に近づいたかを分けます。文章や設定を更新できたことは作業の完了です。相談の質や運用の負担が変わったかは、一定の期間を置いて確認します。結果が出る前に成功と扱うことも、短期の変化だけで失敗と扱うことも避け、次に確認する条件を残します。

公開・運用後の確認と次の改善

変更後は、更新前後の対象検索語を確認することから始めます。確認する日を決めずに毎日数字を眺めても、比較の条件は揃いません。対象期間、曜日や季節、ほかの施策の変更があるかを記録します。特に複数の担当が同時に改善を行う場合は、どこがいつ変わったかがわからないと、結果の説明が難しくなります。

改善の前後には、対象全体の合計と、個別の内訳を両方見ます。全体が増えていても、重要な対象では変化していないことがあります。逆に合計が大きく変わらなくても、依頼に近い情報へ進む人が増える場合があります。公開済みで説明が古いページを中心に見るという最初の方針へ戻り、目的に関係する変化を整理します。

想定と違う結果になったときは、すぐに元へ戻す前に、仮説と観察を分けます。「説明が不足している」は仮説であり、「同じ質問が相談で繰り返された」は観察です。観察したことを具体的に残せば、別の担当者にも検討できます。更新する理由と残す情報について、最初に揃えた条件が途中で変わっていないかを確認することも必要です。

次の改善は、情報が足りない部分を埋める作業と、効果を確かめる作業を分けます。前者は資料や説明を揃えることで完了を確認できます。後者は、期間や対象を決めて比較します。すべてを同じ期限で評価する必要はありません。事実の修正と構成の変更を分けるという基本へ戻り、今回の結果から何がわかったか、何が残ったかを短い文章にまとめましょう。

よくある質問

最初にどこから着手すればよいですか？
公開済みで説明が古いページのうち、事業への影響が大きく、根拠を確認できる対象を選びます。現在のサービス条件と検索データを集め、未確認の条件を分けてから変更します。全体を同時に見直すより、担当者が確認できる範囲を決め、終了後に別の対象へ広げる進め方が現実的です。

担当者が少ない場合はどう進めますか？
更新する理由と残す情報について、情報を確認する人と作業する人を決めます。同じ人が担当する場合でも、編集と確認の時間を分けると誤りに気づきやすくなります。以前の情報と変更理由を保存するための資料を一つにまとめ、更新のたびに新しい書類を増やしすぎないようにします。

成果はどのように判断しますか？
更新前後の対象検索語を確認することを基本にします。変化が見られても、ほかの施策や時期による影響を除けるとは限りません。現在のページで答えられる疑問が明確かも確認し、結果から言えることと、追加の確認が必要なことを分けて報告します。作業の完了だけで成果を断定しません。