El lanzamiento de una web: ese ansiado y a la vez temido momento. Sin duda se trata de un momento bonito en el que el trabajo de semanas y semanas por fin ve la luz y se muestra al mundo, sin embargo, también es el momento en el que mayores cagadas se producen, tal vez por prisas, o quizás por desconocimiento, en ocasiones por ambas, pero sí, se hace muchas veces mal. Cuando lanzamos una web nos dejamos llevar por ese primer contacto con los usuarios, ¿qué pensarán? ¿Sabrán comprar? ¿PODRÁN comprar? Que no está mal, hay que tenerlo en cuenta pero, detrás de tanta usabilidad, diseño y UX hay determinadas cosas muy importantes que, es más, diría que se deben tener MUY en cuenta.

En el lanzamiento de una web queremos que todo sea perfecto, ¡que deslumbre! Pero cuando la nueva criatura comienza a dar sus primeros pasos y vemos que no todo es tan bonito es cuando llegan los madre mías. Son gritos al cielo por únicamente haberse ceñido a la carrocería, a lo que se ve, sin habernos parado un momento a mirar debajo del capó y ver realmente lo que sucede en su interior. Y es que hay ciertos aspectos relacionados con el SEO que creo absolutamente necesarios revisar antes de lanzar una web, sea con CMS personalizado o con los archiconocidos. Hoy quiero hacer una checklist SEO con lo que considero indispensable tener en cuenta antes de este momento. Tomad nota.

Index, noindex, follow, nofollow

Cuántas veces habré visto páginas con la etiqueta meta-robots con noindex. Y es que, aunque como siempre que hablamos de estas cosas son simples sugerencias para Google, a veces se las toma en serio y podremos estar dando vueltas a por qué no se indexa algo. Debemos revisar seriamente todas las etiquetas meta-robots de nuestra web y asegurarnos un index,follow (por defecto) para todas aquellas que lo necesitemos. Por supuesto, también deberemos disponer noindex y nofollow para aquellas páginas que no nos interese indexar: avisos legales, políticas de cookies, etc.

Al final, si pensamos fríamente, la etiqueta meta-robots se va a ver reforzada por lo que nosotros incluyamos posteriormente en el sitemap y en nuestro robots.txt, pero más vale prevenir que curar y dejar a Google las cosas claras a nivel OnPage. Esto lo tienes que indexar y aquí puedes seguir los enlaces, esto no lo indexes y ni se te ocurra seguir navegando por estos enlaces.

Canonicalización de los contenidos

Sobre todo cuando tenemos productos y paginaciones conviene crear canonicals que referencien a los robots de los buscadores a la página que debe indexar. Ocurre en muchas ocasiones que determinados CMS generan diferentes rutas de acceso a un mismo contenido, lo que no deja de producir un contenido duplicado con diferentes url y un contenido. Es en estos casos, que pueden ser, por ejemplo, productos, cuando debemos referenciar a través de una etiqueta canonical la url válida a la que debe ir el robot.

Un canonical apuntando hacia una url lo que hace es decirle, por ejemplo a Google: “¡Hey! Has entrado a esta página, vale, pero recuerda que la que debes indexar es esta otra porque aquí vas a ver lo mismo.” Y Google podrá responderte: “¡Ah, vale! Ya decía yo, no te preocupes, que solo pasaba por aquí pero ahora reviso ese canonical tan majo”. ¿Lo vas pillando?

Un canonical se puede aplicar cuando mostramos el mismo contenido en diferentes categorías porque nos interesa tener diferentes nombres de cara a la navegación del usuario, tenemos paginaciones o filtros en listados (SIEMPRE debe haber un canonical en paginaciones y urls con parámetros de filtrado hacia la categoría original), o simplemente nuestro CMS genera esas molestas url que apuntan a un mismo contenido y nos resulta imposible quitarlas.

Estructura de encabezados

Mis queridos H1, H2 y H3. La máxima expresión del SEO on-page más allá de la redacción. Habló de un repaso general (a nivel de código debería ser suficiente con revisar las páginas tipo) de que cada página tiene establecida su keyword en un titular H1, que los H2 efectivamente delimitan secciones que utilizan sinónimos y que los H3 permiten nombrar sublistados, incluso de productos dependiendo de la página en la que nos encontremos. Podemos ir más allá y hablar de H4, H5 y H6, pero rara vez es necesario llegar a niveles tan profundos.

En mi experiencia, los programadores suelen utilizar estas etiquetas porque tienen un css apropiado en la hoja de estilo, lo que hace que vea un H6 en el nombre del producto, un H4 que indica su descripción y cosas similares. Debemos ASEGURARNOS de que la estructura de cada página tipo (home, listado, detalle, página, etc.) es la que debe ser y no encontrarnos un baile de encabezados que, además de volvernos locos a nosotros, vuelva locos a los robots de los buscadores al no saber de qué va cada página que visitan de un primer vistazo.

Etiquetas alt en imágenes

Algo que la mayoría de veces se nos pasa. A veces subimos las imágenes, comprobamos que la web se ve correctamente y ya está. Pues no. Tenemos que ser conscientes de que como mínimo deberemos añadir una etiqueta de texto alternativo a las imágenes donde se incluya la palabra clave con la que queremos que se identifique la misma. En CMS como WordPress es muy sencillo, ya que nos aparece entre los campos a rellenar una vez hemos subido la imagen. Este punto es muy fácily, si nos acostumbramos desde el principio a meterle un alt a cada imagen, luego nos ahorraremos tener que hacer un repaso completo.

Hreflang en páginas multiidioma

Las etiquetas hreflang son absolutamente necesarias en una página multidioma. Es posible que tengamos diferentes dominios o una estructura de directorios para definir el idioma y/o la región de la web en la que estamos navegando. Pues bien, a través de las etiquetas hreflang podemos indicar qué url es la correcta para cada idioma y región del usuario, ya que es posible que tengamos una versión para en-GB y otra para en-US, por ejemplo, o dispongamos diferentes idiomas desde una misma región: es-ES, en-ES, de-ES, etc. Del mismo modo, también es posible que no diferenciamos por región pero sí por idioma, igualmente deberemos indicar cuál es la url de la versión inglesa y cuál la española, por ejemplo.

Por supuesto, no podemos olvidarnos el x-default, o la página por defecto para todos aquellos usuarios que visitan la web desde un idioma o región no contemplados. Yo recomiendo generalmente poner la versión inglesa para estos casos. Como indica Google, una estructura correcta de hreflang podría ser la siguiente:

Sitemaps adaptado al tipo de web

El sitemap es ese plano que le sirve al robot del buscador para saber a qué páginas dirigirse. Debemos verlo como una tela de araña con multitud de nodos o cruces: visito X página y desde aquí ya empiezo a visitar todos sus enlaces; visito Y página y repito el proceso. Es la autopista perfecta para Google, donde se le indica una por una todas las url útiles de nuestra web. Debemos ser muy conscientes de evitar incluir en este archivo direcciones que anteriormente hayamos puesto en noindex o a las que evitemos su acceso desde el robots.txt, ya que si no pierde su utilidad. En el caso de url con canonical, es menos importante, pero si podemos evitarlas casi que mejor.

Por supuesto, si hablamos de un sitemap multiidioma, también deberemos referenciar por cada documento (recomiendo separarlos por idiomas) su equivalente en todas las otras versiones que tengamos, de modo que Google identifique todas las url que tienen el mismo contenido en diferentes idiomas. Del mismo modo, sería apropiado también, sea en el mismo documento o en un sitemap a parte, referenciar las imágenes, pues siempre nos vendrá bien indexar en Google Images.

Siguiendo con el sitemap multiidioma, la estructura correcta es la siguiente:

En el caso de que únicamente tengamos un idioma, con hacer referencia a la url es suficiente:

O si queremos meter también el contenido multimedia:

Ejemplos extraídos del soporte de Search Console.

Apertura de directorios en robots.txt

He visto cosas que jamás imaginaríais, webs que salen a la luz y semanas después continúan con un Disallow: / adornando nuestro archivo robots.txt. ¿Por qué no se indexa nada? ¿Qué sucede? Como ya os dije en un artículo anterior, el robots.txt es ese archivo que abre y cierra puertas a los robots de los buscadores, por tanto, nos deberemos asegurar que tenemos esas puertas bien cerradas o bien abiertas para que el amigo Googlebot pueda campar a sus anchas por los directorios y las url de nuestra nueva y reluciente web.

Debemos asegurarnos que permitimos el acceso a los archivos .css, .js y otras extensiones de imagen para que Google pueda ver la página como la ve un usuario. También deberemos revisar durante los siguientes días los recursos bloqueados en nuestra Search Console por si debemos abrirle paso a algún que otro directorio que se nos había escapado, así como al indexado del sitemaps por si hemos bloqueado alguna url por despiste. Por supuesto, no debemos olvidarnos de indicar en el robots.txt también la url del sitemap.

Revisión de WPO

¡Ay! La velocidad… Muchas veces estamos tan metidos en que la web funcione cómo debe hacerlo y que sea tan bonita cómo estaba diseñada en los prototipos que empezamos a meterle efectos visuales y paja que lo único que va a hacer es que nuestra página vaya a pedales. Antes de lanzar una web, aunque en el proceso de trabajo seguro que lo has notado, deberemos tener muy en cuenta la velocidad de carga de la página. Para ello existen multitud de test de velocidad que pueden darnos una idea aproximada de lo que está pasando. Yo, en líneas generales, utilizo siempre dos: por un lado GTMetrix para hacerme una idea a nivel técnico de las cosas que están fallando y PageSpeed Insights de Google para ver qué cosas no le están gustando a este buscador.

Generalmente, los motivos principales por los que una página va a ir lenta van a ser la cantidad de JavaScript y CSS acumulado, la optimización de imágenes o incluso la velocidad del servidor. En este último caso no queda otra que irnos a un plan superior o cambiarlo directamente, en los otros casos la solución está más a nuestro alcance. En el caso de WordPress, el CMS que utilizo en este blog, existen varios plugins de caché que permiten agradar un poquito más a Google; por un lado está el W3C Total Caché, que es gratuito y combinándolo con el Autooptimize puede dar buenos resultados en cuanto a optimización de código, sin embargo, el plugin que yo utilizo en todos los WordPress con los que trabajo es premium y se llama WP-Rocket, una maravilla para minificar código y optimizar la velocidad de carga capaz de hacerte subir unas cuentas decenas en el test de Google.

Para la optimización de imágenes, el guardado para web de herramientas como Photoshop es clave, ya que con una calidad mediana e imágenes en torno a los 50kb ya habremos optimizado bastante y, si a eso le sumamos un LazyLoad con el que las imágenes carguen según sea necesario, mejor que mejor.

Sin embargo, no siempre es tan sencillo y, en ocasiones, no tenemos la facilidad de un CMS con plugins ya creados, casos en las que no queda otra que consultar a un desarrollador.

Alta en Google Search Console

Y este es el paso definitivo que nos va a permitir saber si todo lo anterior está bien hecho es dar de alta a nuestra web en la Google Search Console. Una vez la web salga a la luz con su dominio correspondiente, deberemos crear las propiedades de la página, con y sin www y con y sin https. Finalmente trabajaremos en la versión buena dónde especificaremos si preferimos la url con o sin www y subiremos el pedazo de sitemap que hemos hecho para decirle a Google que estamos listos y deseosos de que nos revise la web. Una vez hecho esto, queda esperar a que el robot haga su trabajo y comenzar a revisar posibles errores y advertencias para intentar solventarlas y ver cómo los clics van subiendo con el paso del tiempo.

¡Y esto es todo! Ya sabéis, antes de lanzar una web debéis de tener en cuenta como mínimo todo esto. Y con esta lista asumo que se ha hecho un trabajo correcto de arquitectura de navegación, hemos hecho una migración decente y muchas otras cosas que no tienen que ver con el SEO, por supuesto.