Hace ya muchas versiones que WordPress trata los archivos adjuntos (y, en general, todos los archivos subidos a la biblioteca de medios) como un tipo de contenido especial, un post type, lo que tiene ciertas implicaciones muy a tener en cuenta para el SEO.
Y, de hecho, es algo que se suele pasar por alto (si no tienes un buen conocimiento de WordPress, es difícil imaginar cómo el subir una imagen puede afectar al SEO de tu web). Así que vamos a ver cómo y por qué las páginas de adjuntos afectan al SEO en WordPress y, por supuesto, qué deberías hacer para que esto no sea un lastre en el posicionamiento de tu web.
Tabla de contenidos
- El post type adjunto y las páginas de adjuntos
- Las páginas de adjuntos y el SEO
- Configurar correctamente para el SEO las páginas de adjuntos en WordPress
El post type adjunto y las páginas de adjuntos
Ya he hablado aquí algunas veces de lo que es un post type, un tipo de contenido específico y diferenciado (como las entradas, las páginas, los productos…). Si quieres puedes echar un vistazo al artículo que escribí en su día sobre el tema:
Los custom post type hacen posible manejar el contenido de una forma muy sencilla y eficiente. De hecho la introducción en WordPress 3.5 de los custom post types (tipos de post personalizados) permitió una explosión de funcionalidades hasta entonces inimaginable. Así que WordPress (al igual que muchísimos plugins) hace un uso intensivo de ellos.
El tipo de post attachment
Concretamente, en lo que hoy nos interesa, para los archivos subidos a la biblioteca de medios. De hecho WordPress los trata como un tipo de post específico, llamado attachment (medios, en la traducción española), con una pantalla de edición especial, la biblioteca de medios. En la página del Códex dedicada a los post types lo tienes muy bien explicado:
Attachment is a special post that holds information about a file uploaded through the WordPress media upload system, such as its description and name. For images, this is also linked to metadata information, stored in the wp_postmeta table, about the size of the images, the thumbnails generated from the images, the location of the image files, the HTML alt text, and even information obtained from EXIF data embedded in the images.
Esto se ve mucho más claro si pones la visualización de la biblioteca de medios en modo lista (usando el icono que hay arriba a la izquierda, junto a los selectores de filtrado), en el que aparecen las conocidas columnas con el título, autor, fecha, número de comentarios… Y, entrando a cada uno de ellos, la página de edición.
La página de adjuntos
Ya lo ves, tiene la misma estructura que la pantalla de edición de cualquier otro post type: el título, el contenido (la propia imagen), las opciones de guardado y el resto de metaboxes (que en la captura de arriba no se ven, ya que quedan por debajo), conteniendo la descripción, el texto alt y otros datos.
Y el enlace permanente. Y ahí es dónde puede estar el problema si no haces bien las cosas.
Y es que, como con cualquier otro tipo de contenido (repito: una entrada, una página, un producto…) WordPress genera para cada adjunto su propia URL. ¿Ves en la imagen que en la barra superior aparece el enlace Ver la página del adjunto? Y no se trata de la URL del archivo en sí (sea una imagen, un PDF, un ZIP, etc), sino del post type: una página con su cabecera, su menú, su formulario de comentarios, su footer…
Y su contenido, que en este caso es, exclusivamente, el archivo adjunto.
Las páginas de adjuntos y el SEO
Bien, ahora interrumpe por un momento la lectura de este artículo y ve a tu web, a la biblioteca de medios. Si la pones en modo lista (imagen de abajo, en rojo) te dirá cuántos archivos tienes subidos.
Usaremos mis números como ejemplo, para que sigas el razonamiento. Como puedes ver en la captura, en el momento de escribir estas líneas tengo 1.110 elementos en la biblioteca de medios (en la captura se ven 1.109, pero la propia captura está subida después). Cada uno de ellos, como explicaba más arriba, genera su propia URL de contenido.
Además, tengo publicadas 280 entradas (ésta será la número 281), 65 plugins y 35 páginas, aunque la mayoría de éstas están marcadas como no indexables. En total, digamos, unas 350 URLs que quiero que Google vea y están marcadas como index. Ahora echemos unas cuentas.
350 + 1.110 = 1.460 URLs, de las cuales 350 son el: 350 x 100 / 1.460 = 23,97%
A ojos de Google (si tuviera acceso a mis páginas de adjuntos) mi web tendría 1.460 URLs, de las cuáles sólo el 24% tendrían un contenido de calidad aceptable según sus estándares. El contenido del 76% restante consistiría en una simple imagen.
Eso, para Google, es una web de baja calidad, y como tal la situaría en su ranking. Bien atrás.
Configurar correctamente para el SEO las páginas de adjuntos en WordPress
He visto listados de indexación de webs concretas en Google (usando el operador de búsqueda site: de Google) que consistían en páginas y más páginas de URLs de adjuntos. Imagina el efecto que algo así puede tener en el posicionamiento de tu web. Efectivamente: es un lastre.
Una solución correcta para esto sería evitar la indexación de todas esas páginas marcándolas como noindex y, a ser posible, excluirlas del sitemap. De esta forma nos aseguramos de que no existen para Google.
Pero esto raramente se hace, normalmente por desconocimiento, y además, sinceramente, es un fastidio tener que editar la página de cada adjunto que subes para marcarla como no indexable. Como has podido ver, en mi caso son (hasta ahora) 1.110.
Redirecciona las URLs de los adjuntos hacia la URL de la entrada a la que pertenecen
Afortunadamente Yoast SEO (que, como he dicho varias veces, es el mejor plugin de SEO disponible hoy por hoy para WordPress) nos ofrece una solución entre sus herramientas: redireccionar las URLs de los adjuntos a la entrada en la que se han incluido.
La opción la tienes en SEO > Avanzado > Enlaces permanentes, y es una de esas opciones prácticamente obligadas, de esas que, si no están activadas, es que probablemente el plugin está sin configurar. O al menos sin configurar bien.
Esto te resolverá el problema en la inmensa mayoría de las páginas de adjuntos, ya que normalmente se suben desde una entrada, una página, un producto o cualquier otro tipo de contenido, utilizando el botón Añadir objeto que hay sobre el editor de WordPress.
Y, por supuesto, marca el resto como no indexables
De esta forma sólo quedarán sin redireccionar aquellos adjuntos que no tengan un «post padre», es decir, que no estén asociados a un contenido concreto o aquellos de los que se haya eliminado el contenido al que estaban asociados. Pero claro, esto tampoco se puede quedar así. Afortunadamente Yoast SEO también ha pensado en esto y tenemos una opción al efecto.
Está en SEO > Títulos y metas, la sección que nos permite configurar qué tipos de contenido queremos indexar y cuáles no. En este caso sólo tendremos que buscar el contenido Medios y setear el Meta robots como noindex.
Eso sí, si Google ya te ha indexado todas esas URLs deberás ir a Google Search Console a solicitar su desindexación.
Redireccionar las páginas de adjuntos por código
Si no usas Yoast SEO tienes dos alternativas, en función de cómo de cómodo te sientas «enredando en las tripas de WordPress»: o bien por código, o usando un plugin específico para ello (para esto, salta a la última sección).
Para el código vamos a hacer uso del sistema de templates de WordPress y su jerarquía. Según este sistema (en WP Hierarchy puedes echar un vistazo el esquema completo de la jerarquía de templates), para mostrar un adjunto se utilizará el siguiente template de tu plantilla:
- $mimetipe-$subtype.php. Por ejemplo, image-jpg.php o image-png.php.
- Si éste no existe, entonces se cargará $subtype.php. Con los mismos ejemplos, serían jpg.php y png.php.
- Si tampoco existe este template, entonces se buscará $mimetype.php; en nuestro ejemplo sería image.php para ambos casos.
- Si ninguno de estos templates está presente en el theme, entonces se buscará el archivo attachment.php
- Si attachment.php tampoco existe, entonces caerá por fallback a single.php, singular.php y, por fin, a index.php.
En mi idioma, por favor
A ver si me sale en pocas palabras. Ninguna plantilla va a incluir templates para los subtipos mime específicos, y casi ninguna incluirá un template para un tipo que no sea la imagen, así que, resumiendo, vamos a utilizar los archivos image.php y attachment.php. El primero resolverá la papeleta con las imágenes, y el segundo para el resto de los tipos de archivo de los adjuntos.
Modificar los templates
Ahora que ya sabemos cómo funciona el sistema de templates para las páginas de los adjuntos, tendrás claro cuál necesitas modificar en función de las que incluya tu plantilla: si no incluye image.php, bastará con modificar attachment.php, puesto que ésta se ocupará de todas las páginas de adjuntos.
Si la incluye tendrás que modificar ambas (image.php para cuando se trate de imágenes y attachment.php para otros tipos de archivo), o bien eliminar image.php y centrarte en attachment.php, ya que una vez eliminada aquélla todos los adjuntos, imágenes incluidas, se mostrarán con este template.
¡Ojo! Asegúrate de realizar todos estos cambios en tu tema hijo (child theme). Si no estás usando uno, cualquier cambio que realices directamente en los archivos de la plantilla se perderá al actualizar ésta. Si tu plantilla incluye estos templates pero tu tema hijo no, simplemente cópialos de uno a otro y modifícalos en este último.
Si ninguno de estos dos templates existen en tu plantilla, no hay mayor complicación: simplemente crea el archivo attachment.php.
El código para redirigir de la página del adjunto a su contenido «padre»
Llegados a este punto ya sabemos el cómo, el dónde y el porqué, y sólo nos falta saber el qué, es decir, el código en sí que será el encargado de redirigir la página del adjunto a la del post padre. En su versión más básica el código, que tendrás que poner en la primera línea, es éste (incluyo el tag de apertura de PHP por si has creado el archivo ex-novo, y el de cierre por si estás usando un template existente):
post_parent)); ?>
Básicamente lo que hace es redirigir a la URL del post padre. Pero el código tiene un fallo: ¿qué ocurre si no hay post padre, o si éste se eliminó? ¿Qué pasa, en definitiva, con las páginas de adjuntos que no están incluidos en ningún contenido? Vamos a mejorar nuestro código, comprobando si se da esta situación y, de ser así, llevando a la página de inicio:
post_parent) && $post->post_parent !== 0)
wp_redirect (get_permalink ($post->post_parent));
else
wp_redirect (get_bloginfo ('wpurl'));
?>
Vale, esto ya va siendo otra cosa, pero ¿qué tal si indicamos el tipo de redirección a realizar? Google nos agradecería algo así… Pongamos un 301 (permanente) cuando el adjunto redirige a la URL de la entrada a la que pertenece, y 302 (temporal) si no es así. De esta forma si en el futuro adjuntamos ese archivo a una entrada todo estará como debe:
post_parent) && $post->post_parent !== 0)
wp_redirect (get_permalink ($post->post_parent), 301);
else
wp_redirect (get_bloginfo ('wpurl'), 302);
?>
Adaptar el código para el functions.php
Como el código lo estábamos poniendo directamente en el template que se carga al mostrar la página de adjuntos no hay que comprobar nada más: sabemos que sólo entrará en acción cuando se trate de una página de adjuntos.
Pero para añadir este código en nuestro plugin de funcionalidades o en functions.php primero tenemos que «engancharlo» al hook adecuado y, sobre todo, comprobar si lo que estamos cargando es una página de adjunto. Si no hacemos esto, el cielo se caerá sobre nuestras cabezas, así que vamos a retocar un poco el código:
add_action ('template_redirect', function () {
if (is_attachment() && isset ($post->post_parent) && $post->post_parent !== 0)
wp_redirect (get_permalink ($post->post_parent), 301);
elseif (is_attachment())
wp_redirect (get_bloginfo ('wpurl'), 302);
});
El plugin Attachment Pages Redirect
Si eres de los que tiene aversión al código, no sufras: ya se ha ocupado alguien de empaquetar todo esto convientemente en un plugin y de ponerlo a disposición de todos los usuarios en el repositorio de WordPress.
Se trata de Attachment Pages Redirect, y además su autor es paisano, Samuel Aguilera, así que… ¿qué más se puede pedir?