79 votes

Quelle est la meilleure approche pour la redirection des anciennes pages dans Jekyll et GitHub Pages ?

J'ai un blog sur les pages de github - jekyll

Quelle est la meilleure façon de résoudre la migration de la stratégie url ?

J'ai trouvé que la meilleure pratique commune est de créer un htaccess comme ceci

Redirect 301 /programovani/2010/04/git-co-to-je-a-co-s-tim/ /2010/04/05/git-co-to-je-a-co-s-tim.html

Mais cela ne semble pas fonctionner avec Github. Une autre solution que j'ai trouvée est de créer une tâche rake, qui va générer des pages de redirection. Mais comme il s'agit d'un html, il n'est pas en mesure d'envoyer 301 afin que les robots d'exploration ne le reconnaissent pas comme une redirection.

2 votes

72voto

Konrad Podgórski Points 552

La meilleure solution est d'utiliser les deux <meta http-equiv="refresh" y <link rel="canonical" href=

Cela fonctionne très bien, Google Bot a réindexé tout mon site web sous les nouveaux liens sans perdre de positions. Les utilisateurs sont également redirigés vers les nouveaux articles immédiatement.

<meta http-equiv="refresh" content="0; url=http://konradpodgorski.com/blog/2013/10/21/how-i-migrated-my-blog-from-wordpress-to-octopress/">
<link rel="canonical" href="http://konradpodgorski.com/blog/2013/10/21/how-i-migrated-my-blog-from-wordpress-to-octopress/" />

Utilisation de <meta http-equiv="refresh" redirigera chaque visiteur vers le nouveau message. Quant à Google Bot, il traite <link rel="canonical" href= comme la redirection 301, l'effet est que vos pages sont réindexées et c'est ce que vous voulez.

J'ai décrit tout le processus de transfert de mon blog de Wordpress à Octopress ici. http://konradpodgorski.com/blog/2013/10/21/how-i-migrated-my-blog-from-wordpress-to-octopress/#redirect-301-on-github-pages

5 votes

Lors du passage aux pages GitHub, cela a fonctionné pour moi : help.github.com/articles/redirects-on-github-pages . Il semble qu'il fasse tout ce que vous avez mentionné.

0 votes

Est-ce que l'effet de l'utilisation canonical Cela signifie que Google réindexera les pages à partir de zéro ou qu'il transférera le score de classement à la nouvelle page ? Pouvez-vous préciser comment cette approche affecte le classement des pages ?

0 votes

Est-ce que le <meta http-equiv="refresh" provoquer une boucle de redirection infinie ? C'est ce que j'obtiens, peut-être que je fais quelque chose de mal ?

23voto

ms-ati Points 774

Avez-vous essayé le Plugin générateur d'alias pour Jekyll ?

Vous mettez les urls d'alias dans la matière première YAML d'un message :

---
  layout: post
  title: "My Post With Aliases"
  alias: [/first-alias/index.html, /second-alias/index.html]
---

Lorsqu'un utilisateur visite l'une des urls alias, il est redirigé vers l'url principale via un rafraîchissement de la balise méta :

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <meta http-equiv="refresh" content="0;url=/blog/my-post-with-aliases/" />
  </head>
</html>

Voir aussi cet article de blog sur le sujet.

3 votes

Les pages GitHub n'utilisent pas de plugins.

0 votes

@tekknolagi Je ne comprends peut-être pas les pages GitHub. Mais si vous utilisez Jekyll et que vous publiez simplement le site statique sur Github, alors cela devrait fonctionner, car les pages générées incluraient des rafraîchissements de méta pour les anciennes urls ?

0 votes

C'est correct, mais GitHub n'exécutera pas Jekyll avec les plugins, il ne servira que le site statique compilé.

9voto

Chris Ruppel Points 156

Cette solution vous permet d'utiliser de véritables redirections HTTP via .htaccess. Toutefois, rien de ce qui implique .htaccess ne fonctionnera sur les pages GitHub car elles n'utilisent pas Apache.

En date de mai 2014 Les pages GitHub prennent en charge les redirections mais selon le Documentation de Gem jekyll-redirect-from ils sont toujours basés sur HTTP-REFRESH (en utilisant <meta> ), ce qui nécessite le chargement complet d'une page avant que la redirection ne puisse avoir lieu.

Je n'aime pas le <meta> J'ai donc élaboré une solution pour tous ceux qui souhaitent fournir de véritables redirections HTTP 301 dans un fichier .htaccess utilisant Apache, qui sert un site Jekyll pré-généré :


D'abord, ajoutez .htaccess a la include la propriété dans _config.yml

include: [.htaccess]

Ensuite, créez un fichier .htaccess et assurez-vous d'y inclure Première page YAML . Ces tirets sont importants car Jekyll va maintenant analyser le fichier avec Liquid, le langage de modélisation de Jekyll :

---
---
DirectoryIndex index.html

RewriteEngine On
RewriteBase /

...

Assurez-vous que vos articles qui nécessitent des redirections ont deux propriétés comme celles-ci :

---
permalink: /my-new-path/
original: blog/my/old/path.php
---

Maintenant, dans le .htaccess, il suffit d'ajouter une boucle :

{% for post in site.categories.post %}
  RewriteRule ^{{ post.original }} {{ post.permalink }} [R=301,L]
{% endfor %}

Cela permettra de générer dynamiquement le fichier .htaccess à chaque fois que vous construisez le site, et le fichier include dans votre fichier de configuration garantit que le fichier .htaccess sera intégré dans le fichier de configuration. _site répertoire.

RewriteRule ^blog/my/old/path.php /my-new-path/ [R=301,L]

A partir de là, c'est à vous de servir _site en utilisant Apache. Normalement, je clone le dépôt complet de Jekyll dans un répertoire qui n'est pas la racine du web, puis mon serveur virtuel est un lien symbolique vers le dépôt de Jekyll. _site dossier :

ln -s /path/to/my-blog/_site /var/www/vhosts/my-blog.com

Tada ! Apache peut maintenant servir le dossier _site à partir de votre racine virtuelle, avec des redirections alimentées par .htaccess qui utilisent le code de réponse HTTP que vous souhaitez !

Vous pourriez même être super fantaisiste et utiliser un redirect dans la page d'accueil de chaque article pour désigner le code de redirection à utiliser dans votre boucle .htaccess.

0 votes

Cela semble génial ! Mais que se passe-t-il s'il y a plusieurs liens originaux (liens précédents qui atteignent maintenant 404) pour un article ?

2 votes

La solution impliquerait un élément de logique plus complexe lorsque vous générez l'adresse de l'utilisateur. .htaccess fichier. Par exemple, vous pouvez convertir le YAML de manière à ce que original est un tableau au lieu d'une chaîne. Vous avez alors besoin d'une boucle imbriquée pour que chaque original génère une redirection vers permalink . Prenez ce code comme point de départ et expérimentez par vous-même !

0 votes

Merci. J'ai réussi à le faire fonctionner comme vous l'avez suggéré. J'ai utilisé cette méthode pour un tutoriel.

6voto

Tom Clarkson Points 12369

La meilleure solution consiste à éviter tout changement d'url en définissant le format des permaliens dans _config.yml pour qu'il corresponde à celui de votre ancien blog.

Au-delà, la solution la plus complète consiste à générer des pages de redirection, mais cela ne vaut pas forcément la peine. J'ai fini par simplement rendre ma page 404 un peu plus conviviale, avec du javascript pour deviner la nouvelle url correcte. Cela ne fait rien pour la recherche, mais les utilisateurs actuels peuvent accéder à la page qu'ils cherchaient et il n'y a pas de choses anciennes à supporter dans le reste du code.

http://tqcblog.com/2012/11/14/custom-404-page-for-a-github-pages-jekyll-blog/

2voto

Alan W. Smith Points 6704

Étant donné que github n'autorise pas les redirections 301 (ce qui n'est pas surprenant), vous devrez choisir entre migrer vers votre nouvelle structure d'URL (et en subir les conséquences sur les moteurs de recherche) ou laisser les URL telles qu'elles sont. Je vous suggère d'aller de l'avant et de faire le changement. Laissez les moteurs de recherche faire ce qu'ils veulent. Si quelqu'un trouve l'un de vos anciens liens via le moteur de recherche, il sera redirigé vers le nouvel emplacement. Au fil du temps, les moteurs de recherche prendront en compte vos changements.

Une chose que vous pouvez faire pour aider les choses est de créer une Plan du site où vous ne listez que vos nouvelles pages et pas les anciennes. Cela devrait accélérer le remplacement des anciennes URL par les nouvelles. En outre, si toutes vos anciennes URL se trouvent dans votre répertoire '/programovani', vous pouvez également utiliser un fichier de type fichier robots.txt pour indiquer aux futurs crawls qu'ils doivent ignorer ce répertoire. Par exemple :

User-agent: *
Disallow: /programovani/

Il faudra un peu de temps pour que les moteurs de recherche rattrapent les changements. Ce n'est pas vraiment un problème. Tant que les anciennes URL existent toujours et redirigent les internautes vers les pages actives, tout va bien.

0 votes

La SE n'est pas ce qui me dérange. Je reçois des 404 par des liens d'autres sites/forums. J'ai créé de fausses pages avec un temps de rafraîchissement nul qui vont "rediriger" l'utilisateur. Je l'ai testé dans les outils du webmaster et il semble que le crawler soit également satisfait de cela. Mais pas moi ;)

0 votes

Si vous rencontrez toujours des problèmes d'erreurs 404, envoyez-moi un lien vers l'une d'entre elles et j'y jetterai un coup d'œil pour voir ce qui se passe.

0 votes

Pour l'instant, je l'ai résolu par les fausses pages. L'un des anciens 404 était rooland.cz/programovani/2010/04/git-co-to-je-a-co-s-tim . Je les génère de cette manière git.io/UrlZaQ . Le script est terrible, mais il fait ce dont j'ai besoin.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X