既存サイトをAIビルダーに移行する: 間違える3つの方法

毎週、誰かが実在するサイト——トラフィックがあり、被リンクがあり、数年分のGoogleの信頼を蓄積したサイト——をAIビルダーに移行したいとやって来る。ゼロからのアイデアでもプロトタイプでもなく、失うものがある既存のビジネスだ。これは白紙のプロンプトから始めるのとは別の仕事であり、私が見てきた苦労の大半は、それを同じ仕事として扱ってしまうことから生まれている。

件名を読んだだけでサポートチケットの内容を予測できるほど頻繁に発生する失敗パターンが3つある。正しいやり方は特に巧妙なものではない。この3つをやめさえすれば自然と辿り着くものだ。

失敗その1:旧コンテンツをそのまま流し込み、構造は勝手に整うだろうと期待する

その直感は理解できる。サイトがあり、そこには文章がある。だからそれをチャットに貼り付けて「これを良くして」と頼む。出てくるのは、見た目は新しいが中身は古いままのサイトだ——同じ長々とした説明文、15の役割を3つの見出しでこなす構成、それがより見栄えの良いテンプレートに包まれているだけ。ビルダーは頼まれたとおりのことをした。あなたが頼んだのは模様替えであって、考え直すことではなかったのだ。

その代償は約6週間後に表面化する。新サイトのランキングが旧サイトとまったく同じ位置、あるいはそれ以下に落ち着いてしまうのだ。実際の情報構造が何も変わっていないため、何も改善されない——本来3ページに分けるべきサービスが依然として1つのフラットなページのままだったり、競合サイトが1年前からランクインしているFAQコンテンツが依然として欠けていたりする。部屋数が間違っている家に新しいペンキを塗っても、部屋数が間違っていることに変わりはない。

11種類の異なるサービスをカバーする4,000語の「サービス」ページを持つクライアントがいた。彼女は「これまでずっとうまくいっていたから」とそのまま移行することを望んだ。だが実際にはうまくいっていなかった——すべてを一度に扱っていたせいで、何一つ特定のキーワードでランクインしていなかったのだ。忠実に移行すれば、同じ「ランクインしないページ」の見栄えの良いバージョンができるだけだっただろう。

ここで実際に機能するのは、移行を構築の前段階としての「監査」として扱うことだ。旧コンテンツを取り込みつつ、まずコンテンツインベントリを作成してもらう。どんなページが存在するか、それぞれが実際に何のキーワードでランクインしようとしているか、2つのトピックが1つのURLに詰め込まれている箇所はどこか、1つのトピックが5ページにわたって薄く分散している箇所はどこか。そのインベントリが計画になる。旧サイトはテンプレートではなく、あくまで参照元だ。

失敗その2:GoogleがそもそもURLを信頼していることを忘れる

これが最も高くつく失敗だ。旧パスと新パスをマッピングせずにURL構造を変更するサイト移行は、たとえ新しいコンテンツが本当に優れていたとしても、何年もかけて蓄積したシグナルを捨ててしまう。被リンクは404を指し示すことになる。Googleは、以前は別のアドレスで信頼していたページの信頼を、クロールし直して再度獲得しなければならない。旧ブックマークやメール署名からの直接トラフィックも行き止まりになる。

アナリティクスダッシュボードに上昇ではなく崖のようなグラフが表示されて初めて、これに気づく人たちを何度も見てきた。その時点での対処は事後的なリダイレクト追加になり、損失の一部は取り戻せてもすべては戻らない——「URLが移動した」ことと「誰かがそれに気づいて修正した」ことの間には、二度と取り戻せない数週間分の失われた資産価値がある。

これはどれも特別なことではない。ビルダーに触れる前に作る、2列のスプレッドシートにすぎない。ただ、これは退屈な作業で、構築そのものの方が楽しいという理由で省略されがちなステップなのだ。

失敗その3:戻る道のない一斉切り替え

3つ目の失敗パターンは、コンテンツやURLの話ですらない——切り替えの実際のやり方についてだ。誰かが新サイトを構築し、プレビューで見た目を気に入り、その日の午後にドメインをそちらに向けてしまう。ステージング期間もなく、実際のトラフィック下での並行比較もなく、プレビューでは検出できなかった不具合が発生した場合の計画もない——問い合わせフォームが静かに機能不全になっている、テストではうまくいくのに実際の決済ボリューム下ではチェックアウトフローがつまずく、デスクトップでは問題なく表示されるがユーザーの半数が使っている特定のスマートフォンで崩れるページ、といった具合だ。

ここでの被害は最も騒がしい種類のものだ。なぜなら即座に発生するからだ。サポートの受信箱がいっぱいになる。誰かが10分おきにアナリティクスを更新し、グラフが悪い方向に動くのを見つめている。そしてロールバックとは、再びDNSを向け直すことを意味し、それ自体が反映されるまでに時間がかかる。つまり、元に戻すと決めた後でも、悪い体験は続いてしまうということだ。

解決策は地味なものだ。切り替えの1〜2日前にDNSのTTLを下げておき、必要になった場合にロールバックが素早く反映されるようにする。まずプレビューやステージング用のサブドメインで新サイトを稼働させ、実際に顧客がそうするように使ってみる。そして、新サイトが立ち上がった瞬間に旧サイトを撤去するのではなく、切り替え後少なくとも数週間は旧サイトのホスティングを稼働させたまま、手を加えずに残しておく。この最後の部分は、わずかなホスティング費用で得られる本物の保険だ。人々がこれを省略するのは、旧プランを解約することが区切りをつけるように感じられ、区切りをつけることが進歩のように感じられるからだ。

正しいやり方とは実際どのようなものか

まとめると、これらはどれも間違ったやり方より作業量が多いわけではない——同じ量の作業を、異なる順序で行うだけだ。再構築の前に監査する。公開の前にURLをマッピングする。切り替えの前にステージングし、切り替え後も数週間は戻る道を残しておく。こうして出来上がるサイトは、単に新しく見えるだけではない。旧サイトがすでに獲得していたものすべてを引き継ぐ。それこそが、ゼロから作り直すのではなく移行することの全ての意味だったのだ。