Avantages SEO de / blog lors du transfert via ProxyPass
Nous avons eu des demandes de clients via leurs sociétés de référencement pour héberger des blogs accompagnant des sites de commerce électronique sur theirdomain.com/blog plutôt que sur - par exemple - blog.theirdomain.com
Alors que nous nous occupons de leur hébergement e-commerce et que nous n'hébergeons pas wordpress sites (ceux-ci sont hébergés sur wpengine.com), nous avons reçu quelques demandes pour accomplir cela en utilisant ProxyPass qui nous permet transférer toutes les demandes d’un sous-dossier virtuel vers un autre domaine. Exemple d'installation ci-dessous:
Redirect /blog /blog/
ProxyPass /blog/ http://blog.theirdomain.com/
ProxyPassReverse /blog/ http://blog.theirdomain.com/
ProxyPassReverseCookieDomain blog.theirdomain.com www.theirdomain.com
ProxyPassReverseCookiePath / /blog/
Cela signifie que chaque demande adressée à theirdomain.com/blog est transmise à leur blog sur un sous-domaine. Apparemment il est préférable que Google héberge votre blog de cette manière. Cependant, il me semble que tout avantage que vous en tireriez (à supposer qu’il en existe un) serait éradiqué par le temps de latence introduit pour chaque requête sur votre blog, ou un atout sur votre blog, dans le fait que chaque demande doit être redirigé via notre serveur.
Existe-t-il des preuves à l’appui de l’un ou l’autre point de vue?
Merci.
J'essaie de comprendre comment vous vous occupez de leur hébergement lorsque les domaines sont différents, à moins que tout se trouve sur le même serveur.
Quoi qu'il en soit, le problème avec votre configuration SEO (comme vous l'avez indiqué un peu) est la rapidité, car le serveur Web Apache tente de se connecter à l'autre domaine et de charger les données correctes avant que le client ne puisse rien voir. La latence (délai jusqu'au premier octet ou TTFB) est supérieure à 200 ms, ce qui correspond au nombre que Google considère comme acceptable selon sa documentation Page-speed insights. C’est-à-dire bien sûr que votre serveur est un serveur ridiculement haut débit juste à côté de celui de Google.
Le meilleur site de preuve est à http://www.webpagetest.org . Allez-y et entrez une URL qui fait fonctionner la fonctionnalité de proxy sur votre serveur et vous verrez un TTFB supérieur. Faites la même chose avec tout autre fichier sur votre serveur qui ne nécessite pas la fonctionnalité de proxy et vous devriez voir le TTFB être un peu plus bas.
La meilleure solution serait de créer des pages de redirection avec des codes de statut HTTP 301 qui pointent vers les nouvelles URL. Par exemple, si vous avez mod_rewrite installé et actif dans Apache, vous pouvez ajouter dans .htaccess des lignes telles que:
RewriteEngine On
RewriteRule ^firstcustomerblog$ http://blog.customer1.com [R=301,L]
RewriteRule ^secondcustomerblog$ http://blog.customer2.com [R=301,L]
RewriteRule ^thirdcustomerblog$ http://blog.customer3.com [R=301,L]
Dans l'exemple ci-dessus, toute personne qui visite http://example.com/firstcustomerblog sera automatiquement redirigée vers http://blog.customer1.com . Toute personne qui visite http://example.com/secondcustomerblog sera automatiquement redirigée vers http://blog.customer2.com . Enfin, toute personne qui visite http://example.com/thirdcustomerblog sera automatiquement redirigée vers http://blog.customer3.com . Supposons que exemple.com est votre domaine.
Au début, le TTFB est à peu près identique à l’idée du proxy, mais une fois la page suivante consultée sur le site du client (à condition que le client n'inclue pas votre nom de domaine pour chaque lien), le TTFB sera beaucoup plus bas, fournissant ainsi une expérience plus rapide.