Loading...
Google

10 factores técnicos de SEO en el sitio para evaluar en una auditoría de SEO

Su auditoría de SEO debe descubrir cualquier problema técnico común de SEO que impida que su sitio se clasifique. Esto es lo que debe verificar y cómo.

El SEO técnico es increíblemente importante. Necesita una base técnica sólida para tener éxito.

Es una necesidad y no opcional.

También hay quienes creen que es más importante que nunca ser técnico.

Estoy totalmente de acuerdo con ambos artículos.

Ya sea que se trate de conocimientos de programación, arquitectura de servidor, arquitectura de sitios web, JavaScript, CSS o lo que sea, tener este conocimiento lo pondrá un paso por encima del resto.

El SEO técnico lo ayudará a optimizar su propio sitio e identificar problemas en sitios web que los SEO no técnicos no pueden detectar.

De hecho, en algunos casos, puede ser crítico realizar SEO técnico antes de tocar la construcción de enlaces.

Examinemos algunos de los problemas técnicos de SEO más comunes y realicemos algunas comprobaciones y balances para que podamos solucionarlos.

1. Sitemaps

La presencia de un archivo de mapa del sitio en su sitio ayudará a los motores de búsqueda:

  • Comprender mejor su estructura.
  • Donde se encuentran las páginas.
  • Más importante aún, déle acceso a su sitio (suponiendo que esté configurado correctamente).

Los mapas de sitio XML pueden ser simples, con una línea del sitio por línea. No tienen que ser bonitas.

Los mapas de sitio HTML pueden beneficiarse de ser “más bonitos” con un poco más de organización para arrancar.

Como revisar

Este es un control bastante simple. Dado que el mapa del sitio está instalado en el directorio raíz, puede verificar la presencia del archivo del mapa del sitio buscándolo en Screaming Frog, o puede verificarlo en el navegador agregando sitemap.xml o sitemap.html.

Además, asegúrese de consultar la sección de sitemaps en Google Search Console.

Le indicará si se ha enviado previamente un mapa del sitio, cuántas URL se indexaron correctamente, si hay algún problema y otros problemas.

Si no tiene uno, deberá crear uno.

Con Screaming Frog, es bastante sencillo crear un mapa del sitio XML. Simplemente haga clic en Sitemaps> Crear XML Sitemap.

Screaming Frog - XML Sitemap

Vaya a la pestaña Última modificación y desactívela.

Vaya a la pestaña Prioridad y desactívela. Vaya a la pestaña Cambiar frecuencia y desactívela.

Estas etiquetas no proporcionan muchos beneficios para Google y, por lo tanto, el mapa del sitio XML se puede enviar tal cual.

Todas las opciones adicionales (p. Ej., Imágenes, páginas sin índice, URL canonicalizadas, URL paginadas o PDF) se pueden verificar si se aplican a su sitio.

Screaming Frog - XML Sitemap 1

También es una buena idea revisar su mapa del sitio en busca de errores antes de enviarlo. Use una herramienta de validación XML como CodeBeautify.org y XMLValidation.com.

El uso de más de un validador ayudará a garantizar que su mapa del sitio no tenga errores y que sea 100% correcto la primera vez que se envíe.

Además, cargar la lista de URL en Screaming Frog usando el modo de lista es una buena manera de verificar que su mapa del sitio también tenga los 200 errores OK.

Elimine todo el formato y asegúrese de que solo sea una lista de URL.

Luego haga clic en Modo> Lista> cargar> Rastrear y asegúrese de que todas las páginas en el mapa del sitio tengan 200 errores OK.

2. Robots.txt

Identificar si el archivo robots.txt existe en el sitio es una buena manera de verificar el estado de su sitio. El archivo robots.txt puede aumentar o disminuir el rendimiento de un sitio web en los resultados de búsqueda.

Por ejemplo, si configura el archivo robots.txt en “no permitir: /”, ¡le está diciendo a Google que nunca indexe el sitio porque “/” es root!

Es importante establecer esto como una de las primeras comprobaciones en SEO porque muchos propietarios de sitios se equivocan.

Siempre se supone que debe establecerse en “no permitir:” sin la barra diagonal. Esto permitirá que todos los agentes de usuario rastreen el sitio.

Como revisar

Verifique en Google Search Console la presencia de un archivo robots.txt. Puede ir a Rastrear> Probador de robots.txt para hacer esto.

Le ayudará a ver lo que está actualmente en vivo en el sitio, y si alguna edición mejorará ese archivo.

También es una buena idea mantener registros del archivo robots.txt.

Las capturas de pantalla mensuales lo ayudarán a identificar si se realizaron cambios y cuándo, y le ayudarán a identificar errores en la indexación si surgiera alguno.

Si verifica el enlace “Ver robots.txt en vivo”, podrá investigar el estado actual en vivo del archivo robots.txt del sitio.

3. Errores de rastreo

La sección Errores de rastreo de GSC lo ayudará a identificar si actualmente existen errores de rastreo en el sitio.

Encontrar errores de rastreo y corregirlos es una parte importante de cualquier auditoría de sitios web porque cuanto más errores de rastreo tiene un sitio, más problemas tiene Google para encontrar páginas e indexarlas.

El mantenimiento técnico continuo de SEO de estos elementos es crucial para tener un sitio saludable.

Como revisar

En Google Search Console, identifique cualquier servidor 400 y 500 y no encuentre errores encontrados en el sitio. Todos estos tipos de errores deben llamarse y corregirse.

Además, puede usar Screaming Frog para buscar e identificar los códigos de error del servidor 400 y 500.

Simplemente haga clic en Exportación masiva> Códigos de respuesta> Enlaces de error del cliente (4xx) y enlaces de error del servidor (5xx).

4. Múltiples URL: URL mayúsculas y minúsculas

Este problema puede hacer que Google vea dos o más versiones de la página como fuente de contenido único en su sitio.

Pueden existir varias versiones, desde URL mayúsculas hasta URL en minúsculas, hasta URL con guiones y URL con guiones bajos.

Los sitios con problemas graves de URL pueden incluso tener lo siguiente:

https://www.example.com/this-is-the-url
https://www.example.com/This-Is-The-URL
https://www.example.com/this_is_the_url
https://www.example.com/thisIStheURL
https://www.example.com/this-is-the-url/
http://www.example.com/esto-es-the-url
http://example.com/esto-es-the-url
¿Qué está mal con esta imagen?

En este caso, existen siete versiones diferentes de URL para una pieza de contenido.

Esto es horrible desde la perspectiva de Google, y no queremos tener un lío en nuestras manos.

La forma más fácil de solucionar esto es señalar el rel = canonical de todas estas páginas a la única versión que debería considerarse la fuente del contenido único.

Sin embargo, la existencia de estas URL sigue siendo confusa. La solución ideal es consolidar las siete URL en un solo RL y establecer la etiqueta rel = canonical en esa misma URL.

Otra situación que puede suceder es que las URL pueden tener barras diagonales finales que no se resuelven correctamente a sus URL exactas. Ejemplo:

http://www.example.com/esto-es-the-url
http://www.example.com/esto-es-the-url

En este caso, la situación ideal es redirigir la URL de nuevo a la URL preferida original y asegurarse de que rel = canonical esté configurado en esa URL preferida.

Si no tiene el control total sobre las actualizaciones del sitio, vigílelas regularmente.

5. ¿El sitio tiene un certificado SSL (especialmente en comercio electrónico)?

Idealmente, la implementación de un sitio de comercio electrónico tendrá un certificado SSL.

Pero con los recientes movimientos de Google para preferir sitios que tienen certificados SSL por razones de seguridad, es una buena idea determinar si un sitio tiene un certificado seguro instalado.

Como revisar

Si un sitio tiene https: // en su dominio, tiene un certificado seguro, aunque la verificación a este nivel puede revelar problemas.

Si aparece una X roja junto a https: // en un dominio, es probable que el certificado seguro tenga problemas.

Screaming Frog no puede identificar problemas de seguridad como este, por lo que es una buena idea verificar ciertos problemas como https: // www, https: // blog o https: //.

Si dos de estos tienen X en ellos, a diferencia del dominio principal (si el dominio principal tiene https: //), es probable que durante el proceso de compra del certificado SSL se hayan cometido errores.

Para asegurarse de que todas las variaciones de https: // se resuelvan correctamente, es necesario obtener un certificado de comodín seguro.

Este certificado seguro comodín garantizará que todas las variaciones posibles de https: // se resuelvan correctamente.

6. Reducción de archivos CSS y JavaScript

Identificar el código CSS hinchado, junto con JavaScript hinchado, ayudará a disminuir el tiempo de carga de su sitio.

Muchos temas de WordPress son culpables de CSS y JavaScript hinchados, que si se tomara el tiempo necesario para minimizarlos adecuadamente, estos sitios podrían experimentar tiempos de carga de 2-3 segundos o menos.

Idealmente, la mayoría de las implementaciones de sitios web deberían presentar un archivo CSS y un archivo JavaScript.

Cuando se codifica correctamente, la falta de estos archivos minimiza las llamadas al servidor, los posibles cuellos de botella y otros problemas.

Como revisar

Con URIValet.com, es posible identificar cuellos de botella y problemas en el servidor con archivos CSS y JavaScript más grandes.

Vaya a URIValet.com, ingrese su sitio y examine los resultados.

7. Optimización de imagen

Identificar imágenes que son pesadas en el tamaño del archivo y que causan aumentos en el tiempo de carga de la página es un factor crítico de optimización para hacerlo bien.

Este no es un factor de optimización general, pero puede ofrecer una disminución considerable de la velocidad del sitio si se gestiona correctamente.

Usando nuestra araña Screaming Frog, podemos identificar los enlaces de imágenes en una página en particular.

8. Errores HTML / Validación W3C

Corregir los errores de HTML y la validación de W3C por sí mismos no aumenta la clasificación, y tener un sitio completamente válido de W3C no ayuda a su clasificación, según John Mueller de Google.

Dicho esto, corregir este tipo de errores puede ayudar a mejorar la representación en varios navegadores.

Si los errores son lo suficientemente graves, estas correcciones pueden ayudar a mejorar la velocidad de la página.

Pero es caso por caso. Simplemente hacer esto por sí solo no conducirá automáticamente a mejores clasificaciones para cada sitio.

De hecho, principalmente es un factor contribuyente, lo que significa que puede ayudar a mejorar el factor principal: la velocidad del sitio.

Por ejemplo, un área que puede ayudar incluye agregar ancho + alto a las imágenes.

Según W3.org, si se configuran el alto y el ancho, el “espacio requerido para la imagen se reserva cuando se carga la página”.

Esto significa que el navegador no tiene que perder el tiempo adivinando el tamaño de la imagen, y solo puede cargar la imagen en ese mismo momento.

Como revisar

Usar el validador W3C en W3.org puede ayudarlo a identificar errores HTML y corregirlos en consecuencia.

Asegúrese de utilizar siempre el DOCTYPE apropiado que coincida con el idioma de la página que está siendo analizada por el validador W3C.

Si no lo hace, recibirá errores en todo el lugar. No puede cambiar DOCTYPES de XHTML 1.0 a HTML 5, por ejemplo.

W3C validator

9. Optimización móvil y pruebas

Los dispositivos móviles llegaron para quedarse, y hay muchas razones para la optimización de dispositivos móviles.

Esto incluye el hecho de que Google dijo que la indexación móvil primero se estaba utilizando para más de la mitad de las páginas web en los resultados de búsqueda de Google a fines de 2018.

A partir del 1 de julio de 2019, Google ha anunciado que la indexación móvil primero es la predeterminada para cualquier dominio web nuevo.

Esto debería incluirse en sus auditorías debido a lo extenso que será ahora el móvil.

Estos problemas deben ser revisados.

Como revisar

Asegúrese de que todo el contenido que desarrolle se pueda ver en dispositivos móviles

Instale el conmutador de agente de usuario para Google Chrome.

Verifique su contenido en dispositivos móviles utilizando el conmutador de agente de usuario seleccionando iPhone, Samsung, etc.

Esto le mostrará cómo se ve su contenido en estos dispositivos.

Reduzca y expanda el tamaño de la ventana de su navegador para verificar esto.

Si el sitio tiene un diseño receptivo, verifique su teléfono móvil real.

Informe a su cliente cualquier hallazgo que tenga en los entregables de auditoría.

Qué verificar

  • Cualquier video que tenga en sus páginas debe cargarse y ser compatible con todos y cada uno de los posibles teléfonos inteligentes que usará su usuario.
  • Capacidad de desplazamiento de su contenido: esta capacidad permitirá que su contenido se desplace en cualquier dispositivo inteligente. No obligue a sus usuarios a hacer clic en el botón siguiente al botón siguiente; esto es extremadamente engorroso y destruye la experiencia del usuario.
  • Su diseño siempre debe ser receptivo. No vuelvas a usar un sitio web mobile.domainname.com nunca más. A menos que esto sea algo político para su empleador, no hay excusa para que ningún sitio web en 2019 tenga un móvil. o m. subdominio Cualquier sitio web debe ser 100% receptivo y debe usar las hojas de estilo adecuadas.
  • No uses AMP. A través de una serie de estudios de casos recientes que hemos realizado, la eliminación de AMP en realidad ha aumentado el tráfico, en lugar de causar problemas con el tráfico. Verifique las implementaciones de la codificación AMP y asegúrese de que la codificación no exista. Si es así, recomiende que el cliente lo elimine.

10. Forzar un dominio único

A pesar de muchas recomendaciones en línea, todavía me encuentro con muchos sitios web que tienen este problema importante.

Y este es el problema de la carga de múltiples URL, creando problemas masivos con contenido duplicado.

Cuando ingresa su dirección en su navegador web, puede probar variaciones de URL:

  • http://www.example.com/
  • https://www.example.com/
  • http://example.com/
  • https://example.com/
  • https://example.com/page-name1.html
  • https://www.example.com/page-name1.html
  • https://example.com/pAgE-nAmE1.html
  • https://example.com/pAgE-nAmE1.htm

Lo que sucederá es que todas estas páginas se cargan cuando ingresas la dirección web, creando una situación en la que tienes muchas páginas cargando para una URL, creando más oportunidades para que Google las rastree e indexe.

Este problema se multiplica exponencialmente cuando su proceso de enlace interno se sale de control y no utiliza el enlace correcto en su sitio.

Si no controla cómo se vincula a las páginas, y se cargan así, le está dando a Google la oportunidad de indexar el nombre de la página1.html, el nombre de la página1.htm, pAgE-nAmE1.html y pAgE-nAmE1.htm .

Todas estas URL seguirán teniendo el mismo contenido. Esto confunde exponencialmente al bot de Google, así que no cometas este error.

Como revisar

Puede verificar su lista de URL rastreada en Screaming Frog y ver si Screaming Frog ha recogido alguna de estas mismas URL.

También puede cargar diferentes variaciones de estas direcciones web para el sitio de su cliente en su navegador y ver si se carga contenido.

Si no se redirige a la URL correcta, y su contenido se carga en la nueva variación de URL, debe informar esto al cliente y recomendar la solución (redirija todas estas variaciones de URL a la principal).

Por qué no se incluyeron ciertas “señales”

Algunos SEO creen que las señales sociales pueden afectar las clasificaciones de manera positiva y negativa.

Otros SEO no lo hacen.

Los estudios de correlación, aunque se han realizado, continúan ignorando el factor principal: la correlación no es igual a la causalidad.

El hecho de que haya una mejora en la correlación entre los resultados sociales y las clasificaciones no siempre significa que las redes sociales mejoren la clasificación.

No es tan importante como algunos piensan tener redes sociales activas.

Sin embargo, es importante tener botones para compartir en redes sociales en el sitio, para que pueda compartir ese contenido y aumentar la posibilidad de que ese contenido obtenga enlaces para SEO.

Así que hay que pensar en esa dimensión cuando este tipo de cosas se incluye en esta guía de auditoría.

Podría haber una cantidad de enlaces adicionales agregados al mismo tiempo, o podría haber un enlace de autoridad increíblemente valioso que fue agregado, o cualquier otra cantidad de mejoras.

Gary Illyes de Google continúa manteniendo oficialmente que no usan las redes sociales para clasificar.

El objetivo de esta lista de verificación de auditoría de SEO es reunir controles en el sitio y fuera del sitio para ayudar a identificar cualquier problema, junto con consejos prácticos para solucionar estos problemas.

Por supuesto, hay una serie de factores de clasificación que no se pueden determinar fácilmente mediante verificaciones simples en el sitio o fuera del sitio y que requieren tiempo, métodos de seguimiento a largo plazo, así como en algunos casos, software personalizado para ejecutarse.

Estos están más allá del alcance de esta guía.

Con suerte, esta lista le resultó útil.

Diviértete y feliz auditando el sitio web.

Fuente y foto: https://www.searchenginejournal.com/seo-audit/on-site-technical-seo-factors