captain_torche

Ca semble tout de même logique, non ? Si on pouvait tous gagner 50 euros par mois sur des sites sans bosser dessus, on aurait tous 100 sites chacun, et on siroterait des cocktails au lieu de venir nous améliorer sur des forums

J'avais compris une "faq" Mais bon, y'a pas de miracle : ce n'est pas en traitant ses sites par-dessus la jambe qu'on en retirera le moindre centime.

Micky, ton code ne fait que redimensionner la fenêtre du navigateur à la taille de l'écran, cela n'a donc rien à voir. A part ça, bienvenue à toi, lesaintmardois !

Je pense que ce que veut dire karnabal, c'est que pour deux sites ayant la même notoriété, le fait d'avoir des commentaires de qualité sera plus avantageux que de ne pas avoir de commentaires.

A quoi servent ces critères ? S'ils te sont utiles, ce serait illogique de vouloir les supprimer. Dans ce dernier cas, tu pourrais utiliser une balise meta canonical pour pallier au souci.

Personnellement, j'ai une requête Google Images sur laquelle je suis bien positionné, pour laquelle la page ne répond strictement pas à la requête (Si ce n'est qu'elle comporte un lien vers l'image). Je ne sais pas ce qui s'y passe, mais j'ai une moyenne de trois pages par visite sur cette requête !

Par contre, est-il possible qu'un article où les commentaires sont trop nombreux car mal modérés, verrait son placement décroître en raison d'une "dilution" du contenu intéressant ?

En ce qui concerne ces "sas d'entrée", je suis convaincu que ce n'est rentable QUE pour les grands sites, qui ont une position telle qu'on ne peut pas faire autrement que visiter le site si on veut trouver l'information qu'on souhaite. Si tu veux juste mettre des concerts en avant, tu peux très bien intégrer cela à ta page elle-même, non ?

Tu peux très bien faire une première pagination "en dur", puis la rendre dynamique en AJAX après coup. Ainsi, les commentaires seront tous visibles de Google et consorts.

De toutes façons, il faut TOUJOURS doubler les contrôles côté serveur : il est très facile de désactiver le JS.

Pas vraiment : je lui conseillais de faire un fichier statique en JS, et de mettre dans la page des variables de personnalisation en javascript, mais générées par PHP. C'est un peu gore, mais ça peut marcher.

En toute logique, tant que tu prends un nom de domaine qui ne correspond pas à un domaine d'activité d'Apple, il ne devrait pas y avoir de souci. Après, il faudra bien faire attention à ne pas entretenir de confusion avec la marque à la pomme, également.

Dans ce cas, tu seras obligé de passer par une étape de génération de fichier. Par contre, en ce qui concerne le référencement, le souci ne vient pas du fait qu'il y ait du javascript dans la page (Il est très facile pour un moteur de supprimer le code inutile), mais plutôt du poids de la page. Pour contourner ton problème, pourquoi ne pas faire un fichier statique, et générer des variables de personnalisation dans ta page ?

L'avantage d'un CMS répandu, c'est qu'on doit pouvoir changer de prestataire en fin de contrat : les bases du code seront connues d'un nouveau prestataire.

Malheureusement, tu ne pourras pas te séparer du hash : c'est le seul moyen qu'il existe pour que l'url "change" (même si on reste techniquement sur la même page) quand tu effectues une opération JavaScript (Ajax ou non). Toute autre modification de l'url entraîne un changement de page, et donc Ajax perdrait beaucoup de son intérêt. Par contre, as-tu réellement besoin que l'url de la page change ? Ce n'est en toute logique pas indispensable, à moins que tu ne veuilles qu'on puisse faire un lien vers une image précise. L'ajout du hash dans l'url permet au JavaScript de réafficher l'image en question, ou au navigateur, si JS est désactivé, de pointer sur la bonne image si elles sont disposées en liste, les unes en-dessous des autres.

Et de quelle manière ? Ca pourrait être sympa de le préciser.

Ca ne serait pas une sandbox, mais plutôt une pénalité de duplicate content. Vu que les contenus ne sont plus disponibles, ça ne devrait pas être pénalisant trop longtemps. Tu peux essayer de supprimer les pages les plus importantes avec l'outil de suppression de page de Google : https://www.google.com/webmasters/tools/removals

Ils parlent ici de 4 Go installés, avec suffisamment de slots pour mettre jusqu'à 16 Go au total, donc en toute logique ils sont tous 64 bits. Edit : apparemment les OS sont livrés en 32 bits et 64 bits (Les deux versions sur le DVD d'installation, je suppose), mais préinstallés en 32 bits pour maximiser la compatibilité avec les drivers de matériel plus ancien. Si j'en crois l'article de Wikipédia, le fait qu'ils soient en 32 bits n'est pas un obstacle à l'ajout de plus de 4Go de RAM.

J'avais lu quelque part que Vista 32 bits affichait la quantité de mémoire installée (et non gérée) afin qu'il y ait moins de retours utilisateurs ("Vista m'affiche moins de RAM que ce que j'ai installé"), alors qu'il ne gère pas tout. http://support.microsoft.com/kb/946003/

Au temps pour moi, ça m'apprendra à dire des sonneries

Magicoyo : en toute logique, un système 32 bits peut gérer 3 Go de RAM. Toutefois, les barrettes de RAM étant vendues par deux pour bénéficier du Dual Channel (Doublement de la bande passante dédiée à la mémoire), il est très rare de trouver des valeurs impaires de RAM.

Il suffit de poster des interventions dans les forums appropriés.

Je confirme pour Firefox : les versions actuelles sont assez gourmandes en RAM, et il n'est pas fréquent de voir l'utilisation faire des pointes au Giga, en fonction des plugins qui y sont installés.

C'est effectivement de la signature qui apparaît en-dessous de tous les messages dont il est question. Par défaut sur Invision Power Board, la plateforme de forums qu'utilise Webmaster-Hub, les moteurs ne peuvent pas les voir (Sur d'autres plateformes également, ce n'est pas spécifique à IPB). Il existe aussi une psychose de pseudo-référenceurs qui croient dur comme fer à la "fuite de PR" : un forum laissant trop de liens sortants perdrait son PageRank (Un des très nombreux critères de classement de Google). Dan a donc fait des modifications sur le forum pour que les signatures des membres soient visibles des moteurs à partir d'un certain nombre de messages, et a prouvé par là même que la fuite de PR n'était qu'une légende

J'ajouterai que le robots.txt n'est qu'un moyen de préciser ce qu'on ne veut pas que les robots fassent, mais qu'il n'est aucunement un système de blocage. En gros, si un robot malintentionné veut bien capturer l'intégralité de ton site alors que tu lui en interdis l'accès, il peut le faire malgré tout. De plus, indiquer dans le robots.txt les urls sensibles est dangereux : une personne malintentionnée pourrait s'en servir pour "deviner" facilement les urls de ces pages.