[suggestion] [sitemap] datage des pages statiques (et robots.txt)

KyodevKyodev Member
avril 2014 modifié dans Discussions générales
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:
[== 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

Réponses

  • bazooka07bazooka07 PluXml Lead Developer, Moderator
    avril 2014 modifié
    Bonjour cher voisin ;)

    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 :
    [== Indéfini ==]
    User-agent: *
    Disallow: /core/
    Disallow: /data/
    Disallow: /plugins/
    Disallow: /themes/
    

    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, ...)
  • StéphaneStéphane Member, Former PluXml Project Manager
    Pour le robots.txt c'est pris en compte issue #67

    Pour le sitemap également issue #68

    Merci à tous les deux

    Consultant PluXml

    Ancien responsable et développeur de PluXml (2010 à 2018)

  • hello
    bazooka07 a écrit:
    D'après robots-txt.com, robots.txt sert à exclure l'indexation d'une partie d'un site Web. Donc quand je vois la directive allow ça me laisse perplexe.
    robots-txt.com parle de convention. robots.txt sert aussi à localiser le sitemap
    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
  • KyodevKyodev Member
    avril 2014 modifié
    [h]datage de l'accueil ( page statique ou article)[/h]

    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:
    [== PHP ==]
     	<url>
    		<loc><?php echo $plxMotor->urlRewrite() ?></loc>
    		<changefreq>monthly</changefreq>
    		<priority>0.8</priority>
    	</url>
    
    
    [== PHP ==]
    # L'accueil
    /*
    * Par défaut, le datage de l'accueil se fera sur le dernier article publié. Pour tenir compte de la date de l'article de la catégorie home, 
    * ou si existant d'un article nommé edito.xml, décommenter la suite suivante ou modifier le fichier data/configuration/parametres.xml
    * en ajoutant une ligne <parametre name="lastArtIndexSitemap">0</parametre>
    */
    # $plxMotor->aConf['lastArtIndexSitemap']=0;
    if ( !isset($plxMotor->aConf['lastArtIndexSitemap']) ) $plxMotor->aConf['lastArtIndexSitemap']=1;
    $k_homeStatic = $plxMotor->aConf['homestatic'];
    if ( $k_homeStatic == '' ){			//##\\ article en accueil via home.php
    	if ( $plxMotor->aConf['lastArtIndexSitemap'] ) {	//## datage du dernier article pour l'accueil (home.php publiant les derniers articles par exemple)
    		ob_start();
    			$plxShow->lastArtList('#art_id',1);
    			$k_id = ob_get_contents();
    		ob_end_clean();
    		$k_id = str_pad( $k_id, 4, '0', STR_PAD_LEFT);
    		$k_lastmod=gmdate('Y-m-d\TH:i:s\Z', filemtime(glob(PLX_ROOT.$plxMotor->aConf['racine_articles'].$k_id.'.*')[0]));
    	} else {											//## datage article edito ou catégorie home le plus récent 
    		$ou_home=glob(PLX_ROOT.$plxMotor->aConf['racine_articles'].'[0-9][0-9][0-9][0-9].*.xml', GLOB_BRACE);	// cible article comme home
    		$ou_edito=glob(PLX_ROOT.$plxMotor->aConf['racine_articles'].'*edito.xml');								// cible edito
    		if ( filemtime($ou_home[0]) > filemtime($ou_edito[0]) ) $k_lastmod=filemtime($ou_home[0]); else $k_lastmod=filemtime($ou_edito[0]);
    		$k_lastmod=gmdate('Y-m-d\TH:i:s\Z', $k_lastmod);
    	}
    } else {							//##\\ page statique en accueil
    	$ouEstLeFichier = PLX_ROOT.$plxMotor->aConf['racine_statiques'].$k_homeStatic.'.'.$plxMotor->aStats[$k_homeStatic]['url'].'.php';
    	$k_lastmod = gmdate('Y-m-d\TH:i:s\Z', filemtime($ouEstLeFichier));
    }
    echo "\t<url>\n";
    echo "\t\t<loc>".$plxMotor->urlRewrite()."</loc>\n";
    echo "\t\t<lastmod>$k_lastmod</lastmod>\n";
    echo "\t\t<changefreq>monthly</changefreq>\n";
    echo "\t\t<priority>0.8</priority>\n";	//toutes les priority & les changefreq ont été homogénéisé à 0.8/monthly (comme plugin search & contact)
    echo "\t</url>\n";
    

    résultats pour une page statique en accueil:
    <url>
    <loc>http://www.exemple.fr/</loc>;
    <lastmod>2014-04-11T08:02:32Z</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
    </url>
    pour un article:
    <url>
    <loc>http://www.exemple.fr/</loc>;
    <lastmod>2014-04-13T09:31:33Z</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
    </url>
  • KyodevKyodev Member
    avril 2014 modifié
    [h]datage des catégories[/h]

    à 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:
    [== PHP ==]
    # Les catégories
    foreach($plxMotor->aCats as $cat_num => $cat_info) {
    ...
    eval($plxMotor->plxPlugins->callHook('SitemapCategories'));
    
    par
    [== PHP ==]
    # Les catégories
    //attention plxShow doit être crée et lancé auparavant
    foreach($plxMotor->aCats as $cat_num => $cat_info) {
    	if ( $cat_info[menu] == 'oui' && $cat_info[active] == '1' ) {
    		ob_start();
    			$plxShow->lastArtList('#art_id',1,$cat_num); 	// id du dernier article de la catégorie (le plus récent donc)
    			$k_id = ob_get_contents();
    		ob_end_clean();
    		$k_id = str_pad( $k_id, 4, '0', STR_PAD_LEFT);		// id sur 4 caractères, complété à gauche par des 0
    		$ouEstLeFichier=PLX_ROOT.$plxMotor->aConf['racine_articles'].$k_id.'.*';	// répertoire à scruter
    		echo "\n";
    		echo "\t<url>\n";
    		echo "\t\t<loc>".$plxMotor->urlRewrite("?categorie".intval($cat_num)."/".$cat_info['url'])."</loc>\n";
    		echo "\t\t<lastmod>".gmdate('Y-m-d\TH:i:s\Z', filemtime(glob($ouEstLeFichier)[0]))."</lastmod>\n";
    		echo "\t\t<changefreq>monthly</changefreq>\n";
    		echo "\t\t<priority>0.8</priority>\n";
    		echo "\t</url>\n";
    	}
    }
    eval($plxMotor->plxPlugins->callHook('SitemapCategories'));
    
  • [h]datage des articles[/h]
    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:
    [== PHP ==]
    /*
    dans le bloc 'Les articles', remplacer
    	echo "\t\t<lastmod>".plxDate::formatDate($plxRecord_arts->f('date'),'#num_year(4)-#num_month-#num_day')."</lastmod>\n";
    par :
    */
    	echo "\t\t<lastmod>".gmdate('Y-m-d\TH:i:s\Z',filemtime($plxRecord_arts->f('filename')))."</lastmod>\n";
    

    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).
Connectez-vous ou Inscrivez-vous pour répondre.