ドメインをリンクできるオンラインサービスをほぼ完成させようとしています。 Squarespace/Wix/Weeblyタイプと考えてください。訪問者は、customerdomain.com
につながるmywebapp.com
を入力しますが、customerdomain.com/page
をアドレスバーに保持し、mywebapp.com/page
に転送します。主要なドメインは1つだけで、コンテンツは両方のドメインから技術的にアクセスできます。サイトはドメイン名によって動的に識別され、フレームなしで生成されます。
現在、Alias Pointer
を使用しており、SEOにcustomerdomain.com
を指すcanonical
タグを使用していますが、これは技術的には正常に機能します。
ただし、SSL、サブドメイン、各ドメインのメールホスティングを許可し、クライアントまたは私がドメインを所有することに留意してください。最終的には、顧客によるwebapp内のドメイン名の追加を自動化したいと思います。
これは、「1つの」webappを介して数百のサイトにサービスを提供する私の(顧客)SEOにどのように影響しますか? is Canonical enough? Other technical setup? More IP adresses? How much per IP?
インデックス作成のルールは、「コンテンツはどこですか?」 「それへの最速ルートは何ですか?」
クロスドメインの正規化は、ソフトリダイレクトのように扱われます。コンテンツはwebapp.com/pageから提供されますが、URIはdomain.com/pageのままです。 webapp.com/pageを指すiFrameを使用している場合、Googleはそれをリンクとして表示し、リンクされたコンテンツのアドレスにインデックスを付けます。クロスドメインの標準タグを使用する場合、might index domain.com/page。
ページを別のページに正規化できますが、それは提案であり、指示ではありません。各ページのコンテンツが類似している場合、Googleはインデックスをマージし、それらを同じページと「考える」ことを決定する場合があります。コンテンツが大きく異なる場合、提案は完全に無視されます。
別のページのインデックスを強制する唯一の方法は、301リダイレクトです。これは、より難しいディレクティブとして機能します。また、リクエストURIも変更します。
次に、簡単なフローを示します。
これらは、インデックスからコンテンツへの最短パスを見つけるためにGoogleのアルゴリズムが尋ねる質問です。そのパスを長くしたり、迂回したりする方法でそれを破壊しようとすると、Googleはインデックスリンクを適応またはドロップします。
単一のドメインの下ですべてのインデックスを作成しようとしている場合、IPアドレスに違いはありません。 Googleはもともと、サブドメインを完全に別個のサイトと見なすようにトレーニングされていましたが、サブドメインがメインサイトの一部であるかどうかの解釈にはまだ問題があります。 xxx.wordpress.com
を考えてください-ホストされている各サイトには独自のサブドメインがあります。 www.wordpress.com
はこれらのサブドメインにはまったく影響しません。
クイック編集:IPアドレスwouldがSEOに入る場所は、同じCブロック(同じネットワークから実行される遅延PBNを示します)の一部として表示されることなく、異なるドメインが互いに利益をもたらすようにする場合です。同じドメイン名を使用しているため、これは関係ありません。これは、すべてのサイトが同じネットワークからのものであることをGoogleに明確に伝えます。