サイトの改善をAIに任せるようになって、いままでで一番ひやっとしたのは、文章の間違いではありません。古い体験談のページから新しいページへの301リダイレクト(旧ページを開いた人を自動で転送する設定)が、いつの間にか作業内容に入っていたことでした。
AIの立場からすれば、内容の近いページを一つにまとめるのは合理的な提案です。ただ、私にとってあのページは、当時の体験談としてそのまま残しておきたいページでした。リダイレクトを入れると、読者が古いURLを開いても新しいページに転送されてしまい、古い本文は直接読めなくなります。
結局この変更は取り消して、旧ページを残したまま、本文の中から新しいページを案内する形にしました。この件があってから、記事の本文を直す作業と、検索からの流入を変えてしまう作業は、はっきり分けて扱うようになりました。
301の提案で気づいたこと
たしかに、古い記事と新しい記事が並んでいると、統合した方がすっきり見えます。ただ、ページ同士が似ているからといって、片方を読めなくしてよいわけではありません。旧ページには、検索以外にも、過去の体験の記録として、また外部からリンクしてもらっている先としての役割があります。
本当にページを引っ越したのであれば、301リダイレクトは正しい使い方です。ただ、残しておきたいページに使ってしまうと、「古いページはもう見せない」という判断をしたことになります。ここまで来ると文章の手直しではなく、サイトをどう運営するかの判断です。
作業が終わってから報告されるのでは遅い、というのが正直な感想でした。今は、この手の影響が大きい変更については、作業の計画に入った時点で先に説明してもらうようにしています。
今、AIに任せているサイト作業
- Search Consoleの傾向から、伸びている記事と改善候補を分ける
- 既存の記事を横断して調べ、同じ疑問に答える記事を増やしすぎないようにする
- タイトル、説明文、導入、見出し、内部リンクの改善案を作る
- 公開HTMLを合意した範囲で修正する
- 構造化データ、内部リンク、文言、Git差分を検証する
- 何を変え、何を変えなかったかを日報に残す
表示回数があるのにクリックが弱いページを探す流れは、Search Consoleでクリックされない記事を改善する手順でも紹介しています。AIに候補出しと作業は頼めますが、「今このページを変えるべきかどうか」は私が判断しています。
似ているようで役割が違う設定
| 設定 | 何が起きるか | 承認前に見ること |
|---|---|---|
| 301リダイレクト | 旧URLを開いた人も検索エンジンも新URLに移る。Googleには移転先を代表URLにする強い合図になる | 旧ページを直接読めなくしてよいか |
| canonical | 似たページの代表として希望するURLを伝える強い合図になる | 二つのページの役割は本当に同じか |
| noindex | 検索結果に出さないよう求める | 検索から外してよいか。クローラーが読める状態か |
| robots.txt | クローラーが取得できる範囲を制御する | noindexの代わりにはならない。必要なページまで読めなくならないか |
| サイトマップ | 重要だと考えるURLを検索エンジンに知らせる。代表URLを示す合図としては弱い | 新規追加か、既存URLの除外か |
Googleは、代表URLを示す方法としてリダイレクトとcanonicalを強い合図、サイトマップ掲載を弱い合図と説明しています。また、noindexはクローラーがページを取得できて初めて読まれます。詳しくはcanonicalの公式説明、robotsメタタグの公式説明を確認してください。
事前承認にしている作業
| 分野 | 承認を求める作業 |
|---|---|
| 検索流入 | リダイレクト、URL変更、canonical、noindex、robots、既存URLのサイトマップ除外、ページ統合・削除 |
| 公開 | コミット、push、PR、デプロイ、公開ボタン |
| サイト全体 | 共通CSS、テンプレート、ナビゲーション、CTAの大幅変更 |
| 外部接続 | 認証、APIキー、OAuth、Search Console設定、広告・ASP管理画面、外部サービスへのデータ送信 |
| 運用責任 | ほかの仕組みや別のサービスに影響する変更 |
タイトルや見出しの変更も、ページの主題が入れ替わるほど大きく変えるのであれば承認の対象にしています。どの項目を変えたかではなく、読者から見たページの役割や、検索からの入り口が変わるかどうかで線を引いています。
承認を求めるときの説明
「SEO的に良さそうなのでリダイレクトします」という説明だけでは、私には判断のしようがありません。今は、先にこのあたりを説明してもらうようにしています。
- 変更するURLと、変更後に残るURL
- 古いURLを読者が直接開けるか
- 古い本文は残るか、転送されるか、検索だけから外れるか
- 内部リンクとサイトマップをどう扱うか
- 検索流入にどんな影響がありそうか。分からない場合は分からないと書く
この説明を見てから決めれば、リダイレクトではなく本文からの案内リンクにする、それぞれの記事の役割を書き分けるだけにする、いったん何もしない、といった控えめな方法も選べます。
任せる範囲を狭くするのではなく、止める場所を決める
この件から学んだのは、AIにサイト運営を任せるのは危ない、という話ではありません。調査や重複の確認、下書き、修正、検証、記録には、正直かなり助けられています。問題だったのは、どこから先が経営判断なのかを、私が言葉にして伝えていなかったことでした。
承認のラインを決めてからは、AIが影響の大きい施策を思いついても、先に影響を説明したうえで止まってくれるようになりました。作業を遅くするためのルールというより、後から戻せない変更を手前で見分けるためのルールです。
