¿Qué es y porqué debes tener en cuenta el ciclo de vida de tus urls?

El ciclo de vida de una url es el tiempo que transcurre desde que una url nace hasta que muere, incluyendo los distintos estados por los que pasa. Es decir, desde Status 200 OK, pasando por 301 y muriendo en 404, 410, etc…

Al modificar dichas urls existen ciertos factores SEO que están relacionados entre urls que puede que no hayan cambiado su estado y dependan de dicha url.

Factores SEO que influyen en el ciclo de vida

  • Canonicals
  • Hreflangs
  • Enlazado interno
  • Archivo sitemap.xml
  • Página de error 404 optimizada
  • Backlinks externos y señales de vida.

¿Cómo desarrollar el ciclo de vida de una url?

Tomando como referencia un ecommerce, con rotación de productos, stock, versiones idiomáticas, variables de productos, etc… pensaremos y desarrollaremos la metodología de las acciones que repercuten a los factores de arriba cuando damos de alta un producto, lo modificamos o eliminamos. Por ejemplo.

Captura de pantalla 2020 06 18 a las 10.37.50

Casuísticas generales

Creación de una ficha de producto

Cuando se da de alta un producto, estos deben inluir:

  • Debe dar Staus 200 OK
  • Etiqueta canonical (si tienen variaciones de colores u otros atributos como tallas).
  • Etiquetas hreflang de las versiones idiomáticas correspondientes.
  • Sitemap.xml
  • Enlazado interno desde urls de categorías, posts del blog, etc…

Redirección de una ficha de producto.

Las redirecciones de una ficha de producto pueden darse por varias opciones, las principales son:

  • Que el producto haya dejado de estar a la venta y se redireccione a la categoría.
  • Que haya salido nueva versión del producto y este se redireccione a la nueva versión.
  • O que haya cambiado de categoría y las urls del ecommerce añadan la categoría en forma de carpeta a la url.

Muerte definitiva de una ficha de producto.

Las fichas de productos suelen morir por varios motivos, pero los principales corresponden a:

  • Descatalogación del producto sin nueva versión.
  • Cierre del fabricante o proveedor definitivo.
  • Decisiones estratégicas sobre rentabilidad, éxito de ventas, bajo margen de beneficios, cambios de target, etc…
  • Problemas con proveedores, tiempo elevado de suministro, bajo stock, etc…

¿Cómo afectan las distintas casuísticas a los distintos factores SEO?

Etiquetas canonicals

Cuando se da de alta un producto y este tiene variaciones de colores, tallas, atributos, etc… con una url independiente por combinación… todas las combinaciones deben apuntar a una principal, sin variables aplicadas y lo más limpias posibles. Lo mismo si son páginas de categorías y en vez de variables son filtros aplicados que no se quieren indexar ni posicionar.

Generalmente con las redirecciones en los CMS se sustituyen los canonicals por los nuevos al cambiar las urls y la categoría. En el caso de que no fuera así, los canonicals que apuntan a la url antigua deberían de hacerlo a la nueva.

En las fichas de productos pasa lo mismo, si la url de la ficha principal varía, los canónicals de las variaciones de productos deberían cambiar y apuntar a la nueva url.

Por último, si en vez de cambiar la ficha del producto por cambio de versión, nombre, etc… esta deja de existir… No podrá haber canonicals apuntando a una url con error 404 y aquí viene el problema. No se vende porque se ha descatalogado las zapatillas rojas pero si siguen a la venta las verdes y azules, y las rojas eran la versión canónica…

Hay que seleccionar otras y asegurarse que los canonicals de los demás colores se actualizan.

Etiquetas Hreflang

Las etiquetas Hreflang son algo más complicadas. Sobre todo cuando existen productos que se vende en un páis con un idioma pero en otro no.

Cuando se crea una url esta debe apuntar a su versión idiomática con la etiqueta hreflang y viceversa.

Si existen variables de productos en otros idiomas también, deberán apuntar a la url limpia del producto, como en los canonicals pero a la versión idiomática correspondiente. Es decir, el hreflang del idioma debe corresponder con el canonical. Hasta ahí es lo normal.

Pero ¿cuando se hace una redirección y se modifica la url que había sido seleccionado inicialmente como canónica?

Ahora tenemos un hreflang a una url canonica que redirecciona a otra url. Hay que cambiar ese hreflang a la url nueva a la que se redirecciona. Eso en todos los idiomas que tenga esa url como hreflang.

Lo mismo pasa con los errores 404, si un producto deja de existir por cualquiera de las circunstacias mencionadas anteriormente, dicha referencia hreflang debe dejar de aparecer en las versiones idiomáticas.

Enlazado interno.

El enlazado interno es el menor de los problemas, generalmente todos los CMS suelen actualizarse automáticamente al cambiar la url de una ficha o categoría. Con lo que el enlazado desde menús y listados de fichas no es el problema.

Con las redirecciones solo hay que tener en cuenta que la nueva url se sustituya en el código HTML y no que aparezca la antigua y redireccione, ya que el enlazado se perderá automáticamente. Eso en el caso de que no se sustituyan sino que redireccionen.

Los posts de blogs escritos a mano y con enlaces manuales si deberán ser modificados, ya que quizás añadan las redirecciones pero no cambién la url antigua del código.

Para la muerte de la url hay que investigar que esos enlaces antiguos no den error 404 y susituirlos por fichas de productos nuevos o eliminarlos si no existen.

Sitemap.xml

Los sitemap.xml no deben incluir urls con:

  1. Redirecciones 301
  2. Errores 404
  3. Urls con noindex
  4. Urls apuntando a otros canonicals distintos a la propia url
  5. Urls apuntando a otros hreflangs distintos a la propia url

Si algunos de estos casos se da, dificultaremos la desindexación de esas urls que han muerto o redireccionado a otras.

¿Qué pasa cuando un producto que ha sido top ventas se descataloga, no hay versión nueva o por cualquier motivo la url debería morir… pero sigue trayendo mucho tráfico?¿O si tiene enlaces desde sitios relevantes?

¿Qué hacemos?¿Redireccionamos o la dejamos viva sin stock pero dando sugerencias al usuario?

Mi opinión es que si la url tiene tráfico importante y hay un producto equivalente (nueva versión, modelo muy similar, etc…) redireccionar.

Si los enlaces son pobres o de calidad dudosa y no tiene señales de tráfico, ni impresiones, ni clicks la marcaremos como 410 GONE.

Página de error 404 optimizada.

Si la url tiene además backlinks relevantes y tráfico… mantenerla con Status 200 OK e implementar un sistema de productos relacionados ya sea de:

  • La misma categoría
  • La misma marca
  • Mismo año
  • O añadir un motor de búsqueda de productos.

Con el único objetivo de evitar un rebote alto desde la url al mostrarte en las SERPS

Algunos ejemplos

Se retira de la venta un producto sin variaciones o con un canonical activo.

Si la ficha no ha generado señales SEO, desactivar la ficha, respondiendo 404 o 410 y desenlazar la ficha de cualquier parte donde estuviera enlazada internamente.

Además se revisarán canonicals, etiquetas hreflang y sitemap.xml para que no sean rastreables por los bots de Google.

Para indicar STATUS 410 se añadirá la cabecera siguiente al documento.

header(“HTTP/1.0 410 Gone”);

Se retira de la venta sólo la versión canónica.

Si la ficha no ha generado señales SEO, desactivar la ficha, respondiendo 404 o 410 y desenlazar la ficha de cualquier parte donde estuviera enlazada internamente.

Si por ejemplo de unas zapatillas Adidas no se vende ni se consulta la versión amarilla con lunares rojos que se creía iba a ser un éxito y se seleccionó como canónica… Existirán X productos con un canonical que devolverá 404 o 410.

Además se revisarán canonicals, etiquetas hreflang y sitemap.xml para que no se incluya la versión canonica eliminada y se modificará en las variaciones de productos para seleccionar otra url canónica que devuelva 200 OK.

Se retira sólo la versión canónica de un producto y sólo un idioma, los demás se mantienen.

Si la ficha no ha generado señales SEO, desactivar la ficha, respondiendo 404 o 410 y desenlazar la ficha de cualquier parte donde estuviera enlazada internamente.

Si por ejemplo de unas zapatillas Adidas no se vende ni se consulta la versión amarilla con lunares rojos que se creía iba a ser un éxito y se seleccionó como canónica… Existirán X productos con un canonical y hreflangs de distintos idiomas que devolverán error 404 o 410.

Se sutituirán los canonicals de las versiones que apuntaban a las zapatillas amarillas con lunares rojos por otros canonicals apuntando a la nueva versión canonical.

Además, desde los distintos idiomas que apuntaban mediante hreflang a esa versión amarilla con lunares se deberá apuntar mediante hreflang a la nueva versión canónica elegida de zapatillas Adidas.

Conclusiones

Los ciclos de vida de urls dependen de cada sitio web, de decisiones de negocio, técnicas (a veces se hace algo no porque sea lo ideal,sino porque a nivel técnico es lo más rapido y barato según los recursos disponibles).

Por eso, he intentado dar una pautas sobre cómo actuar. Espero no haberos liado mucho pero lo principal es tener en mente que el objetivo es no perder el tráfico orgánico actual al cambiar el estado de una url y a la vez que este no afecte a la totalidad del sitio web.

Hoy que todo está tan centrado en el contenido, descuidamos aspectos simples como estos que nivel técnico no se tienen en cuenta.

Si os parais a pensar… 10 camisetas descatalogadas al año con 5 colores y 5 tallas disponibles son 250 urls (en el caso que cada combinación sea una url y actualmente existen CMS ecommerce que lo hacen así) que van a dar error 404, o canonicals erróneos, hreflangs missings, etc…

Si el ecommerce lleva un par de años haciendo las cosas así, nos vamos a 500 urls con ese tipo de conflictos que Sí o Sí tienen que afectar al SEO del sitio.

Cualquier duda, me preguntáis por aquí.

Cómo hacer un histórico SEO cuando nadie sabe qué se ha hecho y el anterior seo se dio a la fuga.

No es nada raro hablar con un posible cliente que te pide propuesta y que te diga que “No sabe bien qué se ha cambiado de la web y el anterior SEO is missing”.

La importancia de documentarlo todo con fechas, explicaciones de para qué y por qué así, junto a la persona que lo implantó y una forma de contacto es muy importante. Este tipo de seguimiento básico permite el traspaso del proyecto a quien venga detrás, reduce costes al cliente y permite mejorar la escalabilidad del proyecto. Sabemos qué se ha hecho, cuando y quién.

Cuando esto no se ha hecho puedes recopilar información sobre el proyecto en la medida de lo posible, pero ¿qué pasa si ha habido una migración anterior de la que ya no quedan restos de nada?

  1. ¿Qué urls existían antes?
  2. ¿Se han redireccionado a las actuales?
  3. ¿Cuáles se han dejado morir?
  4. ¿Han cambiado títulos, encabezados, descriptions, etc…?
  5. ¿Tienen más o mejor contenido?

¿Y si además de todo esto no tenemos acceso a Search Console porque no estaba dado de alta el proyecto, ni Google Analytics ni información de ningún tipo?

Parece complicado, pero haciendo uso de Waybackmachine, Screaming Frog y Excel podemos rescatar cierta información más o menos fiable, ya que dependerá de los registros que tenga Waybackmachine, pero eso es mejor que nada.

Buscando la última versión pre migración.

Teniendo en cuenta la fecha de migración, buscamos la versión última anterior a la nueva, en este caso la migración se hizo a finales de 2019 y la fecha es del 6 de noviembre.

Captura de pantalla 2020 06 10 a las 9.33.00

Y aquí el snapshot de la versión previa.

web antigua

Y aquí la actual

web nueva

Recopilando información con Screaming Frog

Con la url ya identificada pasamos a meterla en Screaming frog para empezar a recopilar datos de información.

Waybackmachine contruye las urls en base al /[año][dia][mes][hora]/ con lo que lo ideal es crawlear la url añadiendo filtros como por ejemplo exclusiones de todos los años anteriores.

Captura de pantalla 2020 06 10 a las 9.58.25

Obteniendo un listado de urls con mucha mierda que habrá que limpiar…

screaming

Limpiando el contenido con Microsoft Exel

Ya con esto tenemos las urls a bulk, muy feas y con el prefijo https://web.archive.org, con lo que habrá que limpiarlas con excel. Una opción es buscar y reemplazar todo lo que empiece por https://web.archive.org/ y reemplazarlo por “nada”.

Se puede utilizar los datos en columnas para usar como separadores las / y eliminar también las fechas… La idea es recopilar el máximo numero de urls posibles en el intervalo.

Con todo esto… y “guarreando” un poco el archivo excel, ya que es un trabajo tedioso y feo podemos sacar un listado con las principales métricas…

urls screaming

Y esas son las urls pre-migración de las que disponemos…

Obteniendo las redirecciones con Screaming Frog

Ahora, sólo queda pasar esas urls por screaming frog para ver o”intentar ver” qué han hecho en la migración, con lo que veremos aquellas que no se ha hecho nada, aquellas que se han mantenido o aquellas que se han redireccionado.

urls match

Obteniendo a nivel global…

image

Por último, lo ideal… sería comprar títulos, descripciones, encabezados, etc… para ver si al menos lo “básico” se ha mantenido, mejorado o empeorado.

Otro factor es ver los ratios de texto/código de urls antiguas para ver si el contenido era de poca calidad y se ha mejorado con la nueva versión del sitio o incluso ha empeorado.

Por último, otra opción es la de usar herramientas como Semrush o Hrefs para conseguir enlaces a las urls del dominio y poder conseguir urls que no aparecían en Wayback Machine…

Más info con Semrush

Para ello, filtrar los enlaces por”lost” o perdidos puede ayudar mucho…

Captura de pantalla 2020 06 14 a las 20.34.13

Por último, un pequeño truco, es buscar el archivo robots.txt donde si tenemos suerte está cacheado por WaybackMachine y podemos acceder al sitemap.xml donde aparecerá todo el listado de urls disponibles, aunque esta opción es difícil, puede ser un “pelotazo”.

Probando suerte con robots.txt y sitemap.xml cacheados

Captura de pantalla 2020 06 10 a las 11.04.49

Con esto, aunque sea una solución o “parche” alternativo podemos empezar a entender todo y construir un histórico de acciones SEO para plantear una estrategia y tener una visión de dónde estamos y por qué.

La importancia de disponer de “Personas SEO” en una estrategia.

Tras más de 15 años peleando con todo tipo de proyectos tengo claro que el desarrollo de personas SEO es vital en una estrategia de posicionamiento a largo plazo. Esto ni es o ni debería ser negociable.

Algunos SEOs enfocan el desarrollo de la estrategia en el “custom journey”o etapas del proceso de compra (necesidades de información que requiere el usuario en cada una de ellas). Pero claro, cada tipo de usuario tendrá unas necesidades u otras, con lo que está claro que sin ese tipo de usuarios no puede haber un custom journey. La única excepción a todo esto es entender que el sitio web sólo tiene un tipo de usuario.

El desarrollo de personas se debe hacer en un primer punto con el cliente.

Ellos conocen a sus clientes mejor que nadie. Por eso es vital definir las personas y las distintas necesidades con ellos, sin olvidar que debe existir alguna forma de “llevarse” todo esto al tráfico orgánico en forma de “palabras clave”.

¿Qué servicios ofrece el cliente?

Usando un ejemplo, un site, que ofrece la valoración gratuita de un inmueble como servicio principal puede tener distintos usos dependiendo del tipo de cliente, comprador o vendedor, arrendador o arrendatario. Como por ejemplo:

  1. Vendedor/arrendador
    1. Obtener una valoración inicial (máximo) para establecer un precio de venta de partida.
    2. Comparar dicho precio con ventas de inmuebles cercanos.
    3. Conocer servicios “cercanos” a la zona y que pueden incrementar el precio de venta. Como parques infantiles, supermercados, paradas de metros, etc…
    4. Precio mínimo de venta con el que es inviable seguir con el proceso de negociación.
    5. Estimación de gastos de compraventa.
    6. Estado de las viviendas referencia, reformas, placas de vado, trasteros, garajes, etc…

  1. Compradores/arrendatarios
    1. Precio medio por m2 de la zona
    2. Gastos de comunidad, piscina, garajes, trasteros…
    3. Servicios adicionales de la zona como parques infantiles, supermercados, etc… que justifiquen dicho precio.
    4. Inmobiliarias de la zona donde buscar inmuebles similares.
    5. Precio máximo de compra y fecha
    6. Datos de urbanisno, m2 registrados.
    7. Coste del IBI (no para arrendatarios)

Ya con estos desgloses podemos establecer distintos tipos de personas desde un nivel “heurístico” y basándonos en la lógica del proceso.

Vendedores que quieren saber un precio estimado de venta de su inmueble. Sobre todo para poner un precio mínimo del que no están dispuestos a bajar y precio máximo sobre el cual empezarán a rebajar conforme avance el tiempo.

Compradores que establecen un rango máximo de precio que pueden abarcar y un precio mínimo sobre el que sería considerada una buena compra.

Arrendadores que quieren alquilar un inmueble y pretenden saber el valor medio por metro cuadrado de la zona, en base a la cual, establecerán un precio de alquiler tomando como referencia otros sitios web de alquiler

Agencias inmobiliarias que utilicen los informes para comparar tasaciones de tasadores oficiales a la hora de estimar pre-tasaciones y reclamar tasaciones realizadas a clientes con otras tasaciones de referencia cercanas a la zona.

¿Cómo convertir esa información en contenido?

A través del estudio de palabras claves. Para ello existen dos vías claras:

  1. Estudio por lotes de palabras claves con intenciones de búsquedas simulando ser el comprador o vendedor y depuración de las mismas filtrando palabras claves por:
    1. Volúmenes de búsqueda bajos
    2. Competencia alta
    3. Alto CPC en el caso de que la estrategia SEO vaya a estar apoyada en un inicio con campañas de CPC
    4. Ambigüedad en keywords que puedan canivalizar
    5. Keywords que nunca podremos competir ya que los principales players son “imposibles”.
  2. Estudiando las “keywords” que posicionan los competidores principales y limpiando y filtrando las palabras claves en base a nuestras personas.

Primera aproximación de “keywords”.

Ya con estos datos podemos sacar una primera aproximación de keywords, seleccionando un número de ellas que realmente podamos abarcar.

Captura de pantalla 2020 06 08 a las 17.51.24

A partir de ahí pasamos a definir los tipos de contenidos que se pueden asociar a las personas y los procesos de compra. Siempre con la idea de satisfacer las necesidades de información y posicionar dichas palabras claves seleccionadas arriba. Por lo que será necesario optimizar dicho contenido con:

  1. Títulos
  2. Descripciones
  3. Encabezados H1, H2, etc…
  4. Urls
  5. Microformatos de preguntas y respuestas en este caso y por cómo está generado el contenido. Podría ser otro tipo de microformatos como precios, reviews, etc… si fueran fichas de productos.
  6. Enlazado interno entre el contenido de la misma persona (ahora se llama clusters) y hacia la landing principal a la cual transimitiremos relevancia.

Contenido agrupado por tipos de personas.

Captura de pantalla 2020 06 08 a las 17.55.49

Arquitectura de la información acorde a personas y SEO.

Por último, todo esto debe ir apoyado con una estructura de la información adecuada y una auditoría seo. Y aunque este no es el mejor de los casos ya que era una web con poco contenido y demasiado centrada en el foco.

Captura de pantalla 2020 06 08 a las 18.01.15

Otro punto de vista: Estrategia de keywords por fases en la toma de decisión.

Otra forma de “estructurar y generar” contenido relevante para el SEO y la conversión es por fases del proceso de adquisición. Y como ejemplo, un site que se dedicaba a la venta de tests de paternidad como principal servicio.

Ejemplo de un proceso o custom journey:

  1. Surge la necesidad en el usuario.
  2. Se informa sobre qué tipo de pruebas existen para su necesidad.
  3. Se informa sobre cuáles valen para su caso.
  4. Consulta los requisitos necesarios para hacerlas
  5. Se informa sobre el precio, tiempo de entrega de resultados, valides judicial y otros factores determinantes.
  6. Contrata la prueba.

Fase 2 Se informa sobre qué tipo de pruebas existen para su necesidad.

  • ¿Qué tipos de tests hay disponibles para demostrar lo que quiero?
  • ¿Son válidos para lo que busco?¿Tienen margen de error?
  • ¿Qué muestras necesito para el análisis?
  • ¿Necesito su consentimiento para las muestras?

Fase 3 Se informa de cuáles valen para su caso.

  • Qué diferencias existen entre los distintos tipos de tests para el mismo objetivo.
  • De quién necesito una muestra para el análisis.
  • ¿En el caso de ser durante el embarazo, hay riesgo para el bebe?
  • ¿Hay algún método no invasivo?¿es seguro?

Fase 4 Consulta los requisitos necesarios.

  • ¿Qué tipos de muestras necesito? Saliva, piel, uñas…
  • ¿Necesito su consentimiento?
  • ¿Puede tener validez Judicial?
  • Si quiero que la tenga, ¿debo solicitarlo a los juzgados?

Fase 5 Se informa sobre otros factores determinantes.

  • ¿Cuál es el precio de las pruebas?
  • ¿Cuánto tiempo tardan en estar los resultados?
  • ¿Existen clínicas o laboratorios dónde pueda realizarme las pruebas?
  • Si no existen, ¿hay alguna forma de enviarlas por mensajería?
  • ¿Existe una cadena de custodia o seguridad de que mis muestras no son manipuladas?

Contenidos fase 5

Captura de pantalla 2020 06 08 a las 18.18.18

Arquitectura de la información final

Captura de pantalla 2020 06 08 a las 18.14.26