Comment servir un sous-domaine en tant que sous-répertoire

Disons que vous disposez d'un site Web construit sur une plate-forme qui excelle sur le design et qu'il est disponible sur Example.com. Mais cette plate-forme ne fait pas face aux blogs. Vous vous pensez donc: "Et si je pouvais utiliser une plateforme de blogs différente et la rendre disponible sur exemple.com/blog?"

La plupart des gens vous diraient que cela va à l'encontre de la façon dont le DNS et les sites Web sont censés fonctionner et utiliser un sous-domaine à la place. Mais il y a des avantages à garder votre contenu sur le domaine racine que nous n'obtenons tout simplement pas avec les sous-domaines.

Il existe un moyen de servir deux plates-formes différentes sur la même URL. Et je vais vous montrer la sauce secrète afin que, à la fin de cet article, nous ferons Blog.example.com servir d'exemple.com/blog.

Pourquoi tu voudrais faire ça

Parce que vous êtes ici, vous savez probablement déjà pourquoi c'est une voie à suivre. Mais je voudrais m'assurer que vous êtes ici pour la principale raison de le faire: SEO. Découvrez ces 14 études de cas qui montrent des résultats positifs lorsque les gens déplacent leurs sous-domaines vers des sous-répertoires. Vous voulez que votre blog et votre domaine partagent la valeur SEO. Le mettre sur un sous-domaine déconnecterait quelque peu les deux.

C'était ma raison, et a fini par fusionner deux plates-formes, où le domaine principal était sur WordPress et le sous-domaine était sur Drupal. Mais ce tutoriel est la plate-forme agnostique - elle fonctionnera avec à peu près n'importe quelle plate-forme.

Cela dit, l'approche CloudFlare que nous couvrons dans ce tutoriel est incompatible avec Shopify, sauf si vous payez le plan d'entreprise de CloudFlare. En effet, Shopify utilise également CloudFlare et ne nous permet pas de proxyer le trafic sur leur niveau de tarification gratuit.

Étape 0 (aperçu)

Avant de sauter, je veux expliquer le niveau élevé de ce qui va se passer. En bref, nous aurons deux sites Web: notre principal (example.com) et le sous-domaine (blog.example.com). J'utilise «blog» comme exemple, mais dans mon cas, je devais tomber dans Drupal avec un type de contenu différent. Mais un blog est le cas d'utilisation typique.

Cette approche repose sur l'utilisation de CloudFlare pour DNS et un peu plus quelque chose qui fournira la magie. Nous allons dire à Cloudflare que lorsque quelqu'un visite example.com/blog, il devrait:

1. Intercepter cette demande (parce que l'exemple.com/blog n'existe pas vraiment),
2. Demandez un domaine différent (blog.example.com/blog) dans les coulisses, et
3. Livré les résultats de cette dernière étape au visiteur masqué via example.com/blog.

D'accord, plongeons-y plus en détail!

Étape 1: Utilisation de CloudFlare

Encore une fois, nous utilisons CloudFlare pour le DNS. Pointer le DNS de votre domaine, il y a la première étape pour commencer.

La raison de CloudFlare est qu'elle nous permet de créer des travailleurs capables d'exécuter un peu de code chaque fois que quelqu'un visite certaines URL (appelées itinéraires que nous créerons à l'étape 3). Ce code sera chargé de changer les sites Web dans les coulisses.

Cloudflare a un excellent guide pour commencer. L'objectif est de pointer de votre domaine - partout où il est enregistré - aux noms de noms de CloudFlare et à confirmer que CloudFlare est connecté dans votre compte CloudFlare.

Étape 2: Créez le travailleur

Ce code sera chargé de changer les sites Web dans les coulisses. Rendez-vous chez les travailleurs et cliquez sur Créer un service .

Nommez votre service, puis sélectionnez «HTTP Handler»:

Cliquez sur Créer un service , puis modifiez rapidement .

Collez dans le code suivant et remplacez les noms de domaine par votre propre ligne 16 :

 // Écoutez chaque demande et répondez avec notre fonction.
// Remarque, cela s'exécutera uniquement sur les routes configurées dans CloudFlare.
addEventListener ('fetch', fonction (événement) {
  event.RespondWith (handlerequest (event.request))
})

// notre fonction pour gérer la réponse.
Fonction asynchrone handlerequest (request) {
  // Obtenez uniquement des demandes de travail avec ce proxy.
  if (request.method! == 'get')
  return MethodNotAllowed (demande);
  // L'URL qui est demandée.
  const url = new URL (request.url);
  // Demande "URL d'origine" aka le vrai blog au lieu de ce qui a été demandé.
  // Cela change l'URL absolue, laissant le chemin relatif inchangé. 
  const OriginUrl = url.toString () .replace ('https://example.com', 'https://blog.example.com');
  // Le contenu de la page d'origine.
  const OriginPage = Await Fetch (OriginUrl);
  // Donnez à la réponse notre page d'origine.
  const newResponse = new Response (OriginPage.Body, OriginPage); return newResponse;
}

// Hé! Obtenez les demandes uniquement 
Fonction MethodNotAllowed (demande) {
  return new Response (`Méthode $ {request.method} non autorisé.`, {
    Statut: 405,
    En-têtes: {'permettre': 'get'}
  })
}

Enfin, cliquez sur Enregistrer et déployer .

Étape 3: Ajouter des itinéraires

Informons maintenant CloudFlare quelles URL (AKA Routes) pour exécuter ce code. Rendez-vous sur le site Web de CloudFlare, puis cliquez sur les travailleurs .

Il y a la section des travailleurs sur l'écran principal de CloudFlare, où vous modifiez le code, puis il y a la section des travailleurs sur chaque site Web où vous ajoutez les itinéraires. Ce sont deux endroits différents, et c'est déroutant.

Tout d'abord, cliquez sur Ajouter une route :

Parce que nous ajoutons un blog qui a de nombreuses pages enfants, nous utiliserons https://example.com/blog*. Notez que l'astérisque agit comme un joker pour le match. Ce code s'exécutera sur la page du blog et chaque page qui commence par le blog.

Cela peut avoir des conséquences involontaires. Dites, par exemple, vous avez une page qui commence par «blog» mais qui ne fait pas partie du blog réel, comme https://example.com/blogging-services. Cela serait ramassé avec cette règle.

Ensuite, sélectionnez le travailleur dans la liste déroulante du service .

Nous avons beaucoup de travaux, mais il y a plus de routes que nous devons ajouter - le CSS, le JavaScript et d'autres chemins de fichier dont le blog dépend (à moins que tous les fichiers ne soient hébergés sur une URL différente, comme sur un CDN). Une bonne façon de les trouver est de tester votre itinéraire et de vérifier la console.

Rendez-vous sur votre https://example.com/blog et assurez-vous que quelque chose se charge. Il semblera gâché car il manque les fichiers de thème. C'est bien pour l'instant, tant qu'il ne produit pas une erreur 404. L'important est d'ouvrir les Devtools de votre navigateur, de lancer la console et de noter toutes les URL rouges qu'il ne trouvera ni ne chargez (généralement un 404 ou 403) qui font partie de votre domaine.

Vous voudrez les ajouter en tant que routes… mais ne faites que les chemins parents. Donc, si votre URL rouge est https://example.com/wp-content/themes/file1.css, alors faites https://example.com/wp-content* comme itinéraire. Vous pouvez également ajouter un chemin d'enfant, si vous voulez être plus précis, mais l'idée est d'utiliser un itinéraire pour attraper la plupart des fichiers.

Une fois que vous avez ajouté ces itinéraires, consultez votre URL et voyez si cela ressemble à votre sous-domaine. Si ce n'est pas le cas, vérifiez les étapes précédentes. (Il y a de fortes chances que vous deviez ajouter plus de itinéraires.)

Il est préférable de faire un contrôle de qualité en naviguant vers plusieurs pages et en voyant si quelque chose manque. Je recommande également d'ouvrir Devtools et de rechercher votre sous-domaine (blog.example.com). Si cela apparaît, vous devez soit ajouter des itinéraires pour cibler ces ressources ou faire quelque chose avec votre plate-forme pour arrêter de sortir ces URL. Par exemple, ma plate-forme représentait une balise canonique avec mon sous-domaine, j'ai donc trouvé un plugin pour modifier l'URL canonique comme mon domaine racine.

Étape 4: Le secret des sauces (noindex)

Vous pourriez voir que nous avons un problème. Nos URL sont disponibles dans deux URL différentes. Oui, nous pouvons utiliser l'attribut canonique pour informer Google quelle URL est notre «principale», mais ne laissons pas le coup à Google pour choisir la bonne.

Tout d'abord, définissez l'ensemble de votre sous-domaine en tant que noindex (la façon de le faire variera selon la plate-forme). Ensuite, dans le travailleur CloudFlare, nous allons ajouter la ligne de code suivante, qui dit essentiellement de supprimer le noindex lorsque l'URL actuelle est accessible via le proxy.

 newResponse.Headers.Delete ("X-Robots-Tag");

La solution de code complète est fournie à la fin de cet article.

Étape 5: Modifiez le plan du site

La dernière chose à faire est de modifier le site de site du sous-domaine afin qu'il n'utilise pas le sous-domaine. La façon de le faire variera selon la plate-forme, mais l'objectif est de modifier la base / absolu / domaine dans votre site de site afin qu'il imprime example.com/mypost) au lieu de blog.exmaple.com/mypost. Certains plugins et modules le permettront sans code personnalisé.

C'est ça! La solution devrait fonctionner!

Limites

Cette magie de Cloudflare n'est pas sans ses inconvénients. Par exemple, il accepte uniquement les demandes d'obtention, ce qui signifie que nous ne pouvons obtenir des choses du serveur. Nous ne pouvons pas publier ce que les formulaires utilisent. Donc, si vous avez besoin que vos visiteurs se connectent ou soumettent des formulaires, il y aura plus de travail en plus de ce que nous avons déjà fait. J'ai discuté de plusieurs solutions pour cela dans un autre article.

Comme indiqué précédemment, une autre limitation est que l'utilisation de cette approche sur Shopify nécessite de s'abonner au niveau de tarification Enterprise de CloudFlare. Encore une fois, c'est parce que Shopify utilise également CloudFlare et restreint la possibilité de proxyer le trafic sur leurs autres plans.

Vous pourriez également obtenir des problèmes si vous essayez de fusionner deux instances des mêmes plates-formes ensemble (par exemple, votre domaine de haut niveau et votre sous-domaine utilisent WordPress). Mais dans un cas comme celui-là, vous devriez être en mesure de consolider et d'utiliser une instance de la plate-forme.

Solution complète

Voici le code dans toute sa gloire:

 // Écoutez chaque demande et répondez avec notre fonction.
// Remarque, cela s'exécutera uniquement sur les routes configurées dans CloudFlare.
addEventListener ('fetch', fonction (événement) {
  event.RespondWith (handlerequest (event.request))
})
// notre fonction pour gérer la réponse.
Fonction asynchrone handlerequest (request) {
  // Obtenez uniquement des demandes de travail avec ce proxy.
  if (request.method! == 'get') return méthodyNotAllowed (request);
  // L'URL qui est demandée.
  const url = new URL (request.url);
  // Demande "URL d'origine" aka le vrai blog au lieu de ce qui a été demandé.
  // Cela change l'URL absolue, laissant le chemin relatif inchangé. 
  const OriginUrl = url.toString () .replace ('https://example.com', 'https://blog.example.com');
  // Le contenu de la page d'origine.
  const OriginPage = Await Fetch (OriginUrl);
  // Donnez à la réponse notre page d'origine.
  const newResponse = new Response (OriginPage.Body, OriginPage);
  // Supprimez "NOINDEX" du domaine d'origine.
  newResponse.Headers.Delete ("X-Robots-Tag");
  // Supprime le cache CloudFlare car il est destiné à WordPress.
  // Si vous utilisez CloudFlare APO et que votre blog n'est pas WordPress (mais
  // Votre domaine principal est), puis empêchez APO de fonctionner sur votre URL d'origine.
  // newResponse.heders.set ("cf-edge-cache", "no-cache"); return newResponse; 
}
// Hé! Obtenez les demandes uniquement 
Fonction MethodNotAllowed (demande) {
  return new Response (`Méthode $ {request.method} non autorisé.`, {
    Statut: 405,
    En-têtes:
    {'Permettre': 'get'}
  })
}

Si vous avez besoin d'aide en cours de route, je vous invite à vous contacter via mon site Web createToday.io ou consulter mon YouTube pour une démonstration vidéo.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!