SEOのためのウェブ開発：もう一つはほとんど南に行く

最終更新日：2018年9月14日

これがあなたがそのようなSEO会社を持っている理由です！ 会社、既存のウェブサイトの再設計で何がうまくいかないかを見つけて修正する。 インターネットマーケティング業界で働いていて、機能しているWebサイトの再構築を経験した人なら誰でも知っているように、無数のことがうまくいかない可能性があります。 最近、PPC（クリック課金）およびSEO（検索エンジン最適化）クライアントは、Webサイトの再構築を終えたばかりで、レビューを許可せずに起動しました。 このクライアントのサイトのこの最新の再構築は、立ち上げ時にひどく間違っていたので、私は、失敗する可能性があり、失敗する可能性のある予想および予期しないことのいくつかに触れます。

必要なもの

このクライアントは、既存のeコマースおよび情報Webサイトを持ち、業界のリーダーである既存のビジネスを購入しました。 Web開発者は購入に付属していませんでした。 なんらかの理由で私に明らかにされなかったので、クライアントはショッピングカートの外のページを更新できませんでした。 ショッピングカートはモバイルフレンドリーではなく、デスクトップとモバイルのコンバージョンの違いを確認できました。 モバイルコンバージョンは事実上存在しませんでした。 彼らのオンライン販売の圧倒的多数は、デスクトップのオーガニック検索、PPC、直接および紹介訪問によって生み出されていました。

SEOを改善するために必要な要素の多くも、そこにはありませんでした。 メタデータ、h1タグ、alt / titleタグなどを変更する機能はありません。このデータのほとんどは、プログラムで生成されていました。 メニューやナビゲーション構造も同様です。 この新しいサイトも安全である必要があります。 つまり、彼らが必要としていたのは、既存のエンタープライズリソースプランニング（ERP）ソフトウェアスイートと連携するための、新しいモバイルフレンドリーで安全なWebサイトとコネクタ付きのショッピングカートでした。

ミッション

このクライアントには3,766のキーワードがあり、ランキング結果は上位100のGoogleSERPに含まれています。 ページ1の結果を含む538のキーワードは、65,790の平均月間検索ボリュームを持ち、43のキーワードは6,110の平均月間検索ボリュームを持っていたGoogleSERPの1位にランクされています。 私の仕事は、新しい管理システムがSEOを実装する能力を提供するために必要となる要件を彼らに案内することでした。 これには、既存のランキング結果を可能な限り保護することも含まれていました。

セレクション

クライアントは最終的に、既存のERPソフトウェアと、モバイルフレンドリーで安全な新しいショッピングカートソリューションおよびWebサイトとの統合を提供できるオフショアベンダーを選択しました。 このオフショアベンダーに精通していないため、クライアントは、管理システムがSEOの実装に必要なものを提供することを確認するために、記録された製品デモを提供してくれました。 デモを確認した後、SEOの改善でクライアントを支援するために必要な要素があると結論付けました。 独自のページタイトル、メタディスクリプション、h1タグを作成できます。 Google Analytics（GA）コードを更新することができましたが、そのコードは古くて古いGAコードを実行しており、検索コンソールアカウントはありませんでした。 適切にフォーマットされた代替/タイトルテキストを追加するために、画像にアクセスしました。 後でわかったように、そして遅すぎたので、各ページに301リダイレクトを適用する機能さえありました。 しかし、それは話の一部にすぎません。

結果

結局のところ、開発者はテンプレート、ショッピングカート、ERP統合を提供しました。 クライアントは、既存のメタデータを含むコンテンツの移動（古いサイトコンテンツのコピーと管理システムの新しいページへの貼り付け）を担当していました。 また、古いサイトのURLを新しいページのデータにページごとに入力するように依頼されました。 クライアントが古いサイトのURLをそのままコピーして貼り付けることができなかったため、これは複雑でした。 クライアントはこれを標準の操作手順として採用し、誰にも通知しませんでした。 当初は、開発者が適切な301リダイレクトファイルを作成することを推奨していました。 ロールアウトのタイムラインでは、クライアントが適切な操作を確認することを許可していませんでした。 彼らはちょうどそれを立ち上げました、そしてそれはそれがすべてうまくいかなかったところです。

再構築されたサイトが立ち上げられたことに気づいたら、現在のランキング結果に対して元のキーワードのランキング結果を手動でテストし始めました。 新しいサイトがどのように見えるか、そしてすべてのデータが転送されたことを確認するためだけに。 ホームページを除いて、まだ配置されているGoogle SERPのすべてのランキング結果は、404応答コードになりました。 結局のところ、古いサイトのURLは.html拡張子で作成されていましたが、新しいURLは作成されていませんでした。 管理システムでは、指定された301リダイレクトフィールドに古いURLを貼り付けることができなかったため、クライアントは.html拡張子なしで古いURLを貼り付けました。 クライアントは、これが標準的な操作手順であると想定していました。

社内で多くの議論を重ねた結果、.html拡張子を削除すると、ほとんどの場合、ページが新しいURLの安全なバージョンに正しくリダイレ​​クトされることがわかりました。 ただし、場合によっては、.html拡張子のない古いURLが、これまでに見たことのないクエリ文字列を含む、検索エンジンに対応していない新しいURLにリダイレクトされます。 さらに調べてみると、この新しい未知のURLがメインメニューのナビゲーションによって生成されていることがわかりました。 そのため、ほとんどの場合、古いURLから.html拡張子を削除して、新しい安全な検索エンジンに適したURLに1対1でリダイレクトし、メインナビゲーションから新しい非わかりやすいURL。

コンテンツが重複していますか？ さて、rel =正規タグは配置されましたか？ 正しく？ いいえ。検索エンジンに適したリダイレクトされたURLのrel=canonicalタグは、クエリ文字列を含む新しい非検索エンジンに適したURLを指すように設定されました。 非フレンドリページのrel=canonicalタグを調べたところ、このタグがまったく異なるURLを参照していることがわかりました。 クエリ文字列ではなくカテゴリを含むもの。 そのため、rel = canonicalタグが不適切に設定された、3つの異なるURLに対して1つのコンテンツが表示されていました。

次に、robots.txtファイルですべてのボットが許可されていないことがわかりました。 次に、GAでアクティビティを確認しました。 クライアントはまだすべてのソースからの訪問を受けていましたが、コンバージョンはゼロでした。 さらに、クライアントは、Googleの検索コンソールを必要とするクロールとインデックス作成をプッシュすることを望んでいました。 ここでの問題は、既存のGAコードが古く、サイトに検索コンソールの確認コードが配置されていないことです。 これは、クライアントが決して開示されなかった理由で変更できなかった項目の1つです。

幸い、クライアントは、GAコードを最新バージョンに更新することを実装するという推奨事項を採用していました。 彼らは独自にGoogleのタグマネージャーも追加しました。 おっとっと！ おそらくGAコードの二重発火？ Googleタグマネージャーと更新された非同期GAコードを使用して、クライアント用の新しい安全な（httpsとhttp）検索コンソールアカウントを作成できました。その後、リクエストされたクロールに送信する.xmlサイトマップがないことがわかりました。 。

通知を受けると、クライアントは開発者と通信し、2つの.xmlサイトマップURLが与えられました。 1つは働いた。 1つはしませんでした。 動作しているものには、動作していない.xmlサイトマップを指すエントリが1つありました。 動作していない.xmlサイトマップは、ブラウザで表示したときに適切なフォーマットになりませんでした。 そのため、提供された.xmlサイトマップはその時点では送信していません。

最終結果

私たちは、段階的な電子メールを介して、私たちが見つけたものをクライアントに通知しました。 まず、リダイレクトの失敗の問題と、.html拡張子を削除すると、正しくリダイレ​​クトされることがわかりました。 クライアントは開発者に通知し、開発者は、提供されている301リダイレクトツールに.html拡張子を付けることができないと応答しました。 さらに発見したところ、クライアントはこれを発見し、これが標準的な操作手順であると考えていました。

何らかの理由で、元のWebサイトが削除されたため（ここでは大きなおっと、常に作業バージョンをフォールバックする準備ができています）、古いURLをプルして、.htaccessファイルを介して新しい永続的な301リダイレクトを作成できませんでした。 解決策は、新しい1対1の一致、古いURLと新しいURL、スプレッドシートを作成し、過去1年間のGAからランディングページデータを取得して、開発者が適切に機能するリダイレクトを作成し、301リダイレクトをオーバーライドすることでした。クライアントに課せられた管理システム。

開発者からクライアントへの追加費用で問題が解決されました。 拡張子が.htmlの既存の古いランキング結果は適切にリダイレクトされ始め、14日以内に、ランキング結果は新しい安全なURLに置き換えられ、ほとんどの場合、既存のランキング結果に非常に近くなります。 rel = canonicalタグの問題は、Web開発者の販売代理店とのオンライン会議で解決され、ユーザー入力エラーが発生しました。 既存の選択肢からデータを入力または選択できるフィールドがいくつかあり、ソリューションではこれらのフィールドをリセットしてキャッシュをクリアする必要がありました。

フレンドリーで安全なURLの2つの追加バージョンはすぐになくなりました。 robots.txtのボット/disallowに関して、通知に応じて、開発者はこの問題を迅速に解決しました。

GA変換データの問題は、クライアントのマーチャントサービスプロバイダーに限定されているようです。 これは新しく、古いプロバイダーとは異なりました。 クライアントがマーケティング活動について情報に基づいたビジネス上の決定を行うために必要なeコマースデータを提供するために、チェックアウトページにGAコードが必要であることをマーチャントサービスプロバイダーに伝えることを考えた人は誰もいませんでした。 新しいマーチャントサービスプロバイダーの存在については知らされていませんでした。

最後に、サーバーにアップロードする.xmlサイトマップファイルを手動で作成し、機能していない.xmlサイトマップを作成しているものを開発者に無効にするように要求しました。 開発者の販売代理店とのさらなる話し合いで、サーバーに別の.xmlサイトマップをアップロードできないと言われました。

開発者の販売代理店に結果を見せた後、彼はそれを調べると述べたが、彼は私たちがソースコードを見るように提案した。 ソースコードを表示すると、.xmlドキュメントは適切にフォーマットされていました。 この結果を確認した後、検索コンソールを介して、実際に.xmlサイトマップが機能していることをGoogleに通知しました。 最後に、数日の間に、Googleはようやく.xmlサイトマップが機能していることを記録し、インデックスに登録されているURLの表示を開始しました。 ただし、前述のように、正しくフォーマットされた.xmlサイトマップには、ブラウザでは解決されないがソースコードに正しく表示される追加の.xmlサイトマップを指すエントリが1つしかありませんでした。

追加の.xmlサイトマップが500応答コードを生成したため、この問題はより大きな問題になりました。そのため、サイトのこの領域にアクセスするGoogleエージェントに問題があります。 そして、今日の時点で、両方の.xmlサイトマップは500の応答コードを生成しています。 1週間前に、Google検索コンソールで利用できるフェッチ、レンダリング、送信ツールを使用してクロールを促しました。これにより、新しいサイトのクロールとインデックス作成が行われたと考えられます。

したがって、最後に、問題が発生する可能性がある場合は、Webサイトを再構築するときに、うまくいけば、これらの間違いのいくつかを回避できるようになります。 robots.txtファイルでボットをブロックし、不適切にリダイレクトすると、オンラインで廃業したり、少なくとも危険にさらされたりする可能性があります。 ボットがサイトをクロールできない場合、最終的にはインデックスから削除され、参照、直接、またはその他の非有機的なソースからのものでない限り、インデックスから削除すると、ほとんどの有機的な検索アクセスは存在しなくなります。

結果が適切にリダイレクトされない場合、Organicの訪問者はあなたのサイトを信頼できないと見なす可能性があります。 あなたのサイトをブックマークとして保存している既存の顧客は、ブックマークが正しくリダイレ​​クトされないとイライラするかもしれません。 その間、彼らのPPCキャンペーンを停止しなければならなかったことは言うまでもありません。 有料広告をクリックして404ページが見つからないという応答を受け取ることは、訪問者を苛立たせるだけでなく、費用もかかります。 クリックはあなたにお金がかかり、あなたはあなたの投資の見返りを得ません。 そして、これがあなたが私たちを持っている理由です。

–マークグレイ、シニアSEOマネージャー