Je pense que vous avez quelque chose de mal donc je vais essayer d'expliquer ce qui se passe ici, y compris l'arrière-plan et les alternatives. C'est en effet un sujet très important sur lequel la plupart d'entre nous sommes tombés (ou du moins quelque chose de similaire) de temps en temps. Utiliser AJAX ou plutôt la mise à jour incrémentielle asynchrone des pages (parce que la plupart des pages n'utilisent pas XML mais JSON) a enrichi le web et fourni une grande expérience utilisateur.
Il a cependant aussi un prix.
Le principal problème était les clients qui ne prenaient pas en charge l'objet xmlhttpget ou JavaScript. Au début, vous deviez fournir une compatibilité ascendante. Cela a généralement été fait en fournissant des liens et capturer l'événement onclick et déclencher un appel AJAX au lieu de recharger la page (si le client le prenait en charge).
Aujourd'hui, presque tous les clients prennent en charge les fonctions nécessaires.
Donc, le problème aujourd'hui, ce sont les moteurs de recherche. Parce qu'ils ne le font pas. Eh bien, ce n'est pas tout à fait vrai, car ils le font en partie (surtout Google), mais à d'autres fins. Google évalue certains codes JavaScript pour empêcher Blackhat SEO (par exemple un lien pointant quelque part mais avec JavaScript ouvrant une page web complètement différente ... Ou des codes de mots-clés html qui sont invisibles pour le client car ils sont supprimés par JavaScript ou inversement) . Mais en restant simple, il est préférable de penser à un moteur de recherche d'un navigateur très basique sans support CSS ou JS (c'est la même chose avec CSS, sa partie analysée pour des raisons particulières). Par conséquent, si vous avez des "liens AJAX" sur votre site Web et que Webcrawler ne les prend pas en charge avec JavaScript, ils ne sont pas explorés. Ou ils le font? Eh bien, la réponse est des liens JavaScript (comme document.location quelquechose) sont suivis. Google est souvent assez intelligent pour deviner la cible. Mais les appels ajax ne sont pas faits.simple car ils renvoient un contenu partiel et aucune page entière sensée ne peut en être construite car le contexte est inconnu et l'URI unique ne représente pas l'emplacement du contenu.
Il existe donc essentiellement 3 stratégies pour contourner cela.
- ont un événement onclick sur les liens avec les attributs normaux href comme fallback (imo la meilleure option, car elle résout le problème pour les clients ainsi que les moteurs de recherche)
- soumettant les sites de contenu via votre sitemap afin qu'ils obtiennent indexés, mais complètement en dehors de vos liens de site (pages fournissent un lien permanent à cette urls afin que les pages externes les lien pour le pagerank)
- ajax processus d'exploration
l'idée est d'avoir vos demandes de xmlhttpget JavaScript enchevêtrés avec correspondre ing attributs href qui ressemblent à ceci: www.example.com/ajax.php#!key=value
de sorte que le lien ressemble:
<a href="http://www.example.com/ajax.php#!page=imprint" onclick="handleajax()">go to my imprint</a>
la fonction handleajax pourrait évaluer la variable document.location pour tirer la mise à jour de la page asynchrone incrémentale. il est également possible de passer un identifiant ou une URL ou quoi que ce soit.
le robot d'exploration reconnaît cependant le format ajax et processus d'exploration récupère pour http://www.example.com/ajax.php.php?%23!page=imprint au lieu de http://www.example.com/ajax.php#!page=imprint de sorte que vous la chaîne de requête contanis puis le fragment html à partir duquel vous pouvez dire que le contenu partiel a été mis à jour. vous devez donc vous assurer que le http://www.example.com/ajax.php.php?%23!page=imprint renvoie un site Web complet qui ressemble à un site Web après la mise à jour de xmlhttpget.
Une solution très élégante consiste également à passer l'objet lui-même à la fonction gestionnaire qui récupère alors la même URL que celle que le crawler aurait récupérée en utilisant ajax mais avec des paramètres supplémentaires. Votre script côté serveur décide alors de livrer la totalité de la page ou seulement le contenu partiel.
Il est une approche très créative en effet et vient ici mon analyse pr/con personnelle:
pro:
- pages mises à jour partielles reçoivent un identifiant unique à quel point ils sont entièrement des ressources qualifiées dans la sémantique web
- sites partiellement mis à jour reçoivent un identifiant unique qui peut être présenté par les moteurs de recherche
con:
- c'est juste une solution de repli pour les moteurs de recherche, et non pour les clients sans JavaScript
- il offre des possibilités de référencement de chapeau noir. Donc, Google ne l'adoptera certainement pas pleinement ou classera les pages avec cette technique haut sans une vérification adéquate du contenu.
conclusion:
liens avec l'héritage que d'habitude fallback travail attributs href, mais un gestionnaire onclick sont une meilleure approche, car ils offrent des fonctionnalités pour les anciens navigateurs. Le principal avantage du schéma d'exploration ajax est que les sites partiellement mis à jour obtiennent un URI unique, et vous n'avez pas besoin de créer un contenu dupliqué qui sert en quelque sorte d'équivalent homologue et lisible.
Vous pourriez soutenir que l'implémentation d'un système de crawling ajax est plus cohérente et plus facile à implémenter. Je pense que c'est une question de conception de votre application.
OHHH! Maintenant, c'est clair comment ça fonctionne! :) Merci beaucoup l'homme !! Je n'ai pas compris comment crawler a obtenu les liens des pages. Maintenant je comprends, je les mets sur des liens href. Oui, ça devrait marcher! C'est un super "escamotage" !! mais je le vois comme une belle astuce, pas une vraie solution pour le référencement avec le web 2.0. :) Mais ok, ça a l'air de marcher! Seulement 1 dernière chose: cela ne fonctionnera que si le navigateur évalue l'événement onclick avant le href (mais je pense que tout cela le fait). Merci Joe, vous m'aidez vraiment :) – markzzz
et désolé pour ma merde anglais :) – markzzz