[suggestion] [sitemap] datage des pages statiques (et robots.txt)
Kyodev
Member
bonjour,
je découvre, je teste, je critique
j'ai été surpris de voir que les pages statiques n'étaient pas datées dans le sitemap. je sais (http://www.sitemaps.org/fr/protocol.html) que ce datage est facultatif, mais j'aime à croire que c'est utile au niveau seo.
j'ai pour habitude de fournir la date de modification du fichier dans la balise <lastmod>. avec la méthode La Rache, j'ai modifié rapidement sitemap.php comme cela:
la remarque serait valable pour les catégories, mais là je vois pas de solution simple
dernière suggestion, pourquoi ne pas proposer en standard un fichier robots.txt basique?:
histoire de faciliter la vie aux débutants
[Edit]utilisation variable pluXml pour localiser le répertoire des pages statiques
je découvre, je teste, je critique
j'ai été surpris de voir que les pages statiques n'étaient pas datées dans le sitemap. je sais (http://www.sitemaps.org/fr/protocol.html) que ce datage est facultatif, mais j'aime à croire que c'est utile au niveau seo.
j'ai pour habitude de fournir la date de modification du fichier dans la balise <lastmod>. avec la méthode La Rache, j'ai modifié rapidement sitemap.php comme cela:
[== PHP ==]
/* 2 lignes à placer après echo "\t\t<loc>".$plxMotor->urlRewrite("?static".intval($stat_num)."/".$stat_info['url'])."</loc>\n";
vers la ligne n°66
*/
$ouEstLeFichier = PLX_ROOT.$plxMotor->aConf['racine_statiques'].$stat_num.'.'.$stat_info['url'].'.php';
echo "\t\t<lastmod>".gmdate('Y-m-d\TH:i:s\Z', filemtime($ouEstLeFichier))."</lastmod>\n";
ça marche, mais je ne prétends pas que ce code soit optimal dans pluXml, juste là pour inspiration. ce qui me donne bien
[== XML ==]
<url>
<loc>http://www.exemple.fr/index-static.html</loc>
<lastmod>2014-04-09T12:37:56Z</lastmod>
<changefreq>monthly</changefreq>
<priority>0.8</priority>
</url>
la remarque serait valable pour les catégories, mais là je vois pas de solution simple
dernière suggestion, pourquoi ne pas proposer en standard un fichier robots.txt basique?:
[== Text ==]
User-Agent: *
Allow: /
Sitemap: http://www.exemple.fr/sitemap.php
histoire de faciliter la vie aux débutants
[Edit]utilisation variable pluXml pour localiser le répertoire des pages statiques
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
D'après ce lien, robots.txt sert à exclure l'indexation d'une partie d'un site Web.
Donc quand je vois la directive allow ça me laisse perplexe.
C'est vrai qu'il pourrait y avoir un fichier robots.txt livré avec Pluxml.
Voici ce que je mets dans robots.txt :
Le plus important me semble être le 1er disallow. Inutile d'indiquer le chemin vers la partie admin à nos gentils hackers. Déjà qu'on leur met un panneau indicateur en bas de chaque page.
D'autant qu'il n'y a rien contre une attaque en force brute (pas d'anti-spam, pas ce comptage de tentatives d'accès avec la même ip, pas de temps de latence, ...)
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Pour le sitemap également issue #68
Merci à tous les deux
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
une autre convention (faire une recherche sur Allow) le permet.
amha, le débat est d'un intérêt quasi proche du zéro. ça fait 10 ans que je le fais, parce que m. Google (qui est toujours mon plus gros surfeur) le permet, que ça correspond à mon goût et que ça ne m'a jamais pénalisé. mais c'est sans importance.
je suis beaucoup moins chaud sur les directives disallow. les hackers se contrefichent des directives, au contraire, c'est même leur gagner du temps dans leur recherche.
de toutes façons, pluXml ne camouflant pas la localisation exacte des fichiers (léger défaut), c'est illusoire de compter sur robots.txt.
raisonnement quasi identique pour les mauvais bots.
par exemple, je n'ai pas aperçu d'url avec /core, donc ton fichier permet d'agrandir la zone de recherche pour les malins
robots.txt n'est pas un outil de sécurité, juste une indication pour les honnêtes. pour les datas sensibles et les répertoires core, c'est plus le role du serveur (htaccess)
surtout, l'autre intérêt, c'est de déclarer automatiquement le sitemap, sans rien faire (c'est moins rapide, je sais, mais combien de débutants savent déclarer leur sitemap, et où?), notamment à la multitude de bots peu connus et ne disposant pas d'interface de déclaration (j'ai ajouté un commentaire dans l'issue #67)
@stéphane, merci de tenir compte de nos remarques et félicitations pour ton travail
je me suis aussi rendu compte que la page d'accueil n'était pas datée. me reste à trouver comment améliorer cela aussi
par défaut, date de modification du fichier du dernier article
sur option, la date de modification la plus récente entre un article dont l'url est edito ou un article déclaré comme page d'accueil (catégorie home) (date de modification du fichier)
si page statique comme accueil, date de modification de ce fichier
code initial à remplacer:
résultats pour une page statique en accueil: pour un article:
à mon goût, si les catégories apparaissent dans le sitemap, autant qu'elles soient datées, avec la date du dernier article en faisant partie.
toujours à mon goût, tant qu'à faire, autant utiliser la date de modification de l'article (et non pas celle de la création).
pour ce faire, remplacer le bloc: par
toujours à mon goût,au lieu de prendre en compte une date de publication que l'on doit manuellement modifier au besoin, je préfère actualiser automatiquement la balise <lastmod> avec la date de modification du fichier xml de l'article, soit:
voilà, je me retrouve avec un sitemap automatiquement au plus "réactif", à même de refléter au plus juste le dynamisme d'un site (utile pour certains moteurs).