Formas de bloquear, eliminar y ocultar contenidos web

A la hora de mostrar u ocultar contenidos lo primero que hay que tener presente es “a quién”. Por un lado, tenemos a los usuarios reales, y por otro a los virtuales (los robots, principalmente los de Google, Bing…).

Si comenzamos por la parte más técnica, que son los robots, nos encontramos con diversas formas de bloquear los contenidos:

robots.txt

El fichero de robots.txt está creado para que los robots, en principio, no accedan a esas direcciones URL. Esto hace que esos contenidos queden bloqueados, y que cuando se rastree una página “no se carguen”. Aún así, cabe la posibilidad de que si una URL bloqueada por robots.txt tiene muchos enlaces aparezca en los resultados de búsqueda, aunque con menor peso.

Código 404

Por norma general cuando se carga un elemento web se devuelve un código 200 (OK) o un 304 (Not Modified). Cuando queremos indicar que un contenido no existe, hay varias formas de hacerlo, la más habitual es la del 404. Este código, 4040 (Not Found) indica que un contenido no se ha encontrado en el servidor, sin indicación de si es algo permanente o temporal. Este es el sistema más estándar, pero a la vez el que menos información da a las máquinas.

Un detalle de los 404 es que cuando se indican, los robots de rastreo suelen probar varias veces más a lo largo de los siguientes días para intentar detectar si sigue existiendo o no el contenido, y al cabo de un tiempo lo acaban eliminando (sobre todos los contenidos que no tienen enlaces externos que, si no, cuesta mucho de eliminar).

Código 410

De la misma forma que el código 404 que es bastante indeterminado, existe el código 410 (Gone) que concreta más las razones por las que esa página ha desaparecido. En este caso lo que se viene a indicar es que el recurso ha desaparecido y no hay ningún otro que lo sustituya, por lo que se considera permanente, e incluso se deberían eliminar los enlaces que hagan referencia al recurso.

The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed.

Este sistema hace que una vez un robot de rastreo entre, puedan llegar a probarlo una vez más por confirmar, pero lo antes posible se elimine el resultado de búsqueda.

NoIndex

La opción de NoIndex, ya sea a través de un meta-tag o de una cabecera del servidor, indica que aunque ese recurso existe, no ha de indexarse. Hay que dejar claro que los robots rastrean (crawling) y que indexan esa información. Indexar es que esa dirección URL aparezca o no en los resultados de búsqueda.

En general las razones por las que no se quiere mostrar un resultado en los buscadores es principalmente el de que esa información lleva contenidos delicados y no se han de mostrar (o simplemente que no son de utilidad para alguien que haga búsquedas). Pero no es la única posibilidad. Si nos focalizamos en los propios buscadores, sabemos que no les gustan los contenidos duplicados, porque haces elegir al usuario entre dos elementos muy similares. En estos casos tenemos los llamados soft 404, que son páginas que se consideran muy similares, aunque se les haya devuelto un código 200. Un ejemplo podrían ser listados de búsqueda internos, o secciones de una página con categorías en las que los contenidos sean muy pocos o muy similares, de forma que al comparar dos páginas, se parezcan muchísimo entre sí.

Un ejemplo de uso de los NoIndex es ponerlos en páginas de resultados o listados en los que hayan “muy pocos datos”. Si normalmente una categoría tiene decenas de resultados, y otra solo dispone de 1-3 contenidos, quizá esa página no tenga la necesidad “todavía” de parecer en los resultados, hasta que tenga un contenido 4-6 que realmente le de valor y peso.

Qué hacer en determinados casos

Lo principal que hay que decidor es la combinatoria de si es permanente o temporal, y si los datos han de poderse ver por los usuarios o los buscadores.

Partiendo de esta base nos encontramos con los extremos. Hay que dejar todo (por lo que no hay que hacer nada) o hay que erradicar todo (me encanta esta palabra para este concepto). En este último caso la solución es sencilla: hay que devolver un código 410 y que la página que se muestre no tenga ningún contenido (se puede hacer una página de error explicando que ese contenido que estaba ahí ya no está).

A partir de ese momento nos encontramos con los grises. Por ejemplo, con la RGPD aparece la opción de eliminar todos los datos de un usuario de un sitio de forma pública. Esto significa que las direcciones URL de perfiles y similares han de desaparecer por completo (410). Pero puede ser que simplemente un usuario haya incumplido una acción y se le haya desconectado temporalmente su cuenta. En estos casos hay que plantearse opciones, como por ejemplo si queremos que su ficha siga activa, pero no se pueda interactuar, y al cabo de unos días convertirla en un 410 si no nos ha dado respuesta. O por ejemplo que haya que eliminar su cuenta, pero a sabiendas de que en unos días pueda volver a activarse esa cuenta, lo que en principio debería ser un 404.

Existe un artículo muy interesante sobre desindexación de contenidos en el que se ven reflejados distintos métodos para ver cuál es la mejor forma de eliminar datos de los resultados de búsqueda con el menor impacto posible, que es muy recomendable para leer.

Categorías SEO

La gran experiencia de la WordCamp Irun 2018

No hace ni media hora que estaba despidiéndome entre abrazos de los que ya considero amigos y la “tribu” de personas apasionadas de WordPress. Hace dos semanas estaba en Bilbao, y este fin de semana ha tocado Irún.

Tenía muchas expectativas con esta WordCamp, expectativas que se han cumplido con creces, y me atrevo a afirmar que ha sido la mejor WordCamp en lo que a organización se refiere. Sin duda un grandísimo de Pablo Moratinos y todo el equipo de organización y voluntarios. Un 11, perfecto, nada que objetar.

Y por el resto, todo genial. El viaje comenzó movido, ya que Vueling canceló el vuelo (posteriormente me dijeron que había muchísima niebla) pero finalmente pude llegar el viernes por la tarde. Dejar las cosas en el hotel y nada más salir encontrarme con Ibon Azkoitia, con el que me fui de PintxoPote donde nos cruzamos con el equipo de Cádiz.

La cena fue simplemente espectacular. En la Sidrería Ola simplemente disfrutamos. Algunos ya decíamos que se podría acabar la WordCamp en ese momento.

Allí tuve la oportunidad junto a Tomás de conocer a Ryan, responsable de WPScan, la herramienta en la que se basa WPdanger, por lo que fue un placer poner cara a una muy buena persona que aporta tanto a la seguridad de WordPress.

El sábado comenzaron las ponencias… el programa de dos tracks y mi asistencia a algunas de ellas que fui “retransmitiendo” vía Twitter.

Primero vino la charla de Piccia que habló de los colores…

Luego vino la charla de Monty sobre AMP.

Luego vino mi charla… Hablé de WP-CLI, aunque eso ya lo he contado… muy contento por poder tratar temas técnicos desde una visión muy práctica y con una finalidad, en este caso: el mantenimiento de WordPress.

El siguiente punto fue la charla de Fernando sobre CMB2, muy interesante como elemento algo más técnico que ACF.

Previo a la comida estaba la charla de comunidad de Jonatan.

Después nos juntamos Ana, Fernando, Jaime y yo en el podcast de Club WordPress donde contamos muchas batallitas y en el que nos divertimos muchísmimo.

Cuando acabamos me fui rápidamente a la charla de Ana Cirujano, a la que llegué tarde por estar acabando de grabar el podcast, pero sin duda será el vídeo que recomiendo ver en WordPress.TV, porque su charla fue genial. Como siempre aprendiendo sobre tipografía y porqué usar una u otra letra según el momento adecuado o lo que quieras transmitir. Una fuente de conocimiento -y mejor persona- interminables.

Tras la charla de Ana me fui a otro podcast, en este caso el de Juanma de WP para Novatos

El siguiente paso fue la charla de Tomás. Recuerdo hace unos meses que hablando con él coincidimos casi casi a la par él en presentar la charla de Irún y yo lanzar la herramienta de Google Dorks en WPdanger.

Después de aquello, desconexión por mi lado, un rato de hotel y de camino a la cena / after-party. Allí muchas risas explicando batallitas de viejos de Internet, hablando de cómo era la web en los 90’s. Por supuesto rodeados de kalimotxos, cerveza, refrescos y comida. Por cierto, ¡qué ricas estaban las txistorras!

Y hoy ha sido el Contributor Day. Una vez más, en la sala/mesa de la Comunidad, tomando nota en todos los sentidos de cara a la WordCamp de Barcelona. Es muy probable que de Irún salgan dos meetup y una WordCamp, aunque aún es pronto para saberlo.

Y aquí ando, en el aeropuerto, recién llegado de la Universidad de Mondragón donde se ha celebrado el evento, con ganas de que anuncien Sevilla, Valencia, Pontevedra, llegue Barcelona y finalmente acabemos en Granada, con la posibilidad de una extra.

Gracias a todos los que os habéis acercado a saludar, a preguntar, los que me habéis hecho reír, los que habéis pedido fotos y sobre todo, gracias a la comunidad de Irún, porque ¡sois los p**os amos!.

#WCIrun 2018: WP-CLI para hacer mantenimiento semanal de tu sitio

En estos momentos se está llevando a cabo la WordCamp Irun, y una vez más, como ponente, quiero dejaros una pequeña presentación que se centra en comando de WP-CLI. El objetivo es sencillo: hay que hacer mantenimientos de WordPress de forma simple y a la vez con mucha información.

Si te atreves a usar la consola, quizá te interese usar WP-CLI, un pequeño gran proyecto de WordPress que te ayuda a ejecutar comandos sin necesidad de entrar e el panel de administración. Mucho más rápido y que no requiere de API ni servidor web.

Como decía, estos comandos que planteo están focalizados en hacer mantenimiento de WordPress con WP-CLI. Así que si estás harto de que al actualizar se te quede colgado el navegador, tengas problemas con JavaScript o cualquier otro impedimento, este es tu sistema.