記事を増やす前に、検索で表示される題名と相談の入口を整える

編集部記事の本数を増やす前に、何を調べたのでしょうか。

くるみ｜支援内容から編集

まずどの検索語からどのページへ人が来ているかを照合しました。すでに表示されているページがあるなら、その説明や検索結果での見え方に改善の余地があるかを先に確かめる必要があったためです。Search Consoleで検索語、表示回数、クリック、順位を確認し、既存ページがどの疑問に応えているかを整理しました。記事数を目標に置く前に、検索で見つかっている情報をどう活かすかを判断しました。

クリック率の低さを題名だけの問題とは決めませんでした。順位、端末、検索結果内で回答が完結することなど、複数の要因が考えられたためです。自社サイトの表示実績を市場全体の検索回数として使わず、変更後も同じ検索語・順位帯・端末で比較する方針を整理しました。観測した差と、まだ検証が必要な原因を分けたうえで、修正する順序を決めました。

編集部同じテーマの記事が複数ある場合は、まとめたほうがよいのでしょうか。

くるみ｜支援内容から編集

既存ページを残し、答える疑問を分ける方針にしました。似た言葉で検索されていても、選択肢を知りたい人、方法や費用を比べたい人、利用後のことを知りたい人では必要な説明が違ったためです。検索語と実際の流入先から役割を整理し、詳しく説明するページと、要点を示して案内するページを分ける案を作りました。複数ページが表示されるだけで競合と決めず、すでに読まれている記事の役割を活かす提案でした。

編集部実際に公開ページでは、どこを直したのでしょうか。

くるみ｜支援内容から編集

記事ページの題名を、その記事の内容が分かる表示へ修正しました。異なる記事に共通の題名が使われていると、検索や共有された画面で何の記事かを判断しにくいためです。記事用テンプレートを修正し、通常のtitleと、SNS共有で使う題名を記事名に合わせました。保存後は対象記事を照合し、一覧と代表ページの表示も確認しました。原稿を増やす仕事に加えて、すでにある記事が内容に合った題名で伝わる状態を整えました。

編集部題名のほかに、検索向けの情報は何を確認しましたか。

くるみ｜支援内容から編集

各記事を参照するURLと、記事情報の整合も確認しました。画面の題名を直しても、参照先や記事名・公開日の情報が食い違っていれば、記事を一貫して案内できないためです。記事自身を示す正本URL、主見出し、パンくず、記事名と公開日を表す構造化データを修正し、公開画面と照合しました。人が読む内容と、ページが機械向けに伝える情報をそろえる作業まで担当しました。

サイトマップも、送信しただけで確認を終えませんでした。掲載対象の記事が漏れずに入っているかと、検索側で正常に処理されたかは別の確認だからです。自動生成のサイトマップに含まれる記事と公開記事を照合し、Search Consoleで処理状態を確認しました。記事を見つけるための情報は整備しましたが、全記事の検索登録やリッチリザルト表示を獲得したとは扱っていません。

編集部既存サイトの仕組みを、大きく作り直したのでしょうか。

くるみ｜支援内容から編集

既存の制作基盤を使い、対象を絞って変更しました。記事部分と共通部分で管理方法や担当が違い、まとめて替えると影響範囲を確認しにくかったためです。記事用のテンプレートを検証してから反映し、本文・既存リンク・既存の処理を保持しました。管理する経路が異なる共通部分や、個別の説明文・画像の修正は残作業として分けました。直せた箇所と、別の担当・確認が必要な箇所を区別して進めました。

編集部反映後の数字は、どのように評価しようとしたのでしょうか。

くるみ｜支援内容から編集

技術修正後の確認と、次の本文改稿を分ける方針にしました。複数の変更を同時に進めると、数字の差をどの変更と結び付けて考えるかが曖昧になるためです。変更記事をURLで追跡し、旧形式と通常形式のURLを同じ記事として扱う確認方法を整理しました。当日途中の数字と、過去の終日集計も直接比べない条件にしました。公開直後の表示確認と、集計後の流入評価を分け、遅れているデータで成功・失敗を決めない進め方にしました。

編集部検索から先の、相談や予約はどこまで追うのでしょうか。

くるみ｜支援内容から編集

相談の入口は、ページと経路を分けて確認する条件を整理しました。記事が読まれていても、どの案内から次へ進んだかが分からなければ、導線を改善する場所を決めにくいためです。電話、メッセージ、予約フォームなどの入口を区別し、クリック元のページと合わせて確認する方法を整理しました。記事の閲覧だけで終わらず、相談へ進む入口まで改善対象に含めました。

入口のクリックと、実際の問い合わせ・予約は別に扱いました。ボタンを押したあとに受付や予約が完了したとは限らないためです。未取得の値をゼロで埋めず、取得済みで発生がなかった場合と分け、実予約の件数は別の記録で確認する条件を残しました。計測できる入口と、まだ確かめる必要がある事業上の結果を区別した支援です。