6
votes

Les positifs d'utiliser JQuery pour charger le contenu l'emportent sur les négatifs de référencement?

Je redéfinisse actuellement un site et je considère que cela utilise trop ou non .charger pour la plupart de la navigation pour la rendre plus rapide pour l'utilisateur et simplement plus agréable à utiliser.

Pour ce faire, j'ai des liens avec lien code> p>

I Utilisez ensuite $ ("# Main"). On ("CLIQUE", "Linkid" code> avec renvoie false code> de sorte que les liens ne soient pas suivis. p>

J'ai / chargé/page.php et /page.php pour fournir le Code de chargement nécessaire ou la version complète de la page si un utilisateur se passe directement à celui-ci. p>

enfin sur toutes les modifications de la page de charge I Mettre à jour la page HASH à l'aide de document.location.hash = "+ $ + $ (this) .attr ("href"); code> p>

Cela signifie que les URL du site ressembleraient aux utilisateurs suivants: p> xxx pré> Et ceci aux moteurs de recherche: p> xxx pré>

Si un utilisateur est également redirigé avec le code suivant à l'URL du moteur de recherche, donc je pense que j'ai tout couvert? p>

if (location.href.indexOf("#") > -1) {
    location.assign(location.href.replace(/\/?#/, ""));
}


2 commentaires

Quelle est la structure actuelle du site, comme / fichier / page? Je demande parce que je ne recommande pas de changer la structure de l'URL d'un site existant


La structure du site resterait exactement la même et les URL de référencement ne changeraient pas, les URL hachées seraient nouvelles mais les moteurs de recherche ne devraient jamais voir / être autorisés à y accéder afin que ce soit bien.


4 Réponses :


4
votes

Tout d'abord, je n'utiliserais pas deux versions de Dispatcher PHP. Au lieu de cela, vérifiez si la demande est AJAX, le cas échéant que le contenu (sinon, servez le contenu HTML complet - il faut que les robinets Web doivent toujours voir la version HTML).

Deuxièmement, au lieu de fournir des hrefs différents, utilisez STH. Ceci: P>

$(function(){
  $('a').click(function(){
      // load content of $(this).attr('href')
      // & change the hash
      return false;
  });
});


6 commentaires

C'est une très bonne idée, n'avait pas considéré cela, fait certainement l'édition, etc. Simple.


Pour le moment, j'utilise $ ("# Main"). Sur ("Cliquez sur", "LinkID" car le contenu est chargé et que vous ne pouvez pas "cliquer sur" Contenu chargé [Link] < Un href = "http://stackoverflow.com/questions/8515142/CAN-YOU-CLICK-OWLOAD-Content-in-jQuery" Titre = "Pouvez-vous cliquer sur le contenu chargé de jQuery"> Stackoverflow.com/questions/8515142/ ... Puis-je faire la même chose avec $ ("corps"). On ("Cliquez sur", "A" `


Silver89, si je comprends correctement, ce dont vous avez besoin est la méthode "en direct"


Si cette méthode utilise cette méthode pose-t-elle une sorte de menace XSS si les utilisateurs sont autorisés à publier des liens sur le site? Peut-être sage pour toujours interdire à tous les liens externes générés par l'utilisateur que simplement en utilisant un? Je comprends que c'est un exemple général, mais certains utilisateurs peuvent copier et coller ..


@ Silver89 sorr, je ne comprends pas - comment pourrait-il être plus vulnérable que la page "statique"? :)


Eh bien, si quelqu'un a posté un lien dans un formulaire de commentaires à domaine.com/script-attac.xss , alors cette jQuery chargerait cette URL distante dans la page?



1
votes

Vous voudrez peut-être lire comment faire des applications Ajax robustes sur Google - http://code.google.com/web/ajaxcrawling/


0 commentaires

1
votes

Vous le faites correctement. C'est une amélioration progressive de base. Si l'utilisateur n'a pas accès à JS, alors ils obtiennent la version statique quelle que soit l'URL qu'ils accèdent. S'ils ont JS, ils reçoivent la version Ajaxifiée.

Votre méthode est appropriée, sauf que je suivais la suggestion de Migajek en ce qui concerne la vérification si la demande est AJAX. Voici une telle solution: http://davidwalsh.name/detect-ajax .

De cette façon, vous n'avez pas à gérer à la fois le /load/page.php et la page.php - juste un.

En outre, les moteurs de recherche ne doivent pas indexer la partie de hachage de l'URL. Vous n'avez donc pas besoin de vous inquiéter de bloquer cela.


0 commentaires

1
votes

Concernant la "mise à jour de l'emplacement de hachage" Les principaux navigateurs sont aujourd'hui en support à la modification de l'URL entière sans rechargement de page ( Histoire Push State ), pas seulement ce qui vient après # .

Vous devez mettre en œuvre cette fonctionnalité, car:

  1. Les URL sont plus belles
  2. Si un utilisateur publie un lien sur un forum / blog / quoi que vous souhaitiez que les robots associent le contenu correct avec ce lien.

    Lien vers plus d'informations sur la matière:

    • développeur.mozilla.org - manipuler l'historique du navigateur

      Je bloquerais les URL hachées d'être indexées et permettant uniquement aux URL appropriées d'être atteintes

      Le contenu après que le hachage reste client, sauf si vous l'envoyez au serveur à l'aide de JavaScript ou quelque chose de similaire.

      Et puisque les crawlers n'exécute normalement pas JavaScript ou "quelque chose de similaire", il est impossible pour vous de vérifier de manière à ce que certains #key ne soient pas indexés par un robot Web.


      AJAX + SEO = NO BIGGIE!

      Si vous le faites correctement, il n'y aura pas vraiment de pénalité d'une perspective de référencement lors de l'utilisation de Ajax pour améliorer encore vos visiteurs (et vos serveurs de backend).

      Bien que vous ayez besoin de garder votre tête droite puisqu'il y a quelques pièges, mais si vous faites attention, tout fonctionnera.


0 commentaires