Cambios en la web de DNG Photo Magazine, segunda parte

Este post es la continuación de la entrada Cambios en la web de DNG Photo Magazine (pasando de http a https) publicada ayer miércoles.

Arreglando Sitemaps

Ya metidos en faena nos decidimos a realizar una serie de tareas pendientes. En DNG Photo Magazine utilizamos el plugin Yoast SEO, que incluye las entradas de nuestro WordPress en el Sitemap, Yoast crea un sitemap principal donde se incluyen todos los demás Sitemaps, pero en nuestra web hay una serie de páginas como son las de los concursos, las de descarga de la revista y la revista On-Line que no forman parte de la Base de Datos de WordPress, sino que se generan en el momento de la publicación de un nuevo número en el caso de descargas y revista on-line y cada vez que se validan las fotos en el caso de los concursos y dichas páginas html se incluyen desde las plantillas creadas a tal efecto mediante las funciones de query_vars y generate_rewrite_rules:

add_filter( 'query_vars', array( $this, 'add_query_vars' ) );

add_action( 'generate_rewrite_rules', array( $this, 'add_rewrite_rules' );

Debido a esto todas las páginas y fotos de los concursos no están incluidas en los sitemaps de Yoast, antes generábamos dichos sitemaps (uno por cada edición del concurso) cada vez que se añadían fotos al concurso, pero enviábamos dichos sitemaps a la consola de Google de forma independiente. El caso de las páginas de descarga y del visor de la revista era el realmente problemático ya que no teníamos un sitemap de las mismas y aunque si podían aparecer dichas páginas en Google debido a que la araña de Google tenía acceso a dichas páginas, la verdad es que «no se le facilitaba la tarea» al buscador para que nos indexe más fácilmente. El primer cambio ha sido generar el archivo revista_dng-sitemap_dng.xml cada vez que se publica un número y el siguiente cambio añadir tanto dicho sitemap como los de los concursos al indice de sitemaps de YOAST:

https://gist.github.com/CarlosLongarela/d7d33170120366d8ae106810a39e982c

La primera opción fue añadir los sitemaps al raíz del sitio web al igual que el sitemap_index.xml de YOAST, pero al entrar en la configuración del plugin nos da un aviso de que los siguientes archivos están impidiendo que tus mapas del sitio XML funcionen correctamente, revisadas las condiciones de reescricutra para los XML de YOAST y comprobando que todo funcionaba correctamente, parece ser que por defecto da dicho aviso al encontrar archivos *sitemap.xml en el raíz del sitio web, pero para evitar el fácil borrado desde dicho botón (el botón Arréglalo borra los archivos del servidor) y para contentar a Yoast hemos cambiado la localización de los mismos.

Con estos cambios ya tenemos integrados los sitemaps de todas nuestras páginas en el indice de sitemaps de Yoast y los tenemos en la consola de Google con el envío de tan solo dicho indice.

Google Search Console

Esta página deberíamos visitarla casi a diario para estar al tanto de problemas en nuestra web, posibles fallos, estado del índice de Google, enlaces hacia nuestra web, etc., pero la verdad es que la he visitado menos de lo que debía y sobre todo no me había puesto en serio a corregir varios de los errores, antes se llamaba Google Webmaster Tools y la equivalente de Microsoft es la herramienta para administradores web de Bing.

Lo primero que debemos hacer al cambiar nuestro sitio a https es añadir las dos nuevas variantes, es decir https://www.fotodng.com y https://www.fotodng.com con los que acabamos teniendo cuatro propiedades web (con y sin www y con y sin https), además de las propiedades de las urls del CDN (www.fotodng.com, www.fotodng.com y www.fotodng.com), con lo que acabamos teniendo unas cuantas propiedades. Para poderlas agrupar un poco creamos un conjunto, lo que nos permite ver algunas de las características de las propiedades agrupadas, pero creo que Google debería mejorar en ese aspecto y crear una única propiedad por sitio web donde le indicásemos si es o no https y si tiene www o no, o por ejemplo si incluir en dicha propiedad todos los subdominios.

En nuestra propiedad principal (https y con www) añadimos el sitemap index de Yoast que ahora ya si incluye los sitemaps de los concursos y de las páginas de descarga.

Lo siguiente en lo que nos fijamos es en cantidad de páginas con título y descripción duplicadas… vaya, el tema de las páginas de descarga, revista on-line y concursos, al basarse cada una de las mismas en una plantilla, pues todas tienen el mismo título, siendo el mismo en todas las páginas de descarga, el mismo en todas las de la revista online y el mismo en cada página de la edición del concurso de determinado año.

Aunque es muy sencillo de arreglar, cuando realizamos los cambios de Tema es algo en lo que no caímos con la adaptación de contenidos y lo peor es que no revisamos esto en la Google Search Console, ahora la tengo abierta todos los días mirando los cambios. Para poner los título adecuados creamos las funciones que devuelven el título junto con el número de la revista, página y edición del concurso, etc. y las ponemos en las páginas con:

// URL y Canonical
add_filter( 'wpseo_opengraph_url', 'dng_og_url' );
add_filter( 'wpseo_canonical', 'dng_og_url' );


// Cambiamos el título.
add_filter( 'wpseo_title', 'dng_og_title' );
add_filter( 'wpseo_opengraph_title', 'dng_og_title' );


// Cambiamos la descripción.
add_filter( 'wpseo_metadesc', 'dng_og_desc' );
add_filter( 'wpseo_opengraph_desc', 'dng_og_desc' );


// Cambiamos la imagen.
add_filter( 'wpseo_opengraph_image', 'dng_image_url' )

Esto con las funciones correspondientes aplicadas a cada una de las plantillas y ya tenemos diferentes títulos y descripciones para más de mil páginas, también fijamos la url canónica para que por ejemplo en la revista on-line tanto este artículo https://www.fotodng.com/revista-online-127-pag-58 como por ejemplo este https://www.fotodng.com/revista-online-127-pag-88 no se consideren contenido duplicado ya que a pesar de contener diferentes títulos y descripciones (al incorporar la página en la que se encuentran como se puede ver en los puntos de la siguiente captura), la url canónica en cualquiera de las páginas del mismo número es la misma (punto 3 de la captura), en este caso https://www.fotodng.com/revista-online-127

Seguimos en la Google Search Console, pero ahora nos vamos a las páginas AMP.

Corrigiendo páginas AMP

Lo primero que observamos es que con los cambios del CDN algo ha pasado y todas las páginas aparecen con javascript de usuario:

Observamos los errores de AMP en la consola y vemos que efectivamente, se sigue insertando el javascript concatenado que produce W3TC, al cambiar el modo en que lo insertamos ahora con algunos cambios vemos que no lo registra adecuadamente y por lo tanto el plugin AMP de WordPress no lo elimina de la página AMP. Mirando un poco en el github del plugin vemos que tenemos disponible una acción antes de que se redenderice el post pre_amp_render_post por lo que la solución es decirle que se trata de un feed para que no envié nuestros CSS ni javascripts:

// Evitar CSS y JS minimificado en páginas AMP si usamos W3TC
function cl_amp_sin_w3tc_css_js() {
 global $wp_query;
 $wp_query->is_feed = 1;
}
add_action( 'pre_amp_render_post', 'cl_amp_sin_w3tc_css_js'

Y arreglado, ya podemos ir a cualquiera de las páginas que nos daba error en AMP y comprobar que todo está correcto, eso si, ahora queda esperar a que poco a poco se vaya enterando Google que está solucionado, porque ya han bajado mucho los errores, en estos momentos aún sigue mostrando que hay 318 páginas con errores de javascript generado por el usuario y que ya están corregidas.

Debido a que en algunos posts muy antiguos aún figuraba el visor antiguo de Issuu y era flash, Search Console nos daba contenido muy diferente entre la versión normal y la AMP, hubo que ir editando cada página y eliminamos el visor que ya no tenía sentido, cambiándolo por la foto de dicho número, enlace, etc., comprobando que todo estaba ok y a otra página, en esta caso ya no aparece ninguna página con dicho problema (y los anteriores de js ya están solucionados).

Nos queda un último problema con AMP, marcado com problema No es grave y es en cuanto a el elemento de datos estructurados no es válido, y se debe principalmente a la falta de logo en el elemento publisher y en otras páginas algún otro elemento. Esta parte del marcado se queda en la lista de mejoras pendientes en espera del uso de JSON-LD o de alguna otra solución válida y rápidamente implantable.

Problema AMP y urls de rel=»amphtml»

De nuevo consultando en la Search Console vemos que las páginas AMP aunque acaban en barra final en la etiqueta rel=»amphtml» la misma aparece sin dicha barra, creando un problema ya que por ejemplo la entrada de ayer tenía como url https://www.fotodng.com/cambios-web-dng-photo-magazine-pasando-http-https-9919.html y la url AMP aparecería como https://www.fotodng.com/cambios-web-dng-photo-magazine-pasando-http-https-9919.html/amp cuando en realidad era https://www.fotodng.com/cambios-web-dng-photo-magazine-pasando-http-https-9919.html/amp/

Las urls del sitio web de www.fotodng.com en lo referente a entradas o posts acaban todas con la extensión .html y las páginas acababan con barra final como por ejemplo https://www.fotodng.com/revista-descarga-127/ lo que estaba configurado en YOAST (en Avanzado -> Enlaces permanentes) y en su día activamos, con las últimas actualizaciones se seguía manteniendo dicha configuración sólo si la habíamos activado previamente ya que actualmente según Yoast tiene un impacto SEO cercano a cero.

Mirando entre diferentes opciones para arreglar dicha incongruencia entre ambas urls nos ha convencido el uso de páginas sin la barra final al estilo (legacy) de archivos (sistemas Linux) a diferencia de los directorios que llevarían una barra final, por lo que la solución ha sido muy fácil, simplemente desactivar dicha opción de Yoast. Pero ahora nos queda arreglar multitud de urls que llevan la barra final, en primer lugar vamos al archivo de configuración de Nginx y cambiamos algunas redirecciones (sobre todo de las urls antiguas antes de WordPress) para que no lleven la barra final, que aunque funcionarían igual tendríamos dos redirecciones, la primera a la url con barra final y la segunda la haría a la versión sin barra final (y queremos evitar a toda cosa en la medida de lo posible).

El siguiente cambio es el de los archivos encargados de la creación de las páginas de concursos, de descarga de la revista y revista online, en la que simplemente cambiamos en el código la versión de la url a la que no tiene barra final… bueno esto es un cambio de segundos, pero al final se ha alargado muchísimo más ya que al abrir los archivos de hace un par de años veo el código y me es imposible no acomodarlo a como trabajo ahora, siguiendo los WordPress Coding Standards ya que el editor me resalta y marca todas las recomendaciones, por lo que al final cada archivo que abro casi lo reescribo completamente.

Este ha sido el segundo gran cambio visible a los usuarios, el primero que las urls han cambiado a https y este segundo que se elimina la barra final de las urls de páginas, ya que puestos a afrontar el primer cambio de urls ya lo hacemos todo de una.

Optimizando las imágenes de Flick

En la página inicial de la web veis las últimas fotos subidas al grupo de Flickr por los usuarios, al hacer click sobre las mismas las podéis ver más grandes directamente desde la página de Flickr, pero las fotos pequeñas que se muestran en nuestra web se descargan en nuestro servidor cada pocas horas con una tarea cron y se genera el html con las mismas que después se incluye en la página inicial. Antes descargábamos directamente las imágenes y creábamos el html y en otra tarea cron se optimizaban con el programa jpegoptim instalado en el servidor, pero el problema es que a veces se guardaba en el caché del CDN la imagen antes de que estuviese optimizada.

Esta era otra tarea pendiente ya que además de vez en cuando daba un fallo al no disponer la imagen de alguna de las versiones en miniatura (un PHP Notice, pero odio ver los fallos de código no optimizado en cuanto a control de falllos y eso que era código mio), así que aprovechando toda esta serie de modificaciones, he reescrito la función que llama al API de Flickr para obtener las fotos y ya se ha corregido el fallo, además después del proceso de descarga de las fotos, se realiza la optimización de las imágenes descargadas para a continuación crear el html con dichas imágenes.

https://gist.github.com/CarlosLongarela/49a2c06bd1d7ca48ca21cb567c7fc077

y lo ejecutamos con:

$ruta_desc = RUTA . '/la-ruta-a-nuestra-fotos-descargadas/';

$base->descarga_archs_curl( $arr_fotos, $ruta_desc ); // Descargamos las fotos pequeñas para cache.
$res = optimiza_img( $arr_fotos, $ruta_desc, false ); // Y las optimizamos con jpegoptim.

print_r( $res ); // Mostramos la salida de la optimización.

$arch = RUTA . '/ruta-archivo-html/archivo-fotos-flick-para-incluir.html';
$base->crea_arch( $arch, $html, 1, 1 ); // Guardamos el html de la página de Flickr para incluir en la de inicio.

y cuando ejecutamos el script o se ejecuta via cron vemos como resultado (que me llega por mail):

/ruta-foto/33059865350_985cfc56ae_n.jpg 320x240 24bit JFIF [OK] 24593 --> 8391 bytes (65.88%), optimized.
/ruta-foto/32022492151_7e8caaa45d_n.jpg 320x184 24bit JFIF [OK] 41500 --> 19644 bytes (52.67%), optimized.
/ruta-foto/33059737360_6b6c698e65_n.jpg 320x179 24bit JFIF [OK] 16431 --> 7238 bytes (55.95%), optimized.
/ruta-foto/15033194652_8afc854ab0_n.jpg 320x320 24bit JFIF [OK] 49925 --> 17842 bytes (64.26%), optimized.
/ruta-foto/33314470871_290c2926ea_n.jpg 230x320 24bit JFIF [OK] 12466 --> 3745 bytes (69.96%), optimized.
/ruta-foto/33314421191_0af554f61c_n.jpg 320x213 24bit JFIF [OK] 51929 --> 21438 bytes (58.72%), optimized.
/ruta-foto/24902833709_ca51cefd0d_n.jpg 320x213 24bit JFIF [OK] 21956 --> 7612 bytes (65.33%), optimized.
/ruta-foto/33058901320_7b827c127a_n.jpg 320x212 24bit JFIF [OK] 46902 --> 18384 bytes (60.80%), optimized.
/ruta-foto/32599240004_4839b1b05a_n.jpg 320x149 24bit JFIF [OK] 17051 --> 6188 bytes (63.71%), optimized.
/ruta-foto/33301122755_a264491fb7_n.jpg 235x320 24bit JFIF [OK] 25927 --> 10944 bytes (57.79%), optimized.
/ruta-foto/33442021485_d393fbd9a5_n.jpg 320x222 24bit JFIF [OK] 34551 --> 14298 bytes (58.62%), optimized.
/ruta-foto/33313987491_558948e170_n.jpg 223x320 24bit JFIF [OK] 36846 --> 16380 bytes (55.54%), optimized.
/ruta-foto/32476600353_522db8e9f4_n.jpg 240x320 24bit JFIF [OK] 27414 --> 11047 bytes (59.70%), optimized.
/ruta-foto/32592625784_54cf8949e6_n.jpg 320x216 24bit JFIF [OK] 36618 --> 14666 bytes (59.95%), optimized.
/ruta-foto/33441988625_5e146a13f4_n.jpg 320x174 24bit JFIF [OK] 34633 --> 13577 bytes (60.80%), optimized.
/ruta-foto/33400916696_16d95352f0_n.jpg 320x240 24bit JFIF [OK] 36407 --> 14254 bytes (60.85%), optimized.
/ruta-foto/33286122702_f55657557f_n.jpg 320x240 24bit JFIF [OK] 25783 --> 12108 bytes (53.04%), optimized.
/ruta-foto/33377629855_1a929d58e8_n.jpg 320x171 24bit JFIF [OK] 19573 --> 8483 bytes (56.66%), optimized.
/ruta-foto/33401471436_a5b98f2b6a_n.jpg 320x133 24bit JFIF [OK] 18674 --> 6721 bytes (64.01%), optimized.
/ruta-foto/33286358242_9e03ed2894_n.jpg 320x178 24bit JFIF [OK] 35994 --> 14453 bytes (59.85%), optimized.
/ruta-foto/33286417152_d9d3797ffb_n.jpg 320x240 24bit JFIF [OK] 48088 --> 19265 bytes (59.94%), optimized.
/ruta-foto/26741429131_a2899f2a6a_n.jpg 320x213 24bit JFIF [OK] 30546 --> 14541 bytes (52.40%), optimized.
/ruta-foto/32598894134_a0156d1498_n.jpg 236x320 24bit JFIF [OK] 12605 --> 4816 bytes (61.79%), optimized.
/ruta-foto/33313720361_e94cae52c1_n.jpg 320x219 24bit JFIF [OK] 25048 --> 11051 bytes (55.88%), optimized.

Disqus

También se ha realizado el cambio del sistema de comentarios nativos de WordPress a Disqus (que ya había puesto hace unos años), pero para evitar que se cargue en todas las páginas, vamos a nuestro archivo de funciones (un pequeño plugin donde metemos estas pequeñas utilidades) y si no se encuentra en un post con los comentarios abiertos (los cerramos a los 180 días de su publicación) des-registra los archivos que añade Disqus (javascripts y css).

https://gist.github.com/CarlosLongarela/592113e9d3da54ac0f8f1fa40a3034c6

Finalizando

Por último os copio otra pequeña función que he añadido a nuestro mini-plugin que se encarga de cambiar el nombre de los archivos multimedia subidos al WordPress, esta función es muy útil para algunos sitios donde no se preocupan de subir archivos como «Concurso de Talentos de España 1ª convocatoria.jpg» que a la larga acaban dando problemas. En mi caso siempre renombraba adecuadamente cada archivo de imagen antes de subirlo, pero tenía la tarea de renombrarlo, subirlo y añadirle el título adecuado (y después el alt, claro), ahora si subo el archivo de ejemplo, en el campo de título me aparecerá «Concurso de Talentos de España 1ª convocatoria» pero el archivo se guardará como «concurso-de-talentos-de-espana-1-convocatoria.jpg».

https://gist.github.com/CarlosLongarela/a51f6e6f12c14b64eece6f5af084dad1

Y con esto finalizamos para no entrar más en detalle ya que ha habido muchos más cambios internos, lo que empezó siendo la solución del certificado de la tienda acabó siendo una serie de cambios y mejoras que se alargaron durante casi un mes, cambios de páginas realizadas con el maquetador con un más de un título h1, otras que carecían de h1 y muchas otras mejoras. Somos conscientes de que queda muchísimo por hacer tanto en lo referente a cambios en el servidor, optimizaciones, cambios desdeWordPress, contenidos, etc., pero como todos sabemos que el tiempo es nuestro bien más escaso vamos poniendo granito a granito para llegar a construir la montaña.

Esperamos todos vuestros comentarios, sugerencias, críticas, etc.