Le logiciel de création de site Web avec un système de gestion de contenu (CMS) est toujours idéal pour faire son site internet et surtout effectuer soi-même ses propres mises à jour régulières, de façon intuitive.
Car, certains apparaissent très simples en apparence, mais nécessitent parfois quelques notions de base en HTML. Ne serait-ce que pour pouvoir parfois intervenir à l’intérieur du code source.
Il ne faut donc pas hésiter à faire appel à eux, dès lors qu’il s’agit d’un projet professionnel de grande envergure. Leur aide et leurs conseils vous seront toujours précieux, notamment pour réaliser un site web sur mesure pour vous, et qui sera, en plus, bien optimisé dès le départ pour le référencement Web.
Comme dit plus haut, quelques notions du langage de programmation HTML peuvent s’avérer utiles, voire nécessaires, même si créer un site internet en WYSWYG avec un système de gestion de contenu (CMS) intégré dans la back-office est désormais une pratique courante.
Voici donc le Top 10 des meilleurs logiciels CMS gratuits ou payants pour créer un site professionnel
Classement au 14 Avril 2020 – Source : W3techs.com
WordPress : 35,7% d’usage et 63,1% de part de marché.
Les sites Web sont hébergés, ou stockés, sur des ordinateurs spéciaux appelés serveurs.
nom de domaine dans leur navigateur. Leur ordinateur ou mobile se connectera ensuite à votre serveur et vos pages Web leur seront transmises par le biais du navigateur.
Les différents types de serveurs d\’hébergement internet
Allons plus loin et regardons les principales différences entre un hébergement mutualisé, VPS, dédié et Cloud.
Hébergement mutualisé :
En général, tous les noms de domaine peuvent partager un pool commun de ressources serveur, telles que la RAM et le CPU.
car il nécessite des connaissances techniques minimales.
Inconvénients :
Aucun accès root,
Capacité limitée à gérer des niveaux de trafic élevés ou des pics,
Hébergement sur serveur dédié :
Un serveur dédié offre le contrôle maximal sur le serveur Web sur lequel votre site est stocké.
Vous louez en exclusivité un serveur entier. Votre (vos) site (s) est le seul site Web stocké sur le serveur.
Caractéristiques :
Ce type de serveur est fourni avec une plus grande puissance,
Un coût beaucoup plus élevé qu’avec le serveur mutualisé, même si l’abonnement est généralement mensuel.
Hébergement Virtual Private Server (VPS) :
Inconvénients :
Capacité limitée à gérer des niveaux de trafic élevés ou des pics,
Cloud Hosting :
Le Cloud Hosting ou hébergement cloud offre une capacité illimitée pour gérer des pics de trafic ou de trafic élevés.
Voici comment cela fonctionne : un ensemble de serveurs (appelé nuage ou cloud) travaillent ensemble pour héberger un groupe de sites Web. Cela permet à plusieurs ordinateurs de travailler en commun pour gérer des niveaux de trafic élevés ou des pics pour un site Web particulier.
Inconvénients :
requis pour modifier les paramètres du serveur et installer certains logiciels),
Des coûts plus élevés sont à prévoir,
Les utilisateurs d’hébergement Cloud sont généralement facturés par utilisation.
Comment choisir le bon hébergeur pour votre site Web ?
Il y a des centaines de questions que vous pourriez poser à votre hébergeur Web potentiel.
Et en obtenant les réponses à ces questions avant de vous engager, vous devriez avoir une image claire de ce que vous recevrez, ce que le prestataire offre sur le long terme, comment il traite ses clients (disponibilité du support et moyens de contact) et s’ils sont une entreprise en qui vous pouvez avoir confiance et avoir vraiment envie de travailler avec.
Voici quelques questions que vous pouvez poser.
Quel est le taux de disponibilité mensuelle moyen ?
Combien ça coûte ?
Où sont situés physiquement les serveurs d’hébergement ? Pouvez-vous choisir l\’emplacement de votre serveur ?
Un serveur plus proche de vos utilisateurs permet à votre site Web de charger plus rapidement pour eux.
Quel niveau de support technique ou client est offert ?
Un support client ou technique par téléphone ou par chat disponible 24/7 est à privilégier plutôt qu’un support par email. Vous pourrez ainsi facilement résoudre tout problème technique urgent qui pourrait survenir.
Quels sont les termes et les tarifs de renouvellement ?
Sachez que si vous êtes un abonné pour la première fois, vous devrez probablement vous inscrire à un tarif réduit que pour les changements lorsque vous renouvelez votre contrat. Assurez-vous d’être bien informés pour les années à venir, surtout s’il y a des changements de tarifs en cours de contrat.
Quel types d’évolutions potentielles existe-il ?
Par exemple, si vous démarrez avec un plan de serveur mutualisé, êtes-vous en mesure de développer votre espace plus tard ou même de passer à un environnement de serveur dédié?
Par exemple, si vous démarrez dans une configuration de serveur mutualisé et que vous devez passer à un environnement dédié ou VPS pendant la durée de votre contrat, est-ce autorisé ? Y a-t-il des pénalités ou des frais de migration ?
Sachez que tous les plans illimités ont des limitations. C’est juste une question pour savoir ce que sont ces limitations.
Le prestataire d’hébergement Web offre-t-il un essai gratuit ?
Presque chaque fournisseur offre au moins un essai gratuit allant de 15 à 30 jours, mais certains offrent des délais plus longs. Gardez vos yeux et vos oreilles ouverts et profitez de la période sans engagement pour tester chaque facette du service.
La fonctionnalité est disponible pour les plans Premium et Business sur WordPress.com et sur tout site ou blog WordPress utilisant la version 5.2 ou supérieure de Jetpack.
La solution apportée par Automattic, propriétaire de la plateforme d’hébergement WordPress.com et de Jetpack, va donc permettre à tout site WordPress de vendre des articles individuels
Notons toutefois que WordPress supportait déjà les paiements via PayPal, mais la mise en place nécessitait un long processus en 9 étapes, en commençant par aller chercher votre code pour le bouton PayPal.
Et c’est là où intervient la nouveauté dans ce bouton PayPal intégré qui est désormais plus facile et rapide à créer depuis WordPress, avec pour objectif de ramener l’ancien processus de 15 minutes de durée à tout juste 1 minute.
Le résultat de l\’œuvre est un simple bouton PayPal qui peut être inséré à partir d\’un menu déroulant dans n\’importe quel nouveau post WordPress.
Lorsque vous cliquez sur \ »Ajouter un bouton de paiement\ », vous serez invité à inclure les détails de ce que vous vendez (nom, description et prix du produit), avant d’ajouter l\’adresse e-mail du compte PayPal associé.
Et c\’est tout. Vous pouvez ensuite insérer le bouton Acheter de PayPal et la description du produit sur n\’importe quelle page individuelle de votre site WordPress. Ce qui pourrait donner ceci :
Lorsqu\’un visiteur clique sur le bouton \ »Payer avec PayPal\ », il sera guidé par le processus de paiement PayPal habituel.
Une fois de plus, cette fonction de vente en ligne facilitée avec le bouton Acheter PayPal est actuellement limitée à ceux qui ont un abonnement Premium et Business sur la plateforme WordPress.com et à ceux qui utilisent les outils Jeckpack depuis la page d’administration de leurs propres sites WordPress.
Et peut-être détourner les sites touchés à distance.
Découverte par l\’équipe de Sucuri, WP Statistics est vulnérable à la faille d\’injection SQL qui permet à un attaquant distant, avec au moins un compte d\’abonné, de voler des informations sensibles à partir de la base de données du site Web et éventuellement obtenir un accès non autorisé à des sites Web.
D’autre part, l’injection SQL est un bug d\’application Web qui permet aux pirates informatiques d\’injecter du code SQL malveillant sur les entrées Web afin de déterminer l\’emplacement des bases de données clés, ce qui permet éventuellement aussi de voler la base de données.
Cette vulnérabilité dans WP Statistics réside dans de multiples fonctions WordPress, y compris wp_statistics_searchengine_query().
Les chercheurs en sécurité informatique de Sucuri précisent :
Cette vulnérabilité est causée par le manque de “désinfection” dans les données fournies par l\’utilisateur.
Certains attributs du shortcode“wpstatistics” sont passés en tant que paramètres pour les fonctions importantes et cela ne devrait pas être un problème si ces paramètres ont été désinfectés.
L\’une des fonctions vulnérables wp_statistics_searchengine_query () dans le fichier “URincludes/Functions/functions.php” est accessible via la fonctionnalité Ajax de WordPress grâce à la fonction du core ”wp_ajax_parse_media_shortcode ()”.
Cette fonction ne vérifie donc pas les privilèges supplémentaires, permettant aux abonnés d\’exécuter ce shortcode “wpstatistics” et injecter des données malveillantes à ses attributs.
Et la fonction wp_statistics_searchengine_query () retourne fondamentalement la même valeur que celle passée dans le fournisseur d\’attribut du shortcode “wpstatistics” et son contenu est ajouté directement à la requête SQL brute.
WordPress qui n’ont pas encore appliqué le récent correctif concernant une vulnérabilité critique.
Il s’agit d’une affaire tellement sérieuse que Google a commencé à avertir certains webmasters de blogs WordPress, via la Search Console et par email, qu’il a découvert une faille de sécurité sur leurs blogs WordPress, avant de leur conseiller de les mettre à jour.
Le 26 janvier dernier, WordPress publié la version 4.7.2 dans laquelle figurait un correctif de sécurité pour une vulnérabilité critique qui permet aux pirates de modifier le contenu sur un site WordPress.
Ils n’avaient pas en ce moment là annoncé l’existence d’un correctif très important afin que les pirates ne soient pas conscients de la vulnérabilité pendant que le mécanisme de mise à jour automatique de WordPress aient mis à à jour les sites vulnérables.
Le correctif de sécurité caché, jusque là, a finalement été révélé le 1er février 2017, soit 6 jours plus tard, une période au cours de laquelle les pirates avait déjà pris connaissance de l’exploit ou faille de sécurité.
À cette période là, un grand nombre de sites Web WordPress avait déjà migré vers la version 4.7.2 (la plus récente).
Et, comme il fallait s’y attendre, à compter du 3 Février, les services de sécurité informatique ont commencé à constater une multiplication des attaques ciblant la vulnérabilité de l’API REST.
Une API compatible RESTGET), placer (PUT), publier (POST) et supprimer (DELETE) des données.
La vulnérabilité, située dans l’API REST de la plateforme, permet donc, selon Computerworld.com, à des attaquants non authentifiés de modifier le contenu de n’importe quel article ou page d’un site WordPress.
La faille a été corrigée dans la version WordPress 4.7.2, sortie le 26 janvier, mais l’équipe de WordPress ne divulgue pas publiquement l’existence de la vulnérabilité avant une semaine plus tard, afin de permettre à un grand nombre d’utilisateurs d’avoir le temps de déployer la mise à jour.
Cependant, même après que la faille soit devenue publique, beaucoup de webmasters n’avaient pas encore décidé d’appliquer le patch. Et il s’en est suivi une vague impressionnante de piratages des sites et blogs WordPress non mis à jour.
Le lundi 6 Février, l’entreprise de sécurité Web dénommée Sucuri a signalé qu’environ 67.000 pages avaient été effacées dans les 4 vagues d’attaques distinctes contre des sites WordPress.
Depuis lors, le nombre de pages supprimées a augmenté de plus 1,5 millions et il y a 20 signatures d’attaques différentes, selon les chiffres de Feedjit, l’entreprise derrière le plugin WordPress de sécurité Wordfence.
Le nombre de sites uniques touchés était alors estimé à environ 40.000, en considérant toutefois qu’un site peut avoir plusieurs pages corrompues ou supprimées.
Le Jeudi 9 Février dernier, le PDG de Feedjit a publié un autre post pour dire :
En 48 heures, nous avons constaté plus de 800.000 attaques exploitant cette vulnérabilité spécifique à travers les sites WordPress que nous surveillons.
Bref, l’heure est grave. Vous devez donc comprendre que si WordPress vous propose une version récente, vous devez absolument migrer votre site vers cette nouvelle version.
Car, les pirates profitent justement du temps d’attente de nombreux webmasters, et donc de la mise à jour souvent tardive et non immédiate, pour sévir et compromettre les sites WordPress.
connaissent déjà la faille de sécurité que permet de corriger chaque nouvelle version de WordPress. Alors, il ne leur reste plus qu\’à chercher les sites non mis à jour.
Alors, si ce n’est pas encore fait, téléchargez la version 4.7.2 de WordPress et mettez à jour votre site ou blog.
WordPress recommande vivement à tous ses utilisateurs de mettre rapidement à jour leur site avec la récente version 4.4.1.
une version de sécurité pour toutes les versions précédentes. En effet, selon WordPress, toutes les versions 4.4 et antérieures sont affectées par une vulnérabilité de type cross-site scripting qui pourrait permettre à une personne mal intentionnée de compromettre votre site ou blog.
Si le langage JavaScript est utilisé, il est alors possible :
de récupérer les cookies présent sur la machine victime,
Les risques liés à cette vulnérabilité sont donc nombreux : déni de service de la machine victime, utilisation de la machine victime à des fins malveillantes, récupération de données personnelles.
D’où l’intérêt de migrer rapidement votre site ou blog WordPress vers la version 4.4.1.
De plus, WordPress 4.4.1 corrige 52 bugs de la précédente version 4.4 ! Rendez-vous donc immédiatement dans votre page d’administration pour effectuer votre mise à jour ou téléchargez ici la dernière version.
L’organisation Let’s Encrypt annonce que ses certificats de sécurité gratuits ont maintenant été approuvés par tous les principaux navigateurs web.
Il s’agit donc de l’ultime étape qui va permettre à cette organisation d’assurer sa mission de sécurisation gratuite à l\’aide du protocole HTTPS tous les sites web.
En tant qu’autorité de certification ouverte proposée par Internet Security Research Group (ISRG) et sponsorisée par des entreprises telles que Mozilla et Automattic (WordPress.com), Let’s Encrypt vise à équiper les sites web légitimes de toute taille avec des certificats TLS/SSL permettant aux navigateurs de les identifier correctement et de chiffrer (cryptage) les données, activités et transactions des utilisateurs afin de les protéger contre tout piratage.
Let’s Encrypt a a publié son premier certificat en Septembre dernier et a maintenant reçu les signatures du fournisseur de certificats SSL “IdenTrust”. Il peut donc commencer à les distribuer plus largement aux sites web et permettre ainsi aux utilisateurs de naviguer en toute sécurité sur ces sites.
Let’s Encrypt commencera à délivrer des certificats SSL gratuits à partir du mois de Novembre 2015. Ce qui devrait aider les sites à adopter plus facilement le chiffrement HTTPS tout en réduisant de façon significative les coûts d’installation.
Rappelons que Google a déjà déclaré l’hébergement sécurisé HTTPS comme facteur de référencement et que cette annonce pourrait bientôt le pousser à déclarer ce critère comme globalement effectif pour accélérer son adoption.
D’ailleurs, Google procède actuellement à la migration des sites de sa plateforme Blogger vers le HTTPS .
Il s’agit d’inciter et encourager les développeurs et les éditeurs de contenus à adopter dans leurs sites web et dans leurs applications mobiles (si, si) la technologie dite AMP HTML et d’en faire un nouveau format de page web mobile.
Objectif initial de Google AMP
L’objectif escompté par Google en lançant cette initiative, c’est d’obtenir autant de réactions qu’il y en a eu lors de la divulgation du “responsive design” qui adapte automatiquement les pages web à la taille de l’écran de l’utilisateur.
Selon Google, la technologie AMP HTML va considérablement améliorer la performance du web mobile en permettant aux éditeurs web de créer des pages web très allégées.
Lesquelles pages allégées pourraient alors réduire les nuisances ou lourdeurs des technologies telles que le JavaScript.
En adoptant l’Accelerated Mobile Pages, les éditeurs pourront utiliser les techniques de cache et de stockage des pages web de Google pour afficher instantanément leurs contenus sur le web mobile et dans les applications mobiles, quel que soit le mobile utilisé.
Et, tout comme Nuzzel, ils pourront faire afficher ces contenus mobiles en quelques millisecondes contre 5 à 10 secondes, voire plus, habituellement. Ce qui n’est pas rien sur mobile.
AMP étant un projet open source, il est disponible sur le site GitHub et tous les développeurs et éditeurs peuvent apporter leurs contributions, bénévolement s’entend.
Comment AMP accélère les pages sur le web mobile ?
Rappelons-le, l’usage de l’AMP HTML va permettre aux sites web de créer des versions allégées de leurs pages web que Google se chargera de distribuer pour eux via son cache, pendant que ces sites seront toujours hébergés dans leurs espaces web habituels.
Selon Google, l’Accelerated Mobile Pages (AMP) se présente comme une autre page web, mais débarrassée de toutes les fonctionnalités qui ralentissent son affichage. Ainsi, comme toute autre page web, le fichier AMP se chargera dans tout navigateur ou toute application. Mais plus rapidement.
Les fichiers AMP vont profiter de diverses approches techniques et architecturales pour donner la priorité à la vitesse de chargement afin d’aboutir à une expérience plus rapide pour les utilisateurs. Il s’agit donc de réduire la distance entre l’utilisateur et le serveur de chargement du contenu demandé. Ce qui, inéluctablement a une incidence sur le temps de réponse.
Google a aussi clairement déclaré que pour sa part, l’utilisation de son cache sera gratuitement offerte. Et d’autres plateformes pourront développer leurs propres caches.
Espérons que de nombreux CMS acceptent de jouer le jeu, comme WordPress.com qui annonce tester son plugin AMP.
Qu’en est-il des publicités dans AMP ?
Autant Google ne veut pas garantir que toutes les technologies publicitaires fonctionneront correctement dans les fichier AMP, autant il espère au fil du temps implémenter de nouvelles fonctionnalités qui permettront d’intégrer plus facilement toutes les technologies dans ce format AMP.
Toutefois, le but du projet Accelerated Mobile Pages est aussi de permettre une continuité effective de la monétisation via les publicités sur mobile tout en tenant compte des préoccupations des utilisateurs.
Donc, certaines publicités disponibles sur le web pourraient ne pas être affichées par AMP, surtout si elle mettent à mal l’expérience utilisateur.
Mais, tous les trackers, tags analytics et autres JavaScripts passeront dans un premier temps à la trappe avant qu’une solution ne soit trouvée avec les partenaires qui seraient seuls à fournir des statistiques sur leurs plateformes.
Quid des résultats de recherche dans Google mobile
Google Search sur mobile sera également un peu différent.
Non seulement les pages web des éditeurs participants se chargeront plus vite depuis la page de résultats de Google, mais les personnes effectuant des recherches sur mobile concernant des sujets d’actualité verront s’afficher, tout en haut de la page de résultats, une section “Top Stories” (Top Actualités ou Top Articles) avec un carrousel intégrant des articles et des images qu’ils pourront faire défiler horizontalement.
Et s’il n’y a aucun résultat compatible avec l’AMP, Google Search mobile affichera un listing de résultats, comme dans la deuxième image de ce post, mais toujours dans une section “A la une”.
C’est pourquoi Google se veut rassurant en disant qu’en aucun cas les pages AMP ne seraient favorisées par rapport aux autres pages mobiles. Et pourtant, l’algorithme de classement de Google mobile les favorisera automatiquement en raison de leur très faible temps de chargement.
Quant à Twitter, l’AMP va lui permettre d’afficher correctement les Tweets intégrés dans les contenus mobiles. Et les liens cliqués s’afficheront aussi instantanément.
, depuis votre mobile, tapez l’URL suivante : http://g.co/ampdemo. Et tapez, par exemple, “today’s news”.
C’est peut-être la prochaine page d’accueil de Google Search mobile adaptée aux fichiers AMP en cache que tout le monde utilisera bientôt.
Selon une certaine légende SEO qui perdure, de nombreuses pages à l’intérieur d’un site web renvoyant un code erreur 404, parce qu’introuvables, seraient un mauvais signal pouvant pénaliser le référencement dudit site.
Bien entendu, pour une bonne expérience utilisateur de vos visiteurs, il est préférable de faire en sorte que ces derniers ne tombent pas sur de telles pages.
Il est donc normalement recommandé de mettre en place des redirections si le contenu a changé d’adresse, surtout lors d’une migration du site ou s’il a été remplacé par un autre contenu actualisé, ou encore s’il n’existe même pas sur le site..
Non, si l’on en croit le Tweet ci-dessous de +Gary Illyes, Webmaster Trends Analyst chez Google :
Si vous vous faîtes à l’idée qu’avoir des erreurs 404 génère une quelconque pénalité, vous vous trompez. Vous avez tout à fait tort.
Ce qui est somme toute logique. Car, à l’heure du negative SEO, il suffirait qu’une personne de mauvaise foi ou un concurrent pointe des liens fictifs ou incorrectement transcrits vers des contenus qui existent ou n’existent même pas sur votre site pour que votre référencement s’en trouve pénalisé.
D’autre part, l’erreur 404 peut être due à un bug ou une panne technique du support CMS (WordPress, par exemple), ou à une mauvaise configuration du serveur ou encore à une mauvaise configuration lors d’une migration vers un serveur sécurisé HTTPS ou lors d’une refonte du site
Autant de raisons qui ne sauraient donc justifier qu’un site soit pénalisé.
D’ailleurs, dans sa page d’aide relative aux “erreurs de type page introuvable (404)”, Google confirme bien les propos de Gary Illyes en ces termes :
aucune incidence négative sur les performances de votre site dans les résultats de recherche Google. Vous pouvez les ignorer sans problème.
Toujours est-il qu’avoir une bonne page d’erreur personnalisée avec un moteur de recherche interne pourrait aider vos visiteurs à retrouver le contenu recherché. Et ils vous en sauront gré de les avoir aidés.
Google Search Console a commencé à envoyer à de nombreux webmasters des messages d’alerte par email les notifiant de l’impossibilité pour Googlebot, le robot d’indexation de Google, d’explorer librement certains fichiers.
Ce qui pourrait impacter le référencement de leurs sites web.
Ces fichiers généralement mentionnés par Google concernent les CSS et autres JavaScripts qui n’autorisent pas l’accès à leurs données.
Voici un exemple de message reçu par certains webmasters :
Plus particulièrement, Googlebot ne peut accéder à vos fichiers JavaScript ou CSS
Le message d’alerte indique également avec insistance que le blocage des fichiers Javascript et/ou CSS “peut entraîner des classements qui ne soient pas optimaux”.
Alors que Google a fait savoir, après un changement de ses consignes aux webmasters, de ne plus jamais bloquer Googlebot lors de ses visites d’exploration et d’indexation. Notamment via le fichier robots.txt.
Pour nous aider à comprendre le contenu de votre site de manière exhaustive,
Comment découvrir les ressources bloquées par robots.txt
Les ressources bloquées sont aussi mises en évidence dans la section “Index Google” -> “Ressources bloquées” dans votre Google Search Console.
Le message d’alerte dans Google Search Console fournit aussi les détails sur la façon de résoudre le problème en proposant toutefois de mettre à jour la règle du fichier robots.txt pour débloquer la ressource.
Et ils sont aussi nombreux, les webmasters qui utilisent WordPress, qui ont reçu des avertissements pour avoir utilisé “abusivement” l’instruction “Disallow: /wp-content/plugins” dans leur fichier robots.txt.
Voici les différents types d’instructions qui peuvent générer un message d’alerte dans Google Search Console et par email :
Disallow: /.js$*
Disallow: /.inc$*
Disallow: /.css$*
Disallow: /.php$*
Disallow: /wp-content/plugins
Disallow: /wp-content/cache
Disallow: /wp-content/themes
Disallow: /cgi-bin/
Disallow: /wp-content/uploads/
Disallow: /wp-includes/css/
Disallow: /wp-includes/js/
Disallow: /wp-includes/images/
Ce que demande donc Google dorénavant, c’est qu’il n’y ait plus dans aucun fichier robots.txt d’instructions du type “Disallow: /nomdufichier” ou “Disallow: /nomdurepertoire/”.
Si vous en avez dans votre fichier robots.txt, supprimez-les immédiatement, remplacez-les par \ »Allow: /\ » et le problème sera résolu. Sinon, votre référencement pourrait en souffrir comme Google le mentionne dans ses notifications.
Testez votre fichier robots.txt
L\’outil de test du fichier robots.txt vous indique si votre fichier robots.txt empêche nos robots d\’explorer des URL spécifiques sur votre site.
Depuis la page d\’accueil de la Search Console, sélectionnez le site dont vous souhaitez tester le fichier robots.txt.
Sous l\’en-tête \ »Exploration\ » du tableau de bord de gauche, sélectionnez l\’Outil de test du fichier robots.txt.
Apportez des modifications à votre fichier robots.txt en ligne dans l\’éditeur de texte.
Faites défiler le code du fichier robots.txt pour localiser les avertissements relatifs à la syntaxe et les erreurs de logique signalés. Le nombre d\’avertissements relatifs à la syntaxe et d\’erreurs de logique s\’affiche immédiatement sous l\’éditeur.
Saisissez une extension de l\’URL ou un chemin d\’accès dans la zone de texte en bas de la page.
Dans la liste déroulante à droite de la zone de texte, sélectionnez le user-agent que vous souhaitez simuler.
Cliquez sur le bouton TEST après avoir choisi le robot pour lancer la simulation.
Vérifiez si le bouton TEST indique Acceptée ou Bloquée pour savoir si nos robots d\’exploration peuvent ou non explorer cette URL.
Chargement des commentaires…
Vous devez être connecté pour poster un commentaire.
Vous devez être connecté pour poster un commentaire.