リニューアルを予定していますか？この記事を見つけたことをおめでとうございます。以下の説明は、リニューアルが成功するための決定的な貢献になるかもしれません。成功するとは限りません。私はエージェントオーナーであり、あなたが私のようなタイプを非常に良い仕事をすることやリニューアルでの一般的な失敗を避けることに追い込むために必要なポジションに配置するものを正確に教えます。しかし、最初から始めましょう。
目次
ウェブサイトのリニューアルとは、既存のウェブサイトの再デザインおよび改訂のことです。デザイン、コンテンツ、および技術のいずれか、またはそれらすべてを変更できます。ウェブサイトのリニューアルの目標は、ウェブサイトを改善し、現在の要件に合わせることです。
ある企業では、特定の外部トリガーが「リニューアル」という目標を設定します。新しく雇われた従業員が素晴らしいアイデアを持ち帰り、新しいボスがデジタルをきちんと整理したい、競合他社が新しいウェブサイトを持っている、売上が下がっているなどがその理由です。もしかしたらボスの妻は古いサイトが気に入らないかもしれませんし、Z世代にとってウェブサイトが「lit」（流行っている）でないかもしれません。おそらくそんなことは知っているでしょう。ウェブサイトを新しくする必要があるというのは個人的意見と同様、リニューアルの理由ではありません。
ただし、企業や組織がウェブサイトのリニューアルを行いたいと考えるいくつかの優れた理由があります。主な理由は次のとおりです：
- 古いデザインと/またはリブランディング：古いウェブサイトは企業が時代遅れであるか、活動していないように見える可能性があります。新しい、モダンなデザインはイメージを向上させることができます。ブランドのイメージや企業アイデンティティが変わる場合、新しいブランドメッセージを反映させるためにウェブサイトのリニューアルが望まれることがあります。
- 優れたユーザーエクスペリエンス：ウェブサイトの使い勝手が悪いと、離脱率が高くなる場合があります。リニューアルにより、ユーザーエクスペリエンスを向上させ、ウェブサイトをより使いやすくすることができます。
- モバイル対応：モバイルデバイスを使用してウェブサイトにアクセスする人が増えているため、ウェブサイトがさまざまな画面サイズとデバイスで正常に機能することが重要です。
- 検索エンジン最適化（SEO）：古いウェブサイトはSEOパフォーマンスに問題を抱えることがあります。リニューアルは、検索エンジンでの可視性を向上させるためにSEOに寄与する変更を加える機会を提供します。
- コンテンツの更新：企業の情報、サービス、または製品が変わると、その変更を反映するためにウェブサイトを更新する必要があります。
- セキュリティ向上：古いウェブサイトはよりセキュリティリスクにさらされやすいです。リニューアルにより、ウェブサイトのセキュリティを向上させ、サイバー攻撃から保護することができます。
- 技術的アップデート：時代遅れの技術を使用することがウェブサイトのパフォーマンスに影響を与えることがあります。リニューアルは、最新のWebテクノロジーやプラットフォームに移行する機会を提供できます。
- バリアフリー：多くのウェブサイトにとって、バリアフリー性の向上は重要な関心事であり、障害を持つ人々にとって使いやすい状態に保つことが重要です。
- 競争力：競合他社に対抗するためには、モダンで高性能なウェブサイトを持つことが重要です。リニューアルは、競争力を維持または向上させるために役立つことがあります。
- 分析の改善：より良い分析ツールの導入とデータ収集を通じて、企業はウェブサイトのパフォーマンスをより良く理解し、最適化できるようになります。
- 法的要件とのコンプライアンス：プライバシー、バリアフリー性、セキュリティに関する法律や規制は定期的に変わります。ウェブサイトがこれらの要件を満たしていることを確実にするためには、リニューアルが必要となる場合があります。
これらの理由は、企業の目標やニーズに応じて個別にまたは組み合わせて発生し、異なります。ウェブサイトのリニューアルは、しばしばオンラインプレゼンスを向上させ、企業の目標を達成する戦略的な決定です。上記のポイントを個別に見てみると、ほとんどの理由が小規模なスプリントで実現可能であり、大規模なリニューアルは必要ないことが明らかになります。
従って、リニューアルとは何か、何であるかを区別しましょう。既存の技術基盤を活用した新しいデザインはむしろフェイスリフティングです。リニューアルが起こるのは、リニューアルの目的がユーザーエクスペリエンス、機能、および技術ベースでの実質的な変化をもたらす場合です。
リニューアルは常に事実（たとえば、技術が行き詰まってアップデートできない）やデータ、比較データによって正当化されるべきです。
ここで私がしたい最初の推奨事項は次のとおりです：前進は革命よりも優先されます！リニューアルは可能な限り避け、これまでにリニューアルのために提案されたすべてのポイントを個別または徐々に実装しようと努力してください。1つの問題を改善して、実施し、何が起こるかを評価し、再び調整するか、次のポイントに取り組んでください。最も有名な例は、大きなリニューアル変更をしないAmazonです。
リニューアルはGoogleでの可視性にとって常に大きなリスクです。改善が注目されていますが、リスクについてはほとんど誰もが考えていません。もちろん、ユーザーインターフェイスがより良くなり、ポジティブなユーザーエクスペリエンスが向上し、技術的には最新になります。しかし、あなたの組織の成功が強力なオーガニックの可視性に依存している場合、リニューアルは最後の手段であり、上記の理由の組み合わせにより、個々のスプリントでは解決できなくなったときにのみ決定する必要があります。なぜなら、ここでこの4つのウェブサイトのリニューアル後のオンライン可視性について見てみてください：
慎重に再起動を計画し、チェックリストで成功を確実にしましょう。特に、オンラインの可視性を維持することおよび再起動の過程でオンライン可視性の向上を目指す2つの目標を設定してください。そのためにこの記事があり、再起動の手引きを提供し、再起動時のリスクを最小限に抑え、持続的で有機的なSEOの成功をもたらす可能性のある非常に良い作業結果を確実に取得できるようにします。
再起動のスケジュール
ウェブサイトの再起動の計画は注意深く行われるべきです。以下の手順を考慮することが重要です:
- 既存のウェブサイトの分析と現状の記録: まず、既存のウェブサイトを分析し、強みと弱みを特定する必要があります。
- 目標の設定: ウェブサイトの再起動の目標は明確に定義されるべきです。これには、コンバージョン率の向上、訪問者数の増加、または改善されたコンテンツの管理と保守のために新しいCMSへの切り替えなどが含まれます。
- コンセプトの開発: 分析と目標、競合他社の分析に基づいて、ウェブサイトの再起動のためのコンセプトを開発する必要があります。コンセプトには以下の要素が含まれるべきです:デザイン、コンテンツ、テクノロジー、およびSEO / マーケティング。
- 実行: そのコンセプトを実行します。これにはデザインの開発、コンテンツの作成/調整、および技術的変更の実施が含まれます。
- テスト: 新しいウェブサイトは公開前に十分にテストされ、正常に機能することを確認する必要があります。明確なチェックリストも含まれます。
- 公開: 新しいウェブサイトが公開されます。そして、引き続きライブでテストが行われ、評価され、調整されます。
再起動の目標と戦略の決定
再起動の目標を明確にしましょう。目標には次のようなものがあります(上記の理由に加えて):
- ユーザーエクスペリエンスの向上
- 使いやすさの向上
- コンテンツオファーの拡充
- デザインの近代化
- 売上高およびカートの金額の増加
- コンテンツの管理や技術的保守が容易な他のCMSへの切り替え
- 将来的な拡張可能性と更新可能性の確保。
提案: チームとして会社内で最初のキックオフミーティングの後に、実行する代理店との話し合いをする前に、すべてのプロジェクト関係者が再起動の目標をメモに書いたり、コミュニケーションツール(たとえばSlack)の入力欄に入力したりする必要があります。その後、すべてが同時に目標を提示した場合、すでにミーティングで口頭で話し合ったはずの目標にもかかわらず、考え方がどれほど異なるかに驚くでしょう。そのため、目標を書面で確認することが重要です。目標を正確に把握すると、早い段階でUIプロトタイプでその目標が概念的に考慮されているかを確認することができます。
ラストパッケージが再起動の指示を明確にします
代理店は顧客からの詳細なプロジェクト概要を提供してもらう必要があります。 企業は通常、プロジェクトの概要(より詳細または詳細でない)がスケッチされているWordドキュメントやPDFを用意しています。質問票が配布されることもあり、代理店は顧客の痛点をより明確にするためにワークショップを実施します。より大規模なプロジェクトでは、ラストパッケージが作成されます。 できるだけ詳細にするほど良いです。
ラストパッケージは、ウェブサイトの再起動において重要な役割を果たす文書です。これは、再起動に関する要求事項、目標、期待を文書化するために使用されます。よく練られたラストパッケージは、開発チーム、デザインチーム、または顧客など、再起動中に達成すべきことについて明確な理解を得るのに役立ちます。 また、実行代理店による確定申込の目基となります。ウェブサイトの再起動のラストパッケージに通常含まれる情報や要素は次のとおりです。
- 目標と目的: リローンチの主な目標の説明, たとえば, ユーザーエクスペリエンスの向上、検索エンジンでの可視性の向上、またはCMSの変更とデザインの更新。
- プロジェクトの範囲: リローンチの範囲とそれに含まれるものと含まれないものの明確な定義。これには、ページ数、サードパーティソリューションの統合、コンテンツの見直じなどが含まれることが含まれる。
- デザイン要件: ウェブサイトの視覚的な設計への要求事項に関する情報, レイアウトやカラー、フォント、画像に関する会社のデザインガイドラインの遵守。
- 機能要件: ウェブサイト上での望ましい機能や相互作用の詳細, 例えば、お問い合わせフォーム、検索機能、Eコマース機能など。
- 技術要件: リローンチ中に使用するテクノロジーの仕様, 例えば、コンテンツ管理システム(CMS)の選択や特定の機能の実装。また、最新の画像やグラフィック形式(WebP、AVIF、SVG)の使用も含まれます。
- コンテンツの編集のマニュアルと自動バックアップとリビジョン。
- コンテンツの要件: テキスト、画像、動画、その他メディアの見直し、更新、または新規作成、メタデータの取り扱いや構造化データの扱いに関する明確な基準。
- SEO要件: 次の内容もって詳細。
- スケジュールとマイルストーン: リロンチの計画された開始および完了日、また重要なマイルストーンを定義したスケジュール。
- 予算: リロンチのための予算に関する情報, デザイン、開発、ホスティング、および必要に応じてサードパーティサービスのコストについて。
- テストツールによる品質管理: ウェブサイトが正常に機能することを保証するために行われる、リローンチ中のテストと品質管理手順の説明。
- リロンチ後の継続的な保守およびサポートに対する要件。
よく構造化された仕様書は、誤解を避け、プロジェクトを効率的に管理し、すべての利害関係者の期待を満たすために非常に重要です。プロジェクトチーム全体のガイドラインおよび参照文書として機能し、Webサイトの再構築の成功を確保するのに役立ちます。
私たちがCodIgniterからLaravelにフレームワークを完全に切り替えてTutKit.comの再起動を計画している際、仕様書は220ページに及びました - これを進めるエージェンシーにとって（魅力的な）見通しではありませんでした。
注：私の記事では、概念、デザイン、機能、および使用されている技術について詳細には触れません。新しいウェブサイトはきっと素敵になります。再起動時の最大の危険は、301リダイレクトの不足などによって技術的なユーザーエクスペリエンスの悪化やオンページ品質の低下が実際に発生し、それが順位やサイトの可視性の低下につながることです。これを防ぐために、以下では特にユーザーエクスペリエンスとSEOの観点からプロジェクト成功を確保するための焦点を当てます。
新しいウェブサイトのSEO要件の定義
お客様側のブリーフィングまたはより詳細な仕様書は、デザイン、コンテンツ、機能、および技術的な要件がすでに規定されており、エージェンシーが見積もりを出すための基盤になります。
SEOの観点からは、再起動の成功を確保するための再起動チェックリストに各セクションを見ていく必要があります。たとえば、次のような理由で特別なSEO要件が生じます:
- 変化するURL構造（URLリダイレクトマップ！）および変わるリンクパス
- 変化するナビゲーション（内部リンクとリンク階層が重要なため）
- 変化する技術（CMS、JavaScriptフレームワーク、サーバー、...）
- 変化するコンテンツ（ランキングの良いページの視認性が低下するかもしれない）
ページがGoogleでランク付けされる主な理由は、コンテンツの関連性によりますので、既存のコンテンツが変更されるか、統合されるか、コンテンツが削除されるか、新しいコンテンツが追加されるかを考えることが重要です。カテゴリやページのコンテンツ構造が変化するでしょうか？これらの点から、再起動チェックリストに組み込むべきSEO要件が導かれなければなりません。
古いコンテンツのメタデータは引き継がれるのか、変更されるのか？編集者によるコンテンツ管理はどのように行われ、ページのコンテンツは構造化データとリンクされていますか？
既存のまたは新しい画像は、Webサイト用の現代的な画像形式（WebP/Avif）で保存され、画像のSEOに気を配っていますか？つまり、1234.jpgではなくhotel-ostsee-warnemuende_suite-nachtigall.avifのように、小文字のわかりやすいURLを使用していますか？
さらに、構造化データを持つ画像ファイル（ImageObject）およびGoogleに送信される<meta>-サムネイルも考慮し、Google画像のスニペットに画像を埋め込む可能性やGoogle画像でリストアップされる確率を高めます。
再起動時にCMSを変更することは通常、URL構造とリンクパスの変更をもたらします。SEOの観点からは、これが逆効果となり、慎重に考えるべきです。
興味深いのは、ユーザーシグナルを向上させる方法です。コンテンツページに画像や説明動画、ヘルプ動画を埋め込むことでしょう。Googleからランディングページにアクセスしたユーザーがビデオをクリックして視聴すると、滞在時間が延び（良いユーザーシグナル）、検索結果への再訪率も向上します（良いユーザーシグナル）。
また、Googleの要件に適合するHelpful ContentおよびE-A-T原則に対応するコンテンツセクションをサイトに組み込む方法を検討することも重要です。
Googleにとって「Helpful Content」とは、ユーザーにとって関連性の高く役立つコンテンツであり、ユーザーの質問に包括的かつ有益に答え、問題の解決策を提供し、単なる広告メッセージ以上の価値を提供します。
以下はヘルプフルコンテンツの例です:
- チュートリアルとガイド: これらのコンテンツはユーザーが新しいタスクを学ぶか、既存の問題を解決するのに役立ちます。
- レビューと比較: これらのコンテンツは、ユーザーが適切な製品やサービスを選択するのに役立ちます。
- ニュースと更新情報: これらのコンテンツは、ユーザーに最新のイベントやトレンドに関する情報を提供します。
- インフォグラフィックスと図: これらのコンテンツは複雑なデータや情報を視覚的に表現するのに役立ちます。
- ブログ記事と記事: これらのコンテンツは特定のトピックについてより深く掘り下げるものです。
Googleは、ヘルプフルコンテンツを識別するためにさまざまなシグナルを使用します。これには、次のようなものが含まれます:
- ユーザーの行動: Googleは、ユーザーがコンテンツとどのように対話するか（ページにどれだけの時間滞在するか、何度共有するか、何度評価するかなど）を見ています。
- 品質シグナル: Googleは、関連性、完全性、最新性などの要因に基づいてコンテンツの品質を評価します。
- ユーザーのフィードバック: Googleは、評価やコメントなどのユーザーのフィードバックも考慮します。
- ウェブサイト運営者がこれらのシグナルに注意を払うことで、自分のコンテンツが有益と評価される可能性を高めることができます。
EEAT原則は、Googleが開発した、ウェブサイトとコンテンツの品質を評価するコンセプトです。Expertise（専門知識）、Experience（経験）、Authority（権威）、Trustworthiness（信頼性）を表しており、Expertise（専門知識）、Erfahrung（経験）、Autorität（権威）、Vertrauenswürdigkeit（信頼性）です。
- 専門性は、コンテンツを作成する人々の知識と経験に関連します。Googleは、教育、職務経験、受賞歴などの要素に基づいて専門性を評価します。
- 経験は、コンテンツが一定の経験に基づいて作成されたことを証明します。たとえば、製品の実際の使用に基づいて作成されたり、特定の場所を実際に訪れたり、人が経験を説明したりすることです。
- 権威とは、ウェブサイトやウェブコンテンツの評判や信頼性のことです。Googleは、バックリンク、ソーシャルメディアの活動、ユーザーレビューなどの要素に基づいて権威を評価します。
- 信頼性は、ウェブサイトやウェブコンテンツの信頼性と信頼性を指します。Googleは、プライバシー、セキュリティ、透明性などの要素に基づいて信頼性を評価します。
既存および新しい機能におけるフロントエンドとバックエンドにおけるSEO要件は何ですか？ ここでは以下の点について詳しく説明します:
- 巡回可能性（関連コンテンツはJavaScriptなしでも表示および巡回可能である必要があります）
- ウェブサイトの目的とCall-to-Actionの明確さ（ページの目的の顕著化）
- 重複コンテンツの回避、たとえば自動生成されたカテゴリページやバリアント製品によるページの重複
- 高いページスピードの確保、JavaScriptおよびCSSファイルの過剰な使用の回避、近代的な画像フォーマット（WebP/AVIF）の活用
これらのSEO要件はプロジェクトブリーフィングや仕様書に含まれていますが、プロジェクトの品質保証には、テストツールに関連するチェックリストやプロジェクトの現状と目標の比較なども含まれるべきです。また、代理店の業績の受領基準としても含まれるべきです。以下に詳細を示します。
内部および外部のプロジェクト関係者の決定
プロジェクト関係者を決定します - ここでは、顧客またはウェブサイト所有者の視点から:
- プロジェクト管理を責任を負う人間と最終的な決定を下しますか？
- 代理店またはクライアントとの調整とコミュニケーションを担当するのは誰ですか？
- 内部のプロジェクト管理を誰が行いますか？
- 代理店のためにコンテンツやサポートを内部で準備するのは誰ですか？
- ユーザーエクスペリエンスデザインを実施するのは誰ですか？
- 開発を担当するのは誰ですか？
- 何を定期的な間隔で代理店からクライアントに報告しますか？
- 代理店またはクライアント側のテストと品質保証を誰が担当しますか？
- 外部のコンサルタントを追加しますか（たとえば、SEOまたは法的要件のために）？
- タスクを承認するのは誰ですか？処理後にチケットシステムでタスクを確認するのは誰ですか？
- どのタイミングで誰に情報提供する必要がありますか（従業員、顧客、パートナー、広告キャンペーン担当者、…）？
外部プロジェクト管理者を選択する際の4つの重要なポイント
- そのようなプロジェクトを既に数多く実施しているAgentur （代理店）はありますか？参照証拠はありますか？ そして、大規模な個別開発の場合には、顧客とAgentur（代理店）の間でのフィードバック対話は可能でしょうか？
- 提案および技術実現（CMS/ショップシステム/フレームワーク）により、リニューアルに関連するすべての要件がすでにネイティブで満たされていますか？追加でプログラムされる必要のある個別機能や要件がありますか（プラグインやモジュールを介して）？オファーから除外された、または後で重要なプロジェクト成功に不可欠なサービスに付記されたものがありますか？再設計の実際の理由よりも大きな新しい問題が発生しないように注意することが重要です。
- 実施エージェンシーまたはサービスプロバイダーは、チームの規模、地理的位置、および（Kununuのレビューによって判別可能な）スタッフの定着率の面で、企業に持続的に適していますか？
- 実際のデザインおよび開発チームとの直接のコンタクトは可能ですか？エージェンシー側のプロジェクトチームを実際に知ることが賢明です。元気な営業プロフェッショナルが受注し、後で担当しなくなることがあります。そのため、実行チームとの直接の接触も同意されているはずです。
この点において自己確保のための4つのヒント
- クライアントとして、あなたはエージェンシーの使用する技術に注意を払うべきです。提案されているものについて、「CMS + 欠点」または「CMS + 体験」というキーワードで調べてみてください。あなたが正確に何に取り組んでいるかを知っておくべきです。オープンソースソリューションを選択することが賢明です。できれば、採用された技術に多くの開発者コミュニティが存在することを確認してください。その技術に関する独自のエージェンシーのソリューションに陥ることがないようにします。
- エージェンシーからは、常に会社の運用や外部ウェブサイトの開発権利を取得して、常にウェブサイトの内部または外部開発を行える権利を持つことを確認してください。その規定は契約に含まれるべきです。
- あなたの企業が技術的な設置を行いたい場合、自社のシステム管理者、ソフトウェア開発者などがチームに在籍している場合、GITを使用したバージョン管理やJIRA（または類似のツール）を使用したプロジェクト管理やチケットシステムを自らセットアップするべきです。大規模なプロジェクトになるほど、厳しく苦しいことが多いです。重要なアクセス権およびアカウントを管理できると良いです。ただし、このアドバイスは専門的に厳密にしたがっているため、数少ない顧客にのみ従うものです。
- エージェンシーがウェブホスティングを直接提供している場合があります。私たちはそのような方法には賛成できません。それは顧客との依存関係を高める一方で、ウェブホスティングには特化したWebhosterが最適だと考えています。我々は自らサーバーをセットアップして管理し、多くの人的および時間的リソースを費やしました。結局は戻ることになりました。現在、私たちのシステムはドイツの主要なWebホスティング事業者のクラウドサーバーで稼働しており、満足しています。ウェブホスティングを選択する際は、サーバーサイドのバックアップがパッケージに含まれていること、数回のクリックで簡単に適用できることを確認してください。
期間とローンチ日の決定
リニューアルは複数のプロジェクトスプリントで実行されます。これらは我々のエージェンシーエクスペリエンスによると、次のようになります：
- 現状が記録される（テストツールを使用して、または顧客サイドでうまくいっている箇所と改善が必要な箇所を印象をもとに書面に記載）
- 競合分析と解決策/インスピレーションの調査フェーズ
- ワイヤーフレーム設計
- ユーザーインターフェースデザインの作成
- フロントエンドおよびバックエンドの開発
- データまたはコンテンツの移行（自動化/手作業）
- 構造的およびコンテンツの最適化（テキストと画像）& SEOスプリント
プロジェクトスプリントは相互に重なることがあります。なぜなら、途中で新しいプロジェクト関係者がアクティブになるからです。
個々のプロジェクトスプリントにおける期間を定義し、関係者と調整することが重要です。
プロジェクトが大規模な場合、顧客のためにプロジェクトを円滑に進めるために、エージェンシーは簡単なコミュニケーションのために独自のSlackチャンネルを設けるべきですか？
ここでのヒント：導入段階からクリッカブルなプロトタイプを使用するのは良いことです。つまり、ワイヤーフレーム設計時にすでにプロトタイプを操作できるようにし、ユーザーインターフェースデザインの提示および検証時になおさらです。これにより、顧客はウェブサイトを体験する感覚をよりよく把握できます。レイアウトの提案としての簡単なJPGまたはPNG画像は現代ではもはや使われず、Sketch、Figma、Adobe XD、または他の専門ツールで作成されたクリッカブルなプロトタイプを使用すべきです。
この早い段階では変更が容易です。ウェブサイトの機能やセクションが既に開発されている場合、変更ははるかに手間がかかり、場合によっては再交渉につながりますが、これは非常に不本意です。
ここでは、モバイルユーザーインターフェイスデザインのプロトタイプが、概要とクリックパスでどのように見えるかが一目で分かります：
解決すべき問題は、いつから顧客側で進行中のテストが可能になるかです。開発者は、ローカルでの作業をステージシステムにマージした後もテストする必要があります。一見当たり前のことですが、開発者と一緒に仕事をする人なら即座に理解するでしょう。その後、エージェンシーの品質管理担当者がチケットや機能をテストすべきです。それ以降、顧客のためのテストが解放されます。顧客は決してアルファテスターになるべきではなく、すでに4つの目でテストされたシステムを受け取るべきです。エージェンシーはアルファテスターであり、顧客はベータテスターです！エージェンシータイケットシステムへのアクセスはあるのでしょうか？
さらに、文書でエージェンシーレポートの頻度が顧客に通知されるように定義されるべきです。たとえば、毎週金曜日には、作業の現在の状況、必要なフィードバックループ、または補助作業依頼に関するレポートが電子メールで送付されます。これも我々のエージェンシーエクスペリエンスからのヒントです：顧客を週末に不安定な状態に放置しない方が良いです。彼らはよくないアイデアしか出してこないからです。進行状況と来週の作業内容の詳細を提供する方がより良いです。透明性は、すべての関係者が良い感覚を保つのに役立ちます。
ローンチ日も確定されるべきです。パーキンソンの法則によれば、仕事はその遂行に必要な時間の範囲を占有する傾向があります。言い換えると、タスクを完了するための利用可能な時間が多いほど、そのタスクにかかる時間も増えます。予定された完了日は、契約に明確に記載されるべきです。期限の達成を逃すと、契約金に違約金が設定される可能性があります。ガイドラインとして、違約金は遅延する作業日数ごとに契約金額の0.2％とし、違約金の最大額は契約金額の5％であることが効果的です。違約金を実際に顧客側で主張する必要はないかもしれませんが、エージェンシーにいくつかの特別な要求を引き出す余地を与えるでしょう。
重要：金曜日にはローンチを実施しないでください。祝日の間や企業の主要営業時間帯でも同様にやめてください。実際には、IPが変更される場合、大規模なリニューアルの場合は、日曜日から月曜日の夜間をお勧めします。これにより、大多数のプロバイダーが月曜日にDNS設定を再更新するための余裕があります。DNSエントリが深夜に調整された場合、ほとんどの場合、DNS設定が月曜日の遅い午前中にすでに更新されます。このため、実質的にはライブテストとエラーの修正に4.5営業日余裕が生じます。
ウェブサイトの現状を記録する
作業を始める前に現状を把握することが重要です。現状では、技術的なパラメーターの測定結果がどのようになるかが把握され、目標の値を記録することができます：
| 項目 | 簡単な説明 | テストツール | 現状（現在の値） | 目標（目標値） |
| テクニカル&メタ情報 | ページタイトル、見出し、メタデータ、ALTテキストなど | Seobility | ||
| 構造 | リダイレクト、リンクエラー、サイトマップなど | Seobility | ||
| コンテンツ | キーワードの照合、綴りミス、不十分なテキストなど | Seobility | ||
| 画像SEO | 見やすいURL、モダンなWebフォーマット（WebP/AVIF）、<meta> -サムネイル | なし | ||
| OGデータの実装 | ソーシャルメディア向けのOpen Graphデータ | Open Graph Checker | ||
| 構造化データ（マークアップスキーマ） | スキーママークアップ/構造化データ | Schema.org | ||
| PageSpeedホームページ | モバイル/デスクトップ用のページスピード | PageSpeed Insights | ||
| PageSpeedランディングページ | モバイル/デスクトップ用のページスピード | PageSpeed Insights | ||
| PageSpeedカテゴリページ | モバイル/デスクトップ用のページスピード | PageSpeed Insights | ||
| PageSpeed製品ページ | モバイル/デスクトップ用のページスピード | PageSpeed Insights | ||
| PageSpeedブログページ | モバイル/デスクトップ用のページスピード | PageSpeed Insights | ||
| セクションごとのアクセシビリティ | 障害のあるユーザーを考慮したアクセシビリティ | Accessibility Checkerおよび/または wave.webaim.org | ||
| Hreflangチェック | 多言語対応ウェブサイトの場合 | Hreflang Validator | ||
| セキュリティヘッダー | 信頼性＆安全性 | SecurityHeaders.com | ||
| ヘルスチェック | 信頼性＆安全性 | Security Audit（Astra） | ||
| ブラウザ＆デバイステスト | Edge、Firefox、Safari、Chrome デスクトップ＆モバイル、iOs＆Android | Devツール / Lambdatest | ||
| Cookieポリシー＆DSGVO | Consent-Cookie-Policy＆DSGVO準拠 | Cookie Metrix | ||
| クローリング：ホストステータス | robots.txtの取得、DNS解決、サーバー接続 | Google Search Console | ||
| クローリング統計 | リクエスト数、ダウンロードサイズ、平均応答時間 | Google Search Console | ||
| 検索結果ページでのクリック数 | 期間別（月次/90日間、…） | Google Search Console | ||
| 検索結果ページのインプレッション | 期間別（月次/90日間、…） | Google Search Console | ||
| 検索結果ページでの平均CTR | 期間別（月次/90日間、…） | Google Search Console | ||
リストでは、SEOツールとして当社がよく利用しているSeobilityを使ってOnPage要因をチェックすることができます。私もSeo-Trainingを公開しています。Sistrix、Semrush、Ryte、SE Ranking、Screamingfrogなど、多くの同等のツールがあります。SEOツールでは、主に典型的なOnPageエラーを特定して修正することが重要です。Seobilityでは、技術＆メタ、構造、コンテンツの3つの主要領域に基づいて評価が行われます。他のSEOツールでも同様の形式で見つけることができます。重要なのは、常に全ページがクロールされるフルチェックが行われること、つまり、ホームページだけでなく、すべてのページが対象であること、また、現状のスコアやエラーの値と、最適化後に達成すべき目標値を記入することです。Seobilityでは、90以上の値が望ましいです。同様に、他の用途にも代替ツールがあります。重要なのは、優れたデータを確実に取得するために、どれか1つのツールが使用されていることです。 これがOnPage品質の現在の値の例です:  ユーザーシグナルは、Google Analytics 4からの測定によって統計的に記録されます。たとえば、離脱率、ページ/訪問者数、滞在時間などです。Google Analyticsや他の分析ツールがデータコンプライアンスに準拠して使用されている場合、このデータは現状の記録にも考慮されるべきです。 バックリンクリストも作成する必要があります。たとえば、無料で生成できる場所：https://www.seobility.net/de/backlinkcheck/ さらに、古いsitemap.xmlをバックアップすることや、サイトのフルバックアップも行うべきです。すべての関連するページは、すべての始動基盤となるGoogleシートのリストに移行されるべきです。このリストはURLリダイレクトマップの基盤となります。このようなCSVリストは、SeobilityなどのSEOツールで簡単にエクスポートできます。URLリダイレクトマップには、後で変更されたページURLへの外部バックリンクによってリダイレクトされる必要があるすべての関連ページとリンクされたページが含まれます。削除されたURLは、古い対応URLにリダイレクトされる必要があります。その際には、リダイレクトチェーンを回避することが重要です！古いリダイレクトは、まだ存在する場合は新しい最終URLに直接リダイレクトする必要があります。同様に、PDFファイルや画像にも言及する必要があり、リンクが存在する場合は、これらも正しくリダイレクトされ、404リンクにならないようにする必要があります。 リダイレクトは、URLリダイレクトマップに基づいて301リダイレクトとして設定され、.htaccess、Vhost構成のリダイレクトマップ、またはデータベースソリューションを通じて行われます。お客様自身でこれらをメンテナンスできるようにする必要があります。また、リダイレクションが持続的であることを確認する必要もあります。 チェックリスト: リニューアル前ユーザーインターフェイスデザインが承認され、エージェンシーが開発スプリントに入っている場合、以降のリニューアル日までの重要なポイントがリストされた次のチェックリストが関連してきます:
構造化データの使用（スキーママークアップ）（リストの項目12を参照）は、現代でも依然として過小評価されています。このトピックに慣れており、GoogleがGoogle検索の構造化データのマークアップについてどう述べているかを読むことをお勧めします。Googleは、機械学習によって作成される検索結果群であるSGEの枠組みにおいて、信頼性の高いデータをより重視し始めています。また、GoogleのHelpful Content Updateにより、コンテンツは専門知識、経験、権威、信憑性によりより厳しく検証される必要があります。構造化データは、Googleのこの検証を容易にする重要な要素です。構造化データを統合した後は、Schema-Markup-Validatorを使用してください。また、GoogleがPageSpeed Insightsで推奨しリンクしているStructured Data Linterでページをチェックし、構造化データの使用に関連するコードエラーについてさらに詳細な情報を得ることができます。 ウェブサイトで構造化データを活用することはもはや選択肢ではなく、条件です。Google は、信頼性のあるコンテンツを求めています。AI を活用した検索結果で取り残されたくない場合は、ページにスキーママークアップに取り組んでください！ 16 番目のポイントで、この記事では初めてアクセシビリティが登場します。PageSpeed Insights では既にアクセシビリティが独自の領域を持ち、そこで緑の数字が望ましいです。ページがアクセシビリティに対応しているかどうかのテストは、PageSpeed Insights だけでなく https://www.accessibilitychecker.org および/または https://wave.webaim.org で実施するべきです。今後リニューアルが予定されている場合、2025 年以降はウェブサイトにアクセシビリティ強化法が適用されるため、このポイントは必須です。 スタートページだけでなく、各ページタイプについてもテストを行うことをお勧めします―同様に PageSpeed テストも同じです！  リニューアルのプロセスでは、法的文書の調整と更新もしばしば発生します。 この点は、専門家や法的文書ジェネレータで文書を提供することが早急です。新しいウェブホストやニュースレターサービスの変更などが発生した場合は、委託処理契約も考慮する必要があります。 18 番目のポイントである CMS の更新、使用している JavaScript ライブラリ、インストールされているモジュールとプラグインは、同様に重要でありかつ過小評価されています。リニューアルは数ヶ月以上かかることがあります。WordPress システムでは、リニューアル日の前に多くの更新がすでに利用可能であることが簡単に確認できます。顧客は、最新バージョンを実際の公開時に使用するよう確認する必要があります。 変化する外部サービスについては、ニュースレターサービスの変更など、チェックリストに名前を記載すべき追加タスクがあります:
開発スプリント全体で、機能などのテストが継続的に実施されます。 何も見逃さないよう、非常に詳細なチェックリストを作成することが賢明です。 実施担当エージェンシーとしても顧客としても、ちょっとクリックするだけでは足りません。 TutKit.com のリニューアル後、受け入れチェックリストには確かに 1000 行ありました。 それ以降も大事なメジャーアップデート後には、Chrome、Safari、Android で 70 回の相互作用をチェックリストで行います。 チェックリスト：リニューアル日およびその後の日々リニューアル日が来ていて、金曜日でもなく、お祝いごとの日でもないことを確認してください。 新しいウェブサイトが公開され、DNS 設定が調整されました。 今後は、全体を再度チェックし、評価する必要があります。 以下をチェックしてください:
開発環境では、E-Mailsをローカルでテストするために Mailhog を利用しています。 このようなケースでは、ライブシステムでのEメール受信のための正しいSMTPデータが登録されていることが重要です。同様に、Paypal などの支払いプロバイダーでは、Dev システムにSandboxが実装されていることに注目する必要があります。一方、ライブシステムでは正しい接続が確立されなければなりません。 その後の日々では、特に Google Search Console を把握することが重要です。 ランキングがどのように変化するかに興味を持ちます。 予期しない変化やエラーメッセージに特に焦点を当ててください:
特に、Google Search Console では URL エラーや Href-Lang エラー、Spread indexiert/nicht indexiert でのページインデックスが通知されます。インデックスされていないページには（リダイレクト、noindex などの）理由があるはずです... Search Console で構造化データやコアウェブバイタルに関する問題が報告された場合は、その原因を調査してください。ライブデータを通じて、たとえば高速度のページであるにもかかわらず CLS エラーによりコアウェブバイタルに問題があることがわかるようになります。サイトの変更時に可能な変更の範囲がよくわかります：  直接悪いまたは最適化すべき URL を確認できます。URL を取り、PageSpeed Insights でページ速度テストを実行してください。そこでコアウェブバイタルが満たされない理由と、それを修正する方法がわかります。詳細情報を開くには、右下の小さな矢印をクリックしてください。これらの提案は通常、開発者によってのみ実行できます。ただし、問題を特定できるようになり、代理店と協力して対処できるようにすることが重要です。  Google Analytics 4 などの分析ツールのデータを活用し、システム上で収集できる指標に注意を払ってください。たとえば、予約、変換率、カート内金額、1日あたりの購入/売上高、ニュースレター登録数、お問い合わせ、特定コンテンツのダウンロード、ビデオビューなどを把握してください。 Google Search Console のクロール統計情報は、後続日のチェックにとって重要です。これらは左側のメニューから設定で見つけることができます。クロールのアクティビティが増加していることを直ちに確認できます。増加が見られない場合、クロールエラーがある可能性があります。 ホストステータスでは、リニューアル後にクロールリクエストが robots.txt に失敗し、サーバー接続が断続的に切断される問題が発生したことが直ちに示されます。  クロール統計情報が示す内容も興味深いです。リニューアル後、一般的にクロールリクエストが増加します。また、まだ 404 エラーページがクロールされているかどうかも確認できます。適合しないページがいくつかある場合は、開発者と話し合ってください。  将来的には、（AI を含む）ウェブサイトのコンテンツが増えるにつれて、各ウェブサイトのクロール予算が制限される可能性があるため、サイトの応答時間が良好であることが重要です。ボットが利用可能な時間内になるべく多くクロールできるようにするためです。 Relaunch-Checkliste zum Download（リニューアルチェックリストをダウンロード）埋め込まれた リニューアルチェックリストは、PDF ファイルとしてダウンロードすることができます。ダウンロードして、プロジェクトの成功を確認しましょう！  Bekenntnisse eines Agenturinhabers（代理店経営者の告白）チェックリスト内の SEO 要件は、H1 から H6 までの見出し構造などの詳細な指示を含むことがあります。テストツールでの目標値の設定により、チェックリスト全体の内容が簡略化されます。チェックリストに記載されたテストツールでの最高値達成は、きれいなコード、最新テクノロジーの使用、SEO のオンページ要因などを遵守することのみで達成できるためです。それ以外の場合、最新の Web 標準や技術要件、および SEO 要件を非常に詳細に要求し、顧客がそれについて専門知識を持っていることが困難であるため、実際にはめったに実現されません。テストツールで高い値を達成する必要がある場合、代理店が他に方法がないことから、ベストプラクティスを適用するしかありません。これは、代理店にとっても新しい経験です :-) 「告白」の時間です。SEO 要件の定義や、さまざまなテストツールでの目標値の設定など、チェックリストによる手順と目標達成の確保が、現実には滅多に実現されない理想を表しています。それは：
お客様には非難できません。彼らは専門的な助けを求めており、ほとんどのデジタルエージェンシーが自社のウェブサイトやホワイトペーパーに、SEOがその主要なスキルの一つであると記載しています。再開後のオンライン可視性が3倍、5倍、10倍に増加したことを証明する参照も常にあります。10人の訪問者が100人に増えたとしても、それは確かに1000%の増加ですが、それだけで成功とは言えません。多くの検索エンジンの成功は、競合他社がデジタル面でまだるっこしく弱いことを前提としています。 こうした検証をほぼどのエージェンシーでも行うことができます。データ駆動型の品質保証を実際に行っているエージェンシーはほんの一握りである、という理由から。市場で長年自社のプロジェクトを運営しているエージェンシーがないため。国際的な競合他社とのオンライン可視性において競争しなければならないため。おそらく、プロジェクトが成功するかどうかはエージェンシーにとってほとんど重要ではなく、エージェンシーが請求書を支払われたり、お客様が美しい（しかし質的には平凡な）ウェブサイトでポストしたりする限り、ほとんど無関心であるからです。その特別な皮肉: 上記のテストツールによると、SEOエージェンシーの中で、彼ら自身のウェブサイトが最も低い評価を受けることがあります。なぜなら、彼らは顧客のキーワードに基づいたウェブサイト向けのコンテンツパッケージのようなワン・トリック・ポニーのような手法しか持っていないから... 他の技術要件がしばしば適切な開発者が欠けているためです。 データ駆動型ウェブサイトリランチチェックリストに関するまとめこのようなデータ駆動型チェックリストは、エージェンシーに適切な作業を強制するための数少ない効果的な手段の1つです。 テストツールでの特定の数値の達成を受け入れ条件にすることをオススメします。重要なデータが揃い、最高の数値が確認され（たとえば、コアウェブバイタルとSearch Consoleのスキーママークアップによる検証された製品スニペットなど）、再起動から4週間後に一部の支払いが行われることが契約で規定されるべきです。この記事で説明されているようなワークフローを使用することで、再起動後の見えなくなりかけた可視性の損失を限定し、Googleによりあなたのウェブサイトまたはオンラインショップをすぐにランク付けしてもらいやすい基盤を築くことができます。 この記事が役立つ場合は、私たちの他のコンテンツも是非チェックしてみてください: |