Oui, mais rien ne dit que les concepteurs de dokuwiki soient vraiment doués en référencement ni cultivés en matière de spam, donc que les solutions qu’ils proposent sont utiles, adaptées, efficaces. Et ils peuvent surtout avoir plus de temps pour mettre en place de nouvelles features, que de « perdre du temps » à trouver les meilleures réponses antispam: « ouais ben on a mis quelque chose en place, je ne sais pas si c’est parfait, mais il faut que je code mon module en drag’n drop d’image, c’est plus important ».
Ils sont bénévoles aprés tout (ou pas s’ils ont la chance d’un financement, mais bon), ils font ce qu’ils veulent, non ?
Et je rappelle: je ne suis pas venu aider dokuwiki, mais les framatools, en l’occurence, frama.wiki. Aprés, rien n’empêche de leur faire remonter les patchs qui pourraient être testés et validés sur frama.wiki.
LU.
Alors là, OK, je comprends mieux leur idée d’un timing pour laisser le temps de vérifier l’absence de nocivité du contenu créé, mais là encore, ça ne sert à rien dans le cadre d’une lutte antispam SEO:
le spammeur n’a qu’à créer une page anodine, attendre de voir si elle tient, puis quand elle devient indexable, modifier le contenu et provoquer une indexation rapide (pas super dur, il suffit de tweeter l’url).
Mais la simple indexation de pages sur des sites ouverts n’a en général d’intérêt pour les spammeurs SEO (je ne sais pas pour d’autres types de spam) que si on peut y mettre des liens follow, donc d’un point de vue lutte antispammeur seo, c’est seulement le nofollow permanent et définitif sur tous les liens sortants qui les écartera.
Il y a bien un usage dit de « negative SEO » basée une inondation sur le web de copies d’une page que l’on veut faire dévisser des résultats de google, qui justifierait une préoccupation concernant l’indexation pour la lutte antispam SEO, mais pour ce type de spam, les spammeurs ne regardent même pas si les endroits ou ils posent sont indexables ou non, ils regardent juste s’ils peuvent poser, en essayant de le faire, et cherchent juste un gros volume en espérant que la majorité de leurs spams survivent.
Pour ce type de spam (pas super répandu) ou une page va se retrouver crée par ci par là, si on ne veut vraiment pas que le contenu de spam soit indexé, ce n’est pas « un certain temps » qu’il faut empêcher l’indexation, c’est jusqu’à validation par la modération.
OK, là, je suis arrivé un peu vite dans votre discussion, je n’avais pas vu dans le détail, j’ai parlé un peu à coté, désolé.
Moi je parlais de pages existantes, pas d’urls présentes dans des pages, pointant vers des pages pas encore créées (je sais comment fonctionne un wiki). Dans ce que je disais et sur ces pages nouvellement créées, il ne faut pas les laisser s’indexer tant qu’elles sont vides et il vaut mieux même ne pas les indexer tant que leur contenu propre n’est pas significatif (un ordre de grandeur de mots dans le corps de texte bien plus petit que dans l’habillage). Ca, c’est pour limiter le contenu pauvre.
Mais ce que tu décris est un autre problème, et il doit a priori être déjà bien traité par le wiki.
Là, tu parles (je me permet un tutoiement fraternel de libriste) d’urls vers des pages qui n’ont pas encore été crées, pas de pages.
A cause de ces urls, il pourrait effectivement y avoir ce que tu appelle de la surindexation, terme que je ne connaissais pas en dehors du jargon technocratique des enarques, mais qui si ça correspond à ce que je pense, s’appellerait plutôt une saturation de l’index:
toutes ces urls, le moteur va essayer de les crawler.
Si les urls sont indexables avec le contenu « Cette page n’existe pas encore », il stockera leur contenu, créant effectivement du contenu dupliqué puisqu’elles sont toutes pareilles, puis reviendra les crawler indéfiniment en mangeant le quota de crawl limité que le moteur a attribué au site (car chaque site a un quota défini), minimisant pour les vraies pages le rythme de (re)passage du robot, et pénalisant ainsi leur bonne indexation.
On peu recréer ce phénomène de ralentissement de la découverte et du recrawl des bonnes pages sur des sites configurés pour rediriger vers la home tout le trafic qui devrait aboutir en 404 not found.
En « negative seo », ca se fait en générant sur tes propres sites des tonnes de liens , vers des urls toutes différentes et inexistantes sur le site qui a ce défaut et que tu veux attaquer. A noter que dans ce type d’attaque, les liens doivent être trés faibles pour éviter d’envoyer trop de poussée à la cible et de mauvaise qualité pour éventuellement lui provoquer au passage un fitrage nseo d’un autre type (penguin)
Mais heureusement (je n’ai pas pu vérifier si c’était pareil sur frama.wiki car le premier « créer la page » que je viens de tester me renvoie sur une page blanche sous chromium) sur wikipedia les liens vers des pages à créer sont juste des pages qui répondent en http 404, donc ces urls non indexables ne saturant pas l’index ni ne mangent le budget.
En fait, techniquement, c’est juste la page « 404 not found » qui est customisée pour devenir la page « Cette page n’est pas encore créée », composée avec des éléments trouvés dans le referer et dans l’url déclenchant le 404.
C’est tout, il a suffit de customiser la page 404, et j’imagine que c’est la même chose sous frama.link/dokuwiki.
Voilà, je ne sais plus où je voulais en venir, alors bonne nuit. 
Mais je suis un intégriste du libre.