'>

7 techniques SEO remporte pour les développeurs web

 Comme une agence de référencement, nous travaillons souvent avec les développeurs Web externes. Ils peuvent être à la maison à travailler pour le client ou un autre organisme, comme nous, mais en se concentrant sur la conception et le développement web. Le niveau des connaissances SEO varie grandement d'un organisme à l', et parfois nous sommes amenés à former les développeurs sur les parties de SEO ils influencent souvent sans le savoir. Ci-dessous je vais parler de sept éléments de SEO que tous les développeurs devraient au moins avoir une prise de conscience.

Je voulais simplement clarifier rapidement Technique SEO v SEO sur place. Pour moi, sur place des éléments de référencement sont ceux dont l'utilisateur peut voir sans regarder le code source. Donc je inclure des choses comme -

    Titre Tag
    URL
    Têtes
    Corps du texte, etc

SEO technique comprend les éléments d'une page que l'utilisateur ne peut pas voir sans regarder le code source. Celles-ci comprendront des éléments tels que -

    Détection IP / Redirection
    Vitesse du site
    Redirections 301 et 302
    En-têtes HTTP
    Accès du robot d'
    Javascript
    Flash

Ce sont les sept choses que je vais couverture ci-dessous.

1) Détection des IP / Redirection

J'ai récemment vécu cette première main de problème sur un projet client et c'était très, très salissant. Pour ceux qui ne connaissent pas cela, détection IP et la redirection consiste à déterminer l'adresse IP d'un utilisateur sur votre site, puis leur montrer le contenu (ou les rediriger vers une nouvelle URL) en fonction de leur emplacement. Pour donner un exemple, si quelqu'un a atterri sur www.domain.co.uk et leur adresse IP ont indiqué qu'ils étaient en France, vous pouvez les rediriger vers www.domain.fr qui contient du contenu en français.

Pour l'utilisateur, ce n'est pas vraiment une chose terrible. Il n'est pas infaillible que la détection IP n'est pas toujours précis à 100%, mais en général cela signifie que vous pouvez afficher le contenu des utilisateurs qui est plus pertinent de leur emplacement et la langue. Ça sonne bien et fait sens.

Toutefois, pour les robots des moteurs de recherche, cela peut être très gênant. Principalement parce qu'ils sont généralement ramper à partir d'une IP US, ce qui signifie qu'ils ne peuvent jamais voir votre contenu. Le client récent de la mine ont été rediriger basée sur IP et a fini par la réorientation des moteurs de recherche à leur domaine nous.. Cela signifiait que les moteurs de recherche ne voyaient pas les autres pays, ils ciblaient notamment le Royaume-Uni et en Australie.

John Mu, à coup sur un fil Webmasters :

Oui, de nombreux robots des moteurs de recherche sont actuellement basés aux Etats-Unis ...... Une chose que je crois que vous pouvez être allusion à se rediriger automatiquement les utilisateurs en fonction de leur localisation - nous y reviendrons plus tard dans la série de billet de blog, mais en général, Oui, cela peut causer des problèmes pour les robots des moteurs de recherche et à cause de cela, nous vous recommandons fortement, soit ne pas le faire ou le limiter à un certain ensemble de pages (par exemple la page d'accueil) tout en permettant robots d'accéder à tout le reste de la contenu sur les sites.

Alors que les développeurs (et certains référenceurs) pensent souvent qu'il n'y a rien de mal avec détection IP et la redirection, vous pouvez voir les problèmes que cela peut causer. Vous aurez donc besoin de leur parler et leur faire savoir de l'impact qu'elle peut avoir sur l'exploration et l'indexation du site. Il ya des moments où la détection IP est logique, mais je vous conseille de beaucoup de prudence et de s'assurer que vous n'êtes pas accidentellement arrêtez les moteurs de recherche de voir vos pages.
2) la vitesse du site

Cela devrait certainement être élevé sur la liste des priorités pour vos développeurs à regarder. Pas seulement parce que nous savons qu'il s'agit d'un facteur de classement , mais surtout parce qu'un site rapide est préférable pour les utilisateurs et, finalement, les conversions. Combien de temps pensez-vous rester dans les parages sur un site qui prend plus de quelques secondes pour charger? Les utilisateurs sont les mêmes.

D'un point de vue SEO, vous avez besoin de se soucier de la vitesse du site, car Google est obsédé par la vitesse . J'ai lu récemment In The Plex qui donne un aperçu des débuts de Google et il décrit des cas où Larry Page a mesuré la vitesse de produits dans sa tête et a été précis quelques dixièmes de seconde. Chaque produit qu'il donne des informations sur les besoins d'être super rapide pour qu'il ait une chance d'avancer. Google comprendre combien les utilisateurs se soucient de la vitesse, de sorte que vous devriez aussi.

Si vous êtes aux prises avec les développeurs ici, passer à webpagetest.org et comparer votre site client avec certains concurrents. Ensuite, envoyez les développeurs une copie de la vidéo:

Cela peut souvent leur donner le coup de pouce dont ils ont besoin pour prendre de la vitesse d'un site un peu plus au sérieux. En termes de détails, jetez un oeil à ce guide épique de Craig sur le site Speed ​​et SEO pour obtenir la main sur des conseils et des outils pour améliorer la vitesse du site.
3) redirections 301 et 302

Désolé mais beaucoup de développeurs (et référenceurs) se tromper. En ce moment, il vous suffit de mettre en œuvre deux types de redirection - un 301 ou un 302. C'est tout. Pas 303S, 307S ou autre chose. Il ya deux principales façons que cela peut être foiré, la première façon dont je vais parler est d'utiliser le mauvais type de redirection.

Mise en 301S et 302S Mixed Up

Pour donner un peu de fond et le contexte. Une redirection 301 est habituellement utilisé dans le référencement pour une des raisons suivantes: -

    Une page a été déplacée quelque part ou a été pris vers le bas, de sorte que vous voulez rediriger les utilisateurs et les moteurs de recherche pour une nouvelle page appropriée
    D'une certaine manière vous avez créé un contenu dupliqué et que vous voulez retirer de l'index de Google en les redirigeant vers la principale version canonique

Une redirection 301 seront généralement passer presque tout le jus de lien et d'équité à travers l'URL il pointe. Ainsi, il peut être un bon moyen de donner un peu de force pour les différentes pages et faire en sorte que vous n'êtes pas perdre de jus de lien sur les pages 404 etc C'est pourquoi c'est tellement utile pour les référenceurs.

Bien que n'étant pas SEO friendly (nous couvrons pourquoi dans un instant), il ya des raisons valables pour un référencement en utilisant une redirection 302 -

    Une page peut juste être temporairement indisponible, par exemple un produit qui est âgé de stock sur un site de commerce électronique qui sera de retour en stock bientôt
    Vous pouvez tester de passer à un nouveau domaine à obtenir de la rétroaction des clients, mais ne pas vouloir nuire à l'histoire ancienne et classements domaines

Une redirection 302 fonctionne ici parce que vous êtes sûr que le déménagement n'est pas permanent. Pour cette raison, Google ne va pas passer le jus de lien à travers le rediriger, ni vont-ils supprimer l'ancienne URL de leur index. Ce sont les mêmes raisons pourquoi se mêler avec 301s et 302S peut nuire à votre performance SEO.

La raison commune pour laquelle certains référenceurs et les développeurs se tromper, c'est que pour l'utilisateur, ils ne remarquent aucune différence. Ils seront redirigés toute façon. Mais les moteurs de recherche vont remarquer la différence. J'ai vu un exemple d'un client déplacer la totalité de leur site vers un nouveau domaine et toutes les redirections étant un 302. Ceci est mauvais car -

    jus de lien ne sera pas transmis à travers la nouvelle URL, ce qui signifie qu'ils ont peu de chances de se ranger bien dans le court terme et peut-être à long terme
    Google ne va pas se débarrasser des anciennes URL de son index qui signifie que vous pouvez avoir plusieurs adresses URL des anciens et des nouveaux domaines indexés en même temps

Ainsi, vous pouvez retrouver dans une situatuon où votre nouveau site est indexé, mais n'a guère force et donc ne pas classer. J'ai vu des cas de chutes graves de la circulation en raison de mauvaises implémentations de redirections de ce genre. La courtoisie d'image suivant Elliance fait un bon travail d'afficher les différences:

Redirection de toutes les URL retour à l'accueil

C'est un autre problème que j'ai rencontré plus d'une fois. Google signale que lorsque vous implémentez les redirections, vous le faites à raison de une pour une. Par exemple -

Vous devez rediriger:

http://www.old-site.com/product-name-12345 à http://www.new-site.com/product-name-12345

http://www.old-site.com/product-name-10000 à http://www.new-site.com/product-name-10000

Ce que certaines personnes font le mal est rediriger -

http://www.old-site.com/product-name-12345 à http://www.new-site.com

http://www.old-site.com/product-name-10000 à http://www.new-site.com

Redirection de toutes les pages retour à l'accueil, ou même une seule catégorie de haut niveau, est mauvais pour les utilisateurs et peut parfois paraître manipulatrice. En outre, il ne passe pas le jus de lien indispensable entre les pages profondes de votre site qui en ont besoin, dans l'exemple ci-dessus, les pages produits ne reçoivent pas les jus dont ils ont besoin.

Encore une fois, j'ai vu de nombreux sites perdent beaucoup de trafic en faisant cela. Principalement parce qu'ils perdent classements pour leurs pages profondes qui sont habituellement longue queue.
4) HTTP Header Codes

Il ya des chances que beaucoup de développeurs sauront ce que ces codes d'en-tête HTTP dire, mais par rapport au SEO, ils ne savent pas quel effet ils ont ou comment les moteurs de recherche traitent. Il ya beaucoup, beaucoup de codes de statut là-bas (saviez-vous que le code de statut 418 signifie que je suis une théière?!), mais comme un SEO, vous devez certainement connaître les en-têtes HTTP suivantes bien et de savoir quel impact ils peut avoir. Pour un excellent moyen visuel pour comprendre les codes d'en-tête, les gars de SEOgadget fait une infographie, cliquez sur l'image ci-dessous pour ouvrir la pleine infographie:

Pour trouver le code d'en-tête HTTP d'une page, vous pouvez utiliser un outil comme Web Sniffer , la barre d'outils SEOmoz ou à l'échelle à l'aide de grenouille crie .

200 Success - Cela signifie que la page est chargée avec succès. Pour les utilisateurs et les moteurs de recherche, cela signifie que la page fonctionne bien et devrait être indexée et classée.

301 définitivement déplacé - Cela a été couvert plus en détail ci-dessus, mais en résumé, signifie qu'une page a été déplacée de façon permanente ailleurs. Les utilisateurs et les moteurs de recherche sont redirigés et plus de jus de lien n'est passé à travers la redirection, l'ancienne page est retirée de l'indice.

302 déménagé temporairement - Encore une fois, ceci est décrit ci-dessus, mais signifie qu'une page a été temporairement déplacé ailleurs. Les utilisateurs ne remarqueront pas la différence entre un 301 et un 302, mais les moteurs de recherche ne sera pas passer le jus de lien à travers elle ils ne seront pas désindexer l'ancienne URL.

404 Page Not Found - Vous êtes probablement familier avec celui-ci. Pour les utilisateurs et les moteurs de recherche, cela signifie que la page est demandée n'a pas pu être chargé. Si une page indexée devient tout à coup une page d'erreur 404, au fil du temps les moteurs de recherche vont arrêter le classant (à partir de mon expérience et des tests de toute façon).

Sidenote rapide ici de son expérience. Quelque chose que j'ai rencontré à quelques reprises est la situation où une page est affichée à l'utilisateur qui ressemble à un 404, mais quand vous regardez l'en-tête HTTP, il affichera un code 200 de la réussite à la place. Ce n'est pas bon et Google ont classé ces 404s aussi doux. La raison pour laquelle ils ne sont pas bons, c'est que c'est difficile pour vous de repérer ces erreurs en utilisant les journaux du serveur ou Outils Google pour les webmasters. Bien que Google essaie de les repérer , il est préférable de ne pas se fier à Google de le faire pour vous.

La meilleure pratique consiste à faire en sorte qu'une page 404 revient en fait un en-tête HTTP 404. En passant, vous devriez vérifier la page 404 distillée que notre stagiaire Andrew construit.

410 page définitivement introuvable - Je ne sais pas pourquoi j'utiliserais ce plutôt qu'une redirection 301, mais il peut y avoir quelques bons usages et son savoir à la façon dont Google traiter .

500 Internal Server Error - Ceci est une page d'erreur générique et n'est pas très utile, car il ne donne généralement pas autant de détails que la raison pour laquelle l'erreur s'est produite. Vous devriez vraiment essayer de garder ces erreurs à un minimum absolu.

503 Service Unavailable - Alors que ce n'est pas un code, vous devez généralement utiliser, il est utile de savoir si votre site est temporairement indisponible et sera de retour sous peu. Par exemple, si vous lançons un site ou d'un nouveau design, vous pouvez avoir à le faire en prenant le site hors ligne. Il est préférable de retourner une 503 de sorte que les moteurs de recherche savent de revenir plus tard. John Mu a également confirmé la position de Google sur ce :

"Idéalement, tout comme" le serveur est en panne "URL doit retourner le code de résultat 503 (service indisponible). En faisant cela empêche également les moteurs de recherche d'indexer et d'indexer les pages d'erreur :-) . Parfois, je suis surpris de voir combien les grands sites oubliez de le faire ... "
5) Accès du robot d'

Pour moi, la restriction de l'accès à chenilles et l'optimisation de votre allocation de crawl est une partie négligée de référencement. Probablement parce qu'il peut être un peu difficile à mettre en œuvre et ce n'est pas vraiment une science exacte. Pour comprendre cela et l'optimiser, vous devez d'abord se familiariser avec le concept de l'indemnité de crawl. Rand a écrit un grand poste plus sur SEOmoz sur cette suite de certains commentaires de Matt Cutts sur le sujet.

Au niveau de base, Google va parcourir à peu près basé sur PageRank comme Matt Cutts a expliqué précédemment :

Bottom line pour les référenceurs - Ne croyez pas que Google va parcourir automatiquement et indexer toutes les pages de votre site, tandis que Google ont rendu évident qu'ils veulent trouver chaque élément d'information sur le web, ils ne disposent de ressources limitées et doivent être sélectif sur quelles pages ils rampent encore et encore.

L'apprentissage est ici de faire en sorte que vous ne perdez pas votre allocation de crawl sur des pages qui vous ne vous souciez pas. Essayez de vous assurer que quand Google fait explorer votre site, ils passent du temps sur vos pages importantes. Il ya un certain nombre de façons de le faire, juste avoir une bonne architecture du site est un moyen très puissant en soi:

Malheureusement, de nombreux référenceurs ne sont pas toujours en position de pouvoir travailler avec les développeurs et définir une architecture de site à partir de zéro. Habituellement, c'est un cas de travail avec une architecture de site existant et essayer de réparer et d'optimiser ce que vous pouvez. Il ya quelques façons de le faire et vous avez besoin de travailler avec les développeurs à utiliser ces techniques de manière efficace.

Robots.txt - C'est le premier fichier d'un moteur de recherche va demander quand ils rampent votre site. Dans ce dossier, ils vont essayer de voir s'il ya des zones de votre site ou des URL spécifiques qu'ils ne devraient pas ramper. Il ya un débat quant à la façon strictement les moteurs de recherche obéissent à ce qui est contenu dans le fichier robots.txt, mais je pense toujours que vous devez l'utiliser et se sent sa fiabilité dans la plupart des cas. Un fichier robots.txt examine habituellement quelque chose comme ce qui est de Amazon.co.uk :

Ou si vous êtes quelqu'un comme Rishi , il peut sembler comme ceci :

Si vous n'êtes pas familier avec la façon d'écrire un fichier robots.txt, de son mieux pour être à l'aise avec elle avant de parler avec les développeurs sur le sujet. Lisez ce guide de Google et d'essai sur vos propres sites.

L'action à prendre ici est de prendre un bon aperçu de votre site et de décider quels articles vous ne souhaitez pas les moteurs de recherche à explorer. Utilisez une certaine prudence ici si, comme vous ne voulez pas bloquer les pages par accident.

Rel = canonique - Je n'avais jamais recommande d'utiliser la balise rel = canonique sur un nouveau site. Certains peuvent être en désaccord avec moi, mais je vois rel = canonique comme un dernier recours pour résoudre les problèmes de l'architecture du site. Si vous ne pouvez éviter ces problèmes en premier lieu, de le faire. Ne pensez pas rel = canonique comme un outil pour vous aider.

La principale raison à cela est que cette étiquette n'est pas une règle stricte. Les moteurs de recherche n'ont pas à prendre connaissance de celui-ci et peuvent changer la façon dont ils traitent à tout moment qu'ils veulent. données actuelles suggèrent que les moteurs de recherche prennent l'avis de celui-ci et l'utilisent très fortement. Mais je serais encore déconseille compter sur elle pour le long terme.

Il vaut la peine de faire vos développeurs au courant de cette étiquette et s'assurer qu'ils connaissent les conséquences de son utilisation. Il peut être d'une grande aide pour résoudre les problèmes de duplicate content, mais en même temps, il peut facilement aller mal si vous ne l'utilisez pas correctement. Le grand avantage d'utiliser rel = canonique d'un point de vue du développement, c'est que (en théorie), il est plus facile à mettre en œuvre que d'une redirection 301:

Jetez un oeil à ce guide de Lindsay sur le SEOmoz pour un guide plus complet pour rel = canonique ainsi que mon propre message le choix entre rel = canonique et une redirection 301 .
6) Javascript

Javascript peut être une bonne chose, il peut ajouter une grande fonctionnalité à votre site Web et améliorer l'expérience utilisateur. Cependant, les moteurs de recherche luttent avec compréhension Javascript. Ils sont de mieux en mieux tout le temps et tentent activement d'exécuter Javascript afin qu'ils puissent accéder à plus de contenu. Pour cette raison, il ya deux choses essentielles que vous devez vous rappeler -

Ne placez pas de contenu précieux au sein javascript - vous voulez vous assurer que les moteurs de recherche peuvent lire tout le contenu que vous avez produit. Ne laissez pas tous vos efforts se perdre en mettant votre contenu à l'intérieur javascript qui les moteurs de recherche ne peuvent pas s'y rendre.

Une façon courante J'ai vu cela dans le passé, c'est lors de la navigation entre les onglets sur une page de produit e-commerce. Lorsqu'un utilisateur clique sur un onglet comme "More Information", le contenu est chargé en utilisant javascript. C'est très bien pour l'utilisateur, mais les moteurs de recherche peut ne pas être en mesure de trouver ce contenu supplémentaire. Alors ils peuvent être en mesure d'obtenir à elle, ses meilleures pratiques pour être sûr et charger le contenu sur la page sans avoir à exécuter toute javascript supplémentaire.

Quelque chose que je serais certainement préconise l'utilisation de jQuery lorsque cela est possible. Jquery peut faire des éléments d'une page semblent tout aussi belle que javascript, mais est généralement SEO friendly. Lorsque vous affichez la source sur un élément créé en utilisant jQuery, vous pouvez généralement voir le contenu qui est excellent pour les moteurs de recherche.

Ne placez pas le contenu ou des liens à l'intérieur de JavaScript pour cacher intentionnellement à partir de Google - c'était une vieille tactique qui référenceurs utiliseraient pour diverses raisons. C'était à l'époque où les moteurs de recherche vraiment du mal à voir ce qui était à l'intérieur javascript. Ainsi, il pourrait être utilisé pour des pratiques anciennes comme la sculpture PageRank ou de se cacher juste flagrant de contenu.
7) flash

La plupart d'entre vous doivent le savoir, mais seulement par souci d'exhaustivité, laisse parler brièvement de flash. Comme javascript, les moteurs de recherche ont du mal à comprendre des éléments Flash d'une page. Malgré diverses améliorations , les moteurs de recherche ne sont pas aussi avancé comme ils sont avec JavaScript. Mais Google peut extraire du texte et les adresses URL qui se trouvent dans des éléments Flash, mais tous les moteurs de recherche ne peuvent pas faire cela.

L'essentiel ici est que vous ne pouvez pas laisser les clients, les développeurs ou les concepteurs de construire ensemble leur site en fonction des éléments flash. Amélioration d'une page à l'aide du flash est très bien, mais je voudrais être conscient de la façon dont les moteurs de recherche puissent le voir.
Conclusion

Je pense qu'il ya quelques faits marquants:

    Aimez votre développeur! Ils peuvent faire un travail formidable pour vous et ne pas sous-estimer leur capacité à faire des trucs cool pour aider SEO
    Ne présumez pas qu'ils savent tout - être prêt à les aider à comprendre les implications de référencement de leur travail
    Donner aux développeurs crédit où sa raison - si elles font une modification d'un site et il aide les résultats, dites-leur
Publié par Drupal Study