Have you ever encountered a situation where you need to have a blog on your existing company website that does not run on WordPress? I’m sure most of you have confronted such scenarios. In this article, you’ll discover a way to achieve it without compromising SEO. Before we dive into it, let’s explore how the
Avez-vous déjà été confronté à une situation où vous avez besoin d'un blog sur le site web de votre entreprise qui ne fonctionne pas sous WordPress ? Je suis sûr que la plupart d'entre vous ont été confrontés à de tels scénarios.
Dans cet article, vous découvrirez un moyen d'y parvenir sans compromettre le référencement.
Avant de nous y plonger, examinons comment les organisations et les institutions utilisent l'hébergement du blog séparément du site web principal.
De nombreuses grandes entreprises disposent de systèmes informatiques complexes, ce qui complique la tâche de leurs services internes lorsqu'il s'agit de sortir du cadre de leurs systèmes internes. Prenons l'exemple du département de marketing de contenu qui souhaite créer un blog pour éclairer son public. Cependant, l'organisation actuelle rend impossible la création d'un blog, par exemple sur un hébergement WordPress.
D'autre part, les entreprises peuvent utiliser le ".NET Framework" pour leurs applications web, et d'autres entreprises hésitent à utiliser des frameworks Open-Source.
Lorsque vous devez héberger un blog dans l'un des scénarios énumérés ci-dessus, vous n'avez pas d'autre choix que de penser à un serveur alternatif pour l'héberger. Ce serveur se trouve donc en dehors du serveur sur lequel vous avez hébergé votre site web. Examinons quelques-unes de ces options et leurs incidences, si vous le voulez bien.
Par exemple, si votre site web principal a une URL de www.myorganization.com, les professionnels les plus compétents du passé sur le plan technique seraient enclins à installer le blog WordPress en achetant un sous-domaine du domaine principal. Par exemple, dans cette situation, il s'agirait de notreblog.myoraginzation.com.
Autrefois, cette solution était parfaite. Cependant, à l'heure actuelle, lorsque vous souhaitez générer un volume considérable de trafic vers votre blog, vous devez également prendre en compte les aspects liés au SEO (Search Engine Optimization, ou optimisation pour les moteurs de recherche). Nous y reviendrons dans la section suivante.
La principale raison pour laquelle les propriétaires de sites achètent des sous-domaines est d'avoir un contenu distinct basé sur différents produits pour votre marque. Bien qu'il puisse y avoir d'autres raisons, telles qu'un site web séparé pour les mobiles et l'augmentation du trafic, la raison fondamentale réside dans le contenu et l'expansion de votre marque sur la base de plusieurs niches.
Par exemple, Wikipédia a des sous-domaines pour séparer le contenu en fonction des différentes langues, comme fr.wikipedia.com ou es.wikipedia.com.
NPR, un réseau radiophonique populaire, est un autre exemple où il se concentre à 100 % sur ses actualités et son contenu. Cependant, elle possède également un sous-domaine, https://shop.npr.org/, qui se concentre principalement sur le merchandising.
Dans les scénarios mentionnés ci-dessus, il est donc logique d'avoir un sous-domaine. Mais qu'en est-il dans le cas des blogs ?
Les moteurs de recherche considèrent les sous-domaines comme des sites web distincts. Cela signifie que les moteurs de recherche doivent explorer et indexer chaque sous-domaine séparément. De plus, les liens vers le domaine principal ne sont pas partagés avec les sous-domaines. Il est donc presque aussi difficile d'améliorer le classement d'un sous-domaine que celui du domaine principal.
Il serait donc utile d'avoir des sous-domaines dans les cas où cela se justifie. Par conséquent, une option idéale pour les blogs serait d'avoir le blog en tant que sous-répertoire de votre site principal.
Cependant, comme je l'ai mentionné plus haut, comment pouvez-vous le faire dans des circonstances où votre site principal fonctionne et où vous l'hébergez sur une plate-forme différente qui ne prend pas en charge l'hébergement WordPress ?
C'est précisément la raison d'être de Reverse proxys . Nous vous donnerons une vue d'ensemble de Reverse proxys dans la section suivante.
Il serait plus facile de comprendre le concept de proxy inverse si vous saviez ce que fait un proxy direct.
Proxy d'acheminement - Un proxy d'acheminement transmet toutes les demandes entrantes de tous les nœuds du réseau local (LAN) au serveur approprié auquel la demande doit être adressée. Le serveur de destination n'a aucune idée de l'origine de la demande et envoie la réponse au client qui a initié la demande via le proxy de transfert. Le diagramme ci-dessous l'illustre
Proxy inversé : En revanche, un proxy inverse se place devant les serveurs et envoie une demande au serveur approprié lorsque le client lance une requête. Ensuite, lorsque le serveur approprié renvoie la réponse, le mandataire inverse renvoie la réponse à l'appareil du client. L'appareil client a l'impression que c'est le serveur mandataire inverse qui a traité toutes les demandes. proxys Les serveurs mandataires inversés sont idéaux dans les situations où la même partie d'une application web est réduite sur plusieurs serveurs différents.
Pour en savoir plus sur proxys, vous pouvez consulter cet article.
De même, vous pouvez utiliser un Reverse Proxy pour diriger le trafic vers le serveur où vous avez hébergé le blog WordPress. D'autre part, le Reverse Proxy dirigera le trafic non lié au blog vers le serveur correspondant. Je sais que c'est plus facile à dire qu'à faire. Prenons donc un exemple.
Supposons que, comme le montre le diagramme ci-dessous, votre site web est https://www.somedomain.com hébergé sur un serveur web qui ne prend pas en charge WordPress, mais que votre équipe de marketing de contenu meurt d'envie d'avoir un blog. Compte tenu de tous les éléments de référencement mentionnés ci-dessus, votre équipe de développement Web n'a d'autre choix que d'installer le blog dans le répertoire "blog". Par conséquent, l'URL du blog sera la suivante https://www.somedoamin.com/blog.
Le site web principal n'étant pas compatible avec WordPress, voici les étapes que votre équipe de développement web doit suivre :
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="blog.somedomain.com" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{HTTP_HOST}" pattern="^blog.somedomain.com$" />
<add input="{PATH_INFO}" pattern="^/blog/" negate="true" />
</conditions>
<action type="Rewrite" url="\blog\{R:0}" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Dans les deux lignes ci-dessous, le "blog.somedomain.com" doit être remplacé par le sous-domaine où se trouve votre blog :
<rule name="blog.somedomain.com" stopProcessing="true">
<add input="{HTTP_HOST}" pattern="^blog.somedomain.com$" />
Ensuite, dans ces deux lignes, vous pouvez remplacer le dossier "blog" si vous lui avez donné un nom différent :
<add input="{PATH_INFO}" pattern="^/blog/" negate="true" />
<action type="Rewrite" url="\blog\{R:0}" />
Dans l'étape finale, bien que nous ayons utilisé un sous-domaine, cela n'affectera pas le référencement car le trafic sera généré vers le dossier du blog du site principal. La redirection vers le sous-domaine est donc un processus interne qui n'affectera pas le référencement.
Les circonstances évoquées ci-dessus se produisent lorsque vous utilisez un serveur qui ne prend pas en charge PHP. Cependant, si vous vous trouvez dans un scénario où votre site principal fonctionne avec PHP ou Drupal, par exemple, mais que vous voulez avoir un site différent pour le blog dans le même domaine, vous devez configurer le Reverse Proxy en suivant les étapes ci-dessous.
Mais avant cela, vous devez vous assurer que vous avez deux sites opérationnels. L'un est https://www.somedomain.com, et l'autre est doté de WordPress et d'un sous-domaine, https://blog.somedomain.com.
Tout d'abord, vous devez ouvrir le terminal du serveur Apache via SSH. Ensuite, vous devez activer le module proxy d'Apache à l'aide de cette commande :
sudo a2enmod proxy proxy_http sslCette commande redémarre Apache dans la plupart des cas pour recharger les nouvelles directives que vous avez définies ci-dessus :
L'étape suivante est celle que vous attendiez. Il s'agit de créer le proxy inverse en modifiant le fichier d'hôte virtuel du serveur.
<VirtualHost *>
DocumentRoot /var/www/app/public
SSLProxyEngine On ProxyRequests off
ProxyPass /blog http://blog.somedomain.com
ProxyPassReverse /blog http://blog.somedomain.com
</VirtualHost>
Deux points essentiels sont à noter ici :
Les étapes suivantes concernent WordPress, ce qui est typique des deux scénarios ci-dessus.
Vous devez ensuite vous rendre sur le serveur où vous avez installé WordPress et mettre à jour le fichier wp-config.php. En effet, il n'est pas habituel de configurer WordPress pour qu'il fonctionne sur un proxy inverse.
Vous devez donc mettre à jour le fichier wp-config.php comme suit :
$_SERVER['REQUEST_URI'] = str_replace("/wp-admin/", "/blog/wp-admin/", $_SERVER['REQUEST_URI']) ;
Ensuite, dans le même fichier, vous mettez à jour les variables suivantes :
Entre-temps, vous pouvez mettre à jour les valeurs de configuration de la base de données comme suit :
UPDATE wp_options SET option_value = 'https://www.somedomain.com/blog' WHERE option_name IN('siteurl', 'home') ;
L'étape suivante consiste à modifier le fichier .htacess afin de réécrire correctement les URL :
Devient :
RewriteRule . /blog/index.php [L]
Après avoir effectué toutes les étapes ci-dessus, vous devez vous assurer que les liens vers les articles et les catégories fonctionnent comme prévu. Pour ce faire, vous devez vous connecter avec l'ancienne URL du sous-domaine comme ci-dessous :
blog.somedomain.com/wp-login.php
Dans ce cas, il serait utile de naviguer vers les "paramètres" à partir du tableau de bord principal et de cliquer sur l'onglet "Général".
Dans le champ Adresse du site (URL), procédez à la mise à jour suivante :
Si vous n'êtes toujours pas sûr que les URL fonctionneront correctement, vous pouvez installer le plugin "Better Search Replace". Il mettra à jour tous les enregistrements de votre base de données si nécessaire.
En outre, vous devez également faire attention à la mise à jour des canoniques et des robots.txt.
Si vous n'êtes toujours pas sûr que les URL fonctionneront correctement, vous pouvez installer le plugin "Better Search Replace". Il mettra à jour tous les enregistrements de votre base de données si nécessaire.
En outre, vous devez également faire attention à la mise à jour des canoniques et des robots.txt.
Vous avez peut-être découvert que WordPress est hautement personnalisable. En effet, vous pouvez utiliser WordPress pour héberger uniquement la partie blog du site web, sans toucher au reste. Comme vous l'avez vu dans ce blog, le reste du site web peut être hébergé sur différentes plateformes qui ne supportent pas WordPress.
L'intégration du blog au reste du site web peut donc s'avérer difficile. Cependant, vous pouvez y remédier en utilisant le site proxys inversé.
Restez à l'écoute pour d'autres articles.