Desarrollo web para SEO: Otro casi va al sur

Última actualización el 14 de septiembre de 2018

¡Es por eso que tienes una empresa de SEO, así! Company, para detectar y corregir lo que va mal con el rediseño de un sitio web existente. Como sabe cualquiera que trabaje en la industria del marketing en Internet y haya pasado por una reconstrucción de un sitio web en funcionamiento, muchas cosas pueden salir mal. Recientemente, un cliente de PPC (pago por clic) y SEO (optimización de motores de búsqueda) acaba de terminar con la reconstrucción de su sitio web y lo lanzó sin permitir la revisión. Esta última reconstrucción del sitio de este cliente salió terriblemente mal en el lanzamiento, por lo que mencionaré algunas de las cosas esperadas e inesperadas que pueden, y pueden, fallar.

La necesidad

Este cliente compró un negocio existente que tenía un sitio web informativo y de comercio electrónico existente y era líder en su industria. El desarrollador web no vino con la compra. Por alguna razón que nunca me fue revelada, el cliente no pudo actualizar ninguna página fuera del carrito de compras. El carrito de compras no era compatible con dispositivos móviles y pudimos ver la diferencia en sus conversiones desde computadoras de escritorio versus dispositivos móviles. Las conversiones móviles eran prácticamente inexistentes. La gran mayoría de sus ventas en línea se generaron mediante búsqueda orgánica de escritorio, PPC, visitas directas y de referencia.

Muchos de los elementos necesarios para mejorar su SEO tampoco estaban allí. No hay posibilidad de cambiar los metadatos, las etiquetas h1, las etiquetas alt/title, etc. La mayoría de estos datos se generaban mediante programación; así como los menús y la estructura de navegación. Este nuevo sitio también tendría que ser seguro. En resumen, lo que necesitaban era un nuevo sitio web seguro y compatible con dispositivos móviles y un carrito de compras con un conector para trabajar con su suite de software de planificación de recursos empresariales (ERP) existente.

La misión

Este cliente tenía 3.766 palabras clave con resultados de clasificación entre los cien mejores SERP de Google. Quinientos treinta y ocho (538) palabras clave con resultados en la página 1, con un volumen de búsqueda mensual promedio de 65,790 y 43 palabras clave clasificadas en la posición uno en los SERP de Google que tenían un volumen de búsqueda mensual promedio de 6,110. Mi trabajo consistía en guiarlos a través de los requisitos que un nuevo sistema de administración necesitaría para proporcionar la capacidad de implementar SEO en el futuro. Esto también incluía proteger sus resultados de clasificación existentes lo mejor posible.

La selección

El cliente finalmente seleccionó a un proveedor extranjero que podía proporcionar la integración entre su software ERP existente y una nueva solución de carrito de compras segura y compatible con dispositivos móviles y un sitio web. Al no estar familiarizado con este proveedor extranjero, el cliente me proporcionó una demostración del producto grabada para confirmar que el sistema de administración proporcionaría lo que necesitábamos para implementar SEO. Después de revisar la demostración, concluí que teníamos los elementos necesarios para ayudar al cliente con las mejoras de SEO. Podríamos crear nuestros propios títulos de página, meta descripciones y etiquetas h1. Podríamos actualizar el código de Google Analytics (GA), del cual estaban ejecutando un código de GA antiguo y desactualizado y sin cuenta de Search Console. Tuvimos acceso a las imágenes para agregar texto alternativo/título con el formato adecuado. Como descubrimos más tarde, y demasiado tarde, incluso existía la posibilidad de aplicar la redirección 301 directamente en cada página. Pero eso es sólo una parte de la historia.

El resultado

Resulta que el desarrollador proporcionó una plantilla, un carrito de compras y una integración de ERP. El cliente tenía la tarea de mover el contenido (copiar el contenido del sitio antiguo y pegarlo en una nueva página en el sistema de administración), incluidos los metadatos existentes. También se les asignó la tarea de ingresar las URL del sitio anterior en los datos de la página nueva, página por página. Resulta que esto se complicó por el hecho de que el cliente no podía copiar y pegar intactas las URL del sitio anterior. El cliente tomó esto como un procedimiento operativo estándar y no notificó a nadie sobre esto. Originalmente habíamos recomendado que el desarrollador creara un archivo de redirección 301 adecuado. El cronograma de implementación no permitió que el cliente nos permitiera revisar el funcionamiento adecuado. Simplemente lo lanzaron y ahí es donde todo salió mal.

Al notar que se había lanzado el sitio reconstruido, comenzamos a probar manualmente los resultados de clasificación de palabras clave originales con los resultados de clasificación actuales. Solo para ver cómo se veía el nuevo sitio y que todos los datos se transfirieron. Todos los resultados de clasificación en los SERP de Google que aún estaban vigentes dieron como resultado un código de respuesta 404, excepto la página de inicio. Resulta que las URL del sitio antiguo se crearon con extensiones .html y las nuevas URL no. El sistema de administración simplemente no permitía que la antigua URL se pegara en el campo de redireccionamiento 301 proporcionado, por lo que el cliente pegó la antigua URL sin la extensión .html. El cliente había asumido que este era un procedimiento operativo estándar.

Después de mucha discusión interna, descubrimos que si eliminaba la extensión .html, las páginas redirigirían correctamente a la versión segura de la nueva URL, en la mayoría de los casos. Sin embargo, en algunos casos, la antigua URL, sin la extensión .html, redirigiría a una nueva URL que no era compatible con los motores de búsqueda y que contenía una cadena de consulta que nunca antes habíamos visto. En un examen más detallado, encontramos que esta nueva URL desconocida estaba siendo generada por la navegación en el menú principal. Por lo tanto, tuvimos una redirección uno a uno, en la mayoría de los casos, desde la URL anterior, la extensión .html eliminada, a la nueva URL compatible con el motor de búsqueda seguro y pudimos navegar al mismo contenido desde la navegación principal que generó el nuevo no -URL amigable.

¿Contenido duplicado? Bueno, ¿se colocó la etiqueta canónica rel=? ¿Correctamente? No. La etiqueta rel=canonical en la URL redirigida compatible con los motores de búsqueda se configuró para apuntar a la nueva URL no compatible con los motores de búsqueda que contiene la cadena de consulta. Al examinar la etiqueta rel=canonical de la página no amigable, descubrimos que esta etiqueta hacía referencia a una URL completamente diferente. Uno que contenga la categoría y no la cadena de consulta. Por lo tanto, se mostraba una pieza de contenido para tres URL diferentes, con etiquetas rel=canonical configuradas incorrectamente.

Luego, encontramos que todos los bots habían sido deshabilitados en el archivo robots.txt. Luego comprobamos la actividad en GA. El cliente aún recibía visitas de todas las fuentes, pero registraba cero conversiones. Además, el cliente quería que impulsáramos el rastreo y la indexación que requiere la consola de búsqueda de Google. El problema aquí es que el código GA existente era antiguo y nunca se colocó un código de verificación de Search Console en el sitio. Este es uno de esos artículos que el cliente no podía cambiar por razones nunca reveladas.

Afortunadamente, el cliente tomó nuestra recomendación de implementar la actualización de su código GA a la última versión. Por su cuenta también agregaron el administrador de etiquetas de Google. ¡Ups! ¿Posiblemente doble disparo del código GA? Con el Administrador de etiquetas de Google y el código de GA asincrónico actualizado, pudimos crear una cuenta de Search Console nueva y segura (https frente a http) para el cliente y luego descubrimos que no había un mapa del sitio .xml para enviar para un rastreo solicitado. .

Tras la notificación, el cliente se comunicó con el desarrollador y recibió dos URL de mapa de sitio .xml. Uno funcionó. Uno no lo hizo. El que funcionaba tenía una entrada que apuntaba al mapa del sitio .xml que no funcionaba. El mapa del sitio .xml que no funcionaba no tenía el formato adecuado cuando se visualizaba en un navegador. Por lo tanto, no enviamos el mapa del sitio .xml proporcionado en ese momento.

El resultado final

Notificamos al cliente, a través de correos electrónicos preparados, lo que estábamos encontrando. Primero, el problema de los redireccionamientos fallidos y que descubrimos que si eliminamos la extensión .html, redireccionaron correctamente. El cliente notificó al desarrollador y el desarrollador respondió que no podía poner la extensión .html en la herramienta de redirección 301 provista. Un descubrimiento posterior reveló que el cliente había descubierto esto y pensó que se trataba de un procedimiento operativo estándar.

Por alguna razón, se eliminó el sitio web original (gran sorpresa aquí, siempre tenga una versión funcional lista para recurrir) por lo que no pudimos extraer ninguna de las URL antiguas para crear una nueva redirección 301 permanente a través del archivo .htaccess. La resolución fue crear una nueva coincidencia uno a uno, URL antigua frente a URL nueva, hoja de cálculo, extrayendo los datos de la página de destino de GA durante el último año, para que el desarrollador creara una redirección que funcionara correctamente anulando la redirección 301 en el sistema de administración que se le encargó al cliente.

Problema resuelto con costo adicional para el cliente por parte del desarrollador. Todos los resultados de clasificación antiguos existentes con una extensión .html comenzaron a redirigirse correctamente y, en 14 días, los resultados de clasificación se reemplazaron con las nuevas URL seguras y, en su mayor parte, muy cerca del resultado de clasificación preexistente. El problema de la etiqueta rel=canonical se resolvió en una reunión en línea con el agente de ventas del desarrollador web y se redujo a un error de entrada del usuario. Había varios campos en los que se podían ingresar o seleccionar datos de una opción existente y la solución requería restablecer estos campos y borrar el caché.

Las dos versiones adicionales de la URL amigable y segura desaparecieron rápidamente. Con respecto al bot /disallow en robots.txt, tras la notificación, el desarrollador resolvió rápidamente este problema.

Se descubrió que el problema con los datos de conversión de GA parece estar aislado del proveedor de servicios comerciales del cliente; que era nuevo y diferente del antiguo proveedor. Nadie pensó en comunicarle al proveedor de servicios comerciales que necesitábamos el código GA en su página de pago para proporcionar los datos de comercio electrónico necesarios que el cliente necesita para tomar decisiones comerciales informadas sobre sus esfuerzos de marketing. No se nos informó de la existencia de un nuevo proveedor de servicios comerciales.

Finalmente, habíamos creado manualmente un archivo de mapa de sitio .xml que queríamos cargar en el servidor y solicitamos que el desarrollador deshabilitara cualquier cosa que estuviera creando su mapa de sitio .xml que no funcionaba. En conversaciones posteriores con el agente de ventas del desarrollador, nos dijeron que no podíamos cargar otro mapa del sitio .xml en el servidor.

Después de mostrarle los resultados al agente de ventas del desarrollador, dijo que lo revisaría, sin embargo, sugirió que viéramos el código fuente. Al visualizar el código fuente, el documento .xml tenía el formato correcto. Al ver este resultado, notificamos a Google, a través de Search Console, que de hecho teníamos un mapa del sitio .xml en funcionamiento. Finalmente, en el transcurso de varios días, Google finalmente registró que teníamos un mapa del sitio .xml en funcionamiento y comenzó a mostrar las URL indexadas. Sin embargo, como se indicó anteriormente, el mapa del sitio .xml con el formato correcto solo tenía una entrada que apuntaba al mapa del sitio .xml adicional que no se resolvería en un navegador, pero se mostraría correctamente en el código fuente.

Bueno, este problema se ha convertido en un problema mayor ya que el mapa del sitio .xml adicional generó un código de respuesta 500, por lo que hay un problema con el agente de Google que accede a esta área del sitio. Y, a partir de hoy, ambos mapas de sitio .xml están generando 500 códigos de respuesta. La semana anterior, solicitamos un rastreo utilizando la herramienta de obtención, procesamiento y envío disponible para nosotros en Google Search Console, lo que creemos que provocó el rastreo y la indexación del nuevo sitio.

Entonces, para terminar, si puede salir mal, lo hará cuando reconstruya su sitio web y, con suerte, podrá evitar algunos de estos errores. El bloqueo de los bots en el archivo robots.txt y la redirección incorrecta puede dejarlo fuera del negocio en línea o, al menos, en peligro. Si los bots no pueden rastrear su sitio, finalmente saldrá del índice y, cuando lo haga, a menos que provengan de referencias, fuentes directas u otras fuentes no orgánicas, la mayoría de las visitas de búsqueda orgánica dejarán de existir.

Si los resultados no redirigen correctamente, los visitantes orgánicos pueden ver su sitio como no confiable. Los clientes existentes que tienen su sitio guardado como favorito pueden sentirse frustrados cuando su favorito no se redirige correctamente. Sin mencionar que tuvimos que cerrar su campaña de PPC mientras tanto. Hacer clic en un anuncio pagado y obtener una respuesta de página 404 no encontrada no solo es frustrante para sus visitantes, ¡es costoso! El clic le cuesta dinero y no obtiene retorno de su inversión. Y, es por eso que nos tienes.

– Mark Gray, gerente sénior de SEO