Resumen: Antes de conquistar las primeras posiciones, los rastreadores de Google necesitan encontrar el camino. Un robots.txt mal configurado, un sitemap inaccesible o páginas 404 disfrazadas de éxito son obstáculos invisibles que frenan el ascenso. Esta guía detalla las 13 reglas de SEO técnico que debes auditar para que Googlebot pueda rastrear, indexar y valorar correctamente cada página de tu web.
Solicitar auditoría SEO gratuita → Ver servicios SEO →
Tabla de contenidos
- ¿Por qué el SEO técnico es la base del ascenso?
- Reglas 1–3: robots.txt — existencia, validez y bloqueos
- Regla 4: sitemap.xml — existencia y accesibilidad
- Reglas 5–6: sitemap.xml — validez e indexabilidad
- Reglas 7–8: estructura de URLs — longitud y profundidad
- Regla 9: página 404 real y personalizada
- Reglas 10–11: soft 404s y páginas con errores inesperados
- Reglas 12–13: errores 5xx y páginas de error con contenido útil
- Cómo priorizar los fallos de SEO técnico
- Checklist de las 13 reglas
- Preguntas frecuentes
¿Por qué el SEO técnico es la base del ascenso?
Imagina que has creado el mejor contenido posible para tu web: artículos profundos, páginas de servicio bien estructuradas, landing pages optimizadas. Pero si los rastreadores de Google no pueden llegar hasta ese contenido, todo ese trabajo queda invisible. El SEO técnico es el campamento base desde el que sale cada expedición de rastreo.
El proceso de posicionamiento tiene tres etapas que deben funcionar en orden: rastreo, indexación y posicionamiento. Un fallo en la primera etapa bloquea todo lo demás. Googlebot necesita:
- Permiso para rastrear: el archivo robots.txt indica a los rastreadores qué pueden visitar y qué no. Un error aquí puede bloquear secciones enteras del sitio.
- Un mapa del terreno: el sitemap.xml le da a Google una lista explícita de URLs que quieres que indexe, con metadatos de fecha de modificación y prioridad.
- URLs limpias y accesibles: una estructura de URLs profunda, farragosa o llena de errores dificulta el rastreo y desperdicia el presupuesto de crawl.
- Respuestas HTTP correctas: cada URL debe devolver el código de estado HTTP apropiado. Una página inexistente que devuelve 200 confunde a Google; un recurso válido que devuelve 404 le indica que ya no existe.
Estas 13 reglas cubren exactamente esas cuatro áreas. Son las que auditan herramientas como SEOmator en su categoría de Technical SEO, y son las que marcan la diferencia entre una web que Google puede rastrear eficientemente y una que desperdicia presupuesto de crawl en cada visita.
Reglas 1–3: robots.txt — existencia, validez y bloqueos
El archivo robots.txt es el primer documento que lee Googlebot cuando visita un dominio. Está disponible en https://tudominio.com/robots.txt y le indica a los rastreadores qué rutas pueden visitar. Un error en este archivo puede tener consecuencias graves e inmediatas.
Regla 1: robots.txt existe y es accesible
El archivo robots.txt debe existir en la raíz del dominio y responder con código HTTP 200. Si el servidor devuelve 404 para esta URL, los rastreadores asumen que no hay restricciones — lo cual no es un problema en sí mismo, pero puede serlo si dependes de ese archivo para controlar el rastreo. Si el servidor devuelve 500 u otro error, Googlebot puede dejar de rastrear el sitio temporalmente por precaución.
Cómo verificarlo: accede directamente a https://tudominio.com/robots.txt en el navegador. Debes ver el contenido del archivo y el servidor debe responder con código 200. Google Search Console también alerta cuando robots.txt está inaccesible.
✅ escala14.com supera esta regla: el archivo robots.txt existe, está accesible y responde con código 200.
Regla 2: robots.txt tiene sintaxis válida
La sintaxis de robots.txt es simple pero estricta. Un archivo mal formado puede ser interpretado de manera inesperada por los diferentes rastreadores. Los errores más frecuentes son:
- Espacios antes del nombre del agente o la directiva
- Directivas incorrectamente escritas (
Disalow en lugar de Disallow) - Rutas sin barra inicial (
Disallow: admin en lugar de Disallow: /admin/) - Comentarios mal formados (deben empezar siempre con
#)
# Ejemplo de robots.txt con sintaxis válida
User-agent: *
Disallow: /admin/
Disallow: /privado/
Allow: /
# Referencia al sitemap
Sitemap: https://tudominio.com/sitemap.xml
Cómo verificarlo: Google Search Console dispone de un probador de robots.txt en la sección de Configuración → robots.txt. Te muestra cómo interpreta el archivo y si detecta errores de sintaxis.
✅ escala14.com supera esta regla: el archivo robots.txt tiene sintaxis válida y no genera advertencias en Google Search Console.
Regla 3: robots.txt no bloquea páginas importantes
Este es el error más peligroso que puede ocurrir con robots.txt. Un Disallow: / en el agente universal bloquea todo el sitio de un golpe. Pero también hay bloqueos más sutiles: bloquear la carpeta de CSS o JavaScript puede impedir que Googlebot renderice el sitio correctamente; bloquear categorías de blog con contenido indexable equivale a esconder esas páginas de Google.
Los bloqueos que tienen sentido legítimo son: paneles de administración, áreas privadas tras autenticación, páginas de carrito o checkout, URLs de paginación duplicada y parámetros de filtros que generan contenido duplicado.
# Bloqueos que tienen sentido
User-agent: *
Disallow: /wp-admin/
Disallow: /carrito/
Disallow: /mi-cuenta/
# Esto es un error crítico: bloquea todo el sitio
User-agent: *
Disallow: /
⚠️ Advertencia frecuente: después de migraciones o rediseños web, es habitual encontrar el Disallow: / que se usó en la fase de desarrollo todavía activo en producción. Revisa siempre este archivo antes de lanzar una web nueva o tras cualquier migración.
✅ escala14.com supera esta regla: el robots.txt no bloquea ninguna página ni sección relevante para el posicionamiento.
Regla 4: sitemap.xml — existencia y accesibilidad
El sitemap.xml es el mapa del terreno que le entregas a Google. No es obligatorio — Googlebot puede descubrir URLs por sí solo siguiendo los enlaces internos — pero un sitemap acelera el rastreo, garantiza que ninguna URL quede sin descubrir y permite enviar metadatos de prioridad y fecha de modificación.
Regla 4: sitemap.xml existe y es accesible
El sitemap debe estar disponible en https://tudominio.com/sitemap.xml (o en la ruta que hayas declarado en robots.txt) y responder con código HTTP 200. Si el sitemap no existe o devuelve error, Google lo detectará como fallo en Search Console.
Cómo verificarlo: accede directamente a https://tudominio.com/sitemap.xml. Debes ver un archivo XML con la lista de URLs. Adicionalmente, envía el sitemap manualmente en Google Search Console → Sitemaps para confirmarlo.
La línea que referencia el sitemap en robots.txt es fundamental para que todos los rastreadores lo encuentren automáticamente:
# Al final de tu robots.txt
Sitemap: https://tudominio.com/sitemap.xml
✅ escala14.com supera esta regla: el sitemap.xml existe, responde con código 200 y está referenciado en robots.txt y enviado a Google Search Console.
Reglas 5–6: sitemap.xml — validez e indexabilidad
Tener un sitemap accesible no es suficiente si su contenido tiene errores o incluye URLs que no deberían indexarse. Estas dos reglas evalúan la calidad del contenido del sitemap.
Un sitemap XML mal formado — etiquetas sin cerrar, caracteres especiales sin codificar, encoding incorrecto — puede hacer que Google rechace el archivo completo o procese solo una parte de él. Los validadores XML son estrictos: un solo carácter incorrecto puede invalidar todo el documento.
Los errores más frecuentes en sitemaps:
- URLs con ampersands (
&) sin codificar como & - URLs con espacios en lugar de
%20 - Etiquetas
<url> sin <loc> dentro - Fechas en formato incorrecto (debe ser ISO 8601:
2026-03-17T00:00:00Z) - Encoding del archivo distinto del declarado en la cabecera XML
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://tudominio.com/pagina/</loc>
<lastmod>2026-03-17T00:00:00Z</lastmod>
<changefreq>monthly</changefreq>
<priority>0.8</priority>
</url>
</urlset>
Cómo verificarlo: usa el validador de XML Sitemap de SEMrush, Screaming Frog o el propio Google Search Console, que indica el número de URLs enviadas vs. URLs indexadas y muestra los errores de formato detectados.
✅ escala14.com supera esta regla: el sitemap.xml tiene formato XML válido sin errores de sintaxis ni codificación.
Regla 6: las URLs del sitemap son indexables
El sitemap debe contener únicamente URLs que quieres que Google indexe. Incluir en el sitemap URLs con etiqueta noindex, URLs bloqueadas por robots.txt o páginas redirigidas es una señal de inconsistencia que confunde al rastreador y desperdicia presupuesto de crawl.
Los casos más habituales de URLs no indexables en sitemaps:
- Páginas con
noindex: si una URL tiene <meta name="robots" content="noindex">, no debería estar en el sitemap. - URLs bloqueadas en robots.txt: si robots.txt dice
Disallow para una ruta, esa URL no debería estar en el sitemap. - Redirects 301: el sitemap debe contener las URLs de destino final, no las que redirigen.
- URLs con parámetros: las versiones con parámetros de una URL canónica no deberían aparecer si la canónica ya está incluida.
Google interpreta la presencia de una URL en el sitemap como una señal de que quieres que sea indexada. Contradecir esa señal con un noindex crea una ambigüedad que siempre se resuelve a favor del noindex, pero genera ruido innecesario en el proceso de rastreo.
✅ escala14.com supera esta regla: todas las URLs incluidas en el sitemap son indexables, sin conflictos con robots.txt ni etiquetas noindex.
Reglas 7–8: estructura de URLs — longitud y profundidad
La estructura de las URLs afecta tanto al rastreo como a la usabilidad y al posicionamiento. URLs limpias, cortas y con jerarquía clara son más fáciles de rastrear, más fáciles de entender para el usuario y más fáciles de enlazar.
Regla 7: URLs no demasiado largas (≤ 115 caracteres recomendado)
Google no tiene un límite técnico estricto para la longitud de las URLs, pero sí hay evidencia de que las URLs muy largas tienen menor visibilidad en los resultados de búsqueda: se truncan en los snippets, son más difíciles de compartir y suelen indicar una estructura de URLs generada automáticamente con parámetros innecesarios.
El umbral de referencia más usado en las herramientas de auditoría SEO es de 115 caracteres. Por encima de esa longitud, los auditores marcan la URL como candidata a revisión.
Las causas más frecuentes de URLs excesivamente largas:
- Parámetros de sesión o tracking (
?session=abc123&utm_source=...&utm_medium=...) - Rutas generadas por CMS con IDs numéricos y slugs redundantes (
/categoria/subcategoria/2024/03/titulo-del-articulo/) - Slugs sin optimizar que reproducen el título completo del artículo con todas las palabras de relleno
# URL demasiado larga (ejemplo)
https://tudominio.com/blog/categoria/subcategoria/2026/03/17/como-mejorar-el-posicionamiento-seo-de-tu-pagina-web-en-google-paso-a-paso/
# URL limpia y corta
https://tudominio.com/mejorar-posicionamiento-seo/
✅ escala14.com supera esta regla: las URLs del sitio tienen una longitud media inferior a 60 caracteres, muy por debajo del umbral de 115.
Regla 8: profundidad de URLs no excede 3–4 niveles
La profundidad de una URL hace referencia al número de directorios entre el dominio raíz y la página. Una URL como https://tudominio.com/nivel1/nivel2/nivel3/nivel4/pagina/ tiene una profundidad de 5.
El problema de las URLs muy profundas es doble: para el rastreo, cuanto más lejos esté una página del dominio raíz, más peticiones necesita Googlebot para llegar hasta ella, lo que consume más presupuesto de crawl; para el usuario, indica una jerarquía excesivamente compleja que normalmente refleja una arquitectura de información deficiente.
La recomendación general es mantener todas las páginas importantes a un máximo de 3–4 clics desde la home. Esto coincide con una profundidad de URL de 3–4 niveles. Las páginas de blog con categorías y fechas en la URL son el caso más habitual donde se supera este umbral sin necesidad real.
Cómo auditarlo: herramientas de rastreo como Screaming Frog (filtro de depth) o el informe de rastreo de Google Search Console muestran la profundidad de cada URL indexada.
✅ escala14.com supera esta regla: la estructura de URLs del sitio tiene una profundidad máxima de 2 niveles para la mayoría de páginas, con las entradas de blog a profundidad 1 (directamente en el dominio raíz).
Regla 9: página 404 real y personalizada
Cuando un usuario o un rastreador accede a una URL que no existe, el servidor debe responder con el código HTTP 404 (Not Found). Esta es la señal correcta que indica a Google que esa URL no existe y no debe indexarse. Pero hay dos problemas frecuentes en este punto: que el servidor devuelva un código incorrecto, o que la página de error sea tan genérica que resulte inútil.
Regla 9: la página 404 devuelve código HTTP 404 y tiene contenido personalizado
La verificación tiene dos partes:
Parte 1 — Código HTTP correcto: accede a una URL inexistente en tu dominio (por ejemplo, https://tudominio.com/esta-pagina-no-existe/) y comprueba en las DevTools de Chrome (pestaña Network) que la respuesta tiene código 404, no 200. Si devuelve 200 con el mensaje de “página no encontrada”, tienes un soft 404 — uno de los problemas más graves y silenciosos del SEO técnico (ver regla 10).
Parte 2 — Contenido útil: la página de error 404 no debería ser una pantalla en blanco o un mensaje genérico del servidor. Una página 404 bien diseñada incluye:
- Un mensaje claro de que la página no existe
- Navegación principal accesible (el usuario no debería quedar atrapado)
- Un buscador interno o links a secciones relevantes
- Branding coherente con el resto del sitio
Una página 404 con contenido útil reduce la tasa de abandono cuando los usuarios llegan a URLs rotas y transmite una imagen de sitio cuidado y profesional.
HTTP/1.1 404 Not Found
Content-Type: text/html; charset=UTF-8
✅ escala14.com supera esta regla: las URLs inexistentes devuelven código 404 correcto y la página de error incluye navegación y links a las secciones principales del sitio.
Reglas 10–11: soft 404s y páginas con errores inesperados
Los soft 404s son el problema de rastreabilidad más difícil de detectar porque no se manifiestan como errores visibles: la página parece funcionar, el servidor devuelve 200, pero el contenido dice que algo no existe.
Regla 10: sin soft 404s
Un soft 404 es una página que devuelve código HTTP 200 pero muestra un mensaje de tipo “página no encontrada”, “producto no disponible” o “resultado vacío”. Desde el punto de vista del servidor, la petición fue un éxito. Desde el punto de vista de Google, está indexando una página sin contenido real.
Los soft 404s son especialmente frecuentes en:
- Tiendas online: un producto descatalogado que sigue en la base de datos y muestra una ficha vacía en lugar de devolver 404.
- Motores de búsqueda internos: la URL
/buscar/?q=termino-sin-resultados devuelve 200 con “No se encontraron resultados”, y Google la indexa como página de contenido. - Sistemas con autenticación: una página protegida que redirige al login devolviendo 200 en lugar de 401.
- Páginas de paginación vacías:
/pagina/99/ de un blog con solo 5 páginas de resultados, que muestra la paginación vacía con código 200.
Cómo detectarlos: Google Search Console → Cobertura → Excluidas → “Página rastreada, no indexada actualmente” o “Soft 404” incluye un informe específico de soft 404s detectados. También puedes buscarlos con Screaming Frog revisando las páginas con código 200 y volumen de contenido muy bajo.
La corrección depende del caso: en general, las URLs que no tienen contenido real deben devolver 404 (si el recurso no existe) o redirigir con 301 a la URL más relevante (si el contenido se ha movido).
✅ escala14.com supera esta regla: no hay soft 404s detectados. Las páginas sin contenido real devuelven los códigos de error correctos.
Regla 11: sin páginas rotas con códigos 4xx inesperados
Además de las URLs genuinamente inexistentes (que deben devolver 404), hay otro grupo de errores 4xx que indican problemas de configuración o mantenimiento:
- 400 Bad Request: la petición tiene formato incorrecto — suele ocurrir con URLs malformadas que deberían tener una redirección.
- 401 Unauthorized / 403 Forbidden: páginas que requieren autenticación o permisos. Si están siendo enlazadas desde el sitio público, es un fallo de arquitectura.
- 410 Gone: indica que el recurso fue eliminado permanentemente. Es más definitivo que el 404 y le indica a Google que no reintente rastrear esa URL.
- 429 Too Many Requests: el servidor está limitando las peticiones de Googlebot — puede hacer que el rastreo se ralentice o detenga.
El objetivo es que ninguna URL que sea enlazada desde el sitio (interna o externamente) devuelva un código de error inesperado. Las únicas 4xx aceptables son los 404 correctamente gestionados con su página de error y, opcionalmente, los 410 para recursos eliminados permanentemente.
Cómo auditarlos: Screaming Frog en modo rastreo filtra por código de estado y muestra todas las URLs que devuelven 4xx con el anchor text y la página que las enlaza. Google Search Console → Cobertura → Error también lista las páginas con errores de rastreo.
✅ escala14.com supera esta regla: no hay URLs internas que devuelvan códigos 4xx inesperados. Las páginas eliminadas tienen redirecciones 301 o devuelven 404 con página de error correcta.
Reglas 12–13: errores 5xx y páginas de error con contenido útil
Los errores del servidor (5xx) son los más graves desde el punto de vista de disponibilidad: indican que el servidor no pudo procesar la petición, no que el recurso no exista. Si Google encuentra errores 5xx con frecuencia, puede reducir la velocidad de rastreo o, en casos extremos, retirar páginas del índice temporalmente.
Regla 12: sin errores de servidor 5xx
Los errores 5xx más frecuentes en entornos web son:
- 500 Internal Server Error: error genérico del servidor — suele indicar un fallo en el código del backend, configuración de PHP/Node.js o base de datos.
- 502 Bad Gateway / 503 Service Unavailable: el servidor está saturado, en mantenimiento o la conexión con el backend ha fallado.
- 504 Gateway Timeout: la petición tardó demasiado en procesarse — puede indicar consultas de base de datos lentas o sobrecarga del servidor.
Un error 5xx puntual durante un pico de tráfico no tiene impacto SEO significativo. El problema son los errores 5xx recurrentes o persistentes en páginas importantes: Google Search Console los registra y si se acumulan sin resolverse, afectan a la percepción de fiabilidad del sitio.
Cómo monitorizarlos: Google Search Console → Cobertura → Error agrupa los errores de rastreo por tipo y muestra las URLs afectadas con fecha del último rastreo. También es recomendable tener alertas de disponibilidad externas (UptimeRobot, Pingdom o similar) que notifiquen cuando el sitio devuelve errores 5xx.
✅ escala14.com supera esta regla: no hay errores 5xx activos. El sitio se sirve como Astro estático con CDN, lo que elimina prácticamente los errores de servidor al no haber backend dinámico.
Regla 13: páginas de error con contenido útil (no en blanco)
Esta regla complementa a la regla 9. No solo la página 404 debe tener contenido útil: cualquier página de error que pueda mostrar el sitio (500, 503, mantenimiento) debe tener contenido HTML coherente con el branding del sitio.
Una página de error en blanco o con el mensaje genérico del servidor (como “500 Internal Server Error” en texto plano sobre fondo blanco) causa dos problemas: el usuario no entiende qué ha pasado y no tiene forma de continuar navegando; y algunos rastreadores pueden interpretar una respuesta de error sin contenido como un problema diferente al que realmente es.
Las páginas de error bien diseñadas incluyen:
- El código y tipo de error explicado en lenguaje natural
- La navegación principal del sitio (o al menos un link a la home)
- Información de contacto o alternativas de acceso
- Branding coherente que transmita que el error es temporal
<!-- Ejemplo de página 500 útil -->
<h1>Algo salió mal en la ruta</h1>
<p>Nuestro servidor encontró un problema inesperado. El equipo ya está trabajando en ello.</p>
<a href="/">Volver al inicio →</a>
✅ escala14.com supera esta regla: las páginas de error del sitio tienen contenido HTML con navegación y branding coherente.
Cómo priorizar los fallos de SEO técnico
Cuando una auditoría devuelve varios fallos simultáneos, el orden de ataque debe seguir la severidad del impacto en el rastreo y la indexación:
| Prioridad | Regla | Impacto | Esfuerzo |
|---|
| Crítica | robots.txt bloquea páginas importantes | Desindexación masiva inmediata | Bajo — editar el archivo |
| Crítica | robots.txt inaccesible (500) | Google puede pausar el rastreo | Bajo — restaurar el archivo |
| Crítica | Soft 404s en páginas rastreadas | Google indexa páginas vacías | Medio — corregir códigos de respuesta |
| Crítica | sitemap.xml inaccesible | Rastreo más lento y menos completo | Bajo — restaurar el sitemap |
| Alta | sitemap.xml con URLs no indexables | Señales contradictorias para Google | Medio — limpiar el sitemap |
| Alta | Página 404 devuelve 200 | Google indexa la página de error | Medio — configurar respuesta correcta |
| Alta | Errores 5xx recurrentes | Reducción de frecuencia de rastreo | Medio/Alto — depurar el servidor |
| Media | URLs muy largas (>115 caracteres) | Menor visibilidad en SERPs | Alto — rediseñar estructura de URLs |
| Media | Profundidad de URLs excesiva | Menor eficiencia de rastreo | Alto — reestructurar arquitectura |
| Media | robots.txt sin referencia al sitemap | Google puede no encontrar el sitemap | Bajo — añadir línea Sitemap: |
| Baja | sitemap.xml con formato inválido | Sitemap parcialmente procesado | Medio — corregir XML |
| Baja | Página 404 sin contenido útil | Mayor tasa de abandono | Bajo — diseñar página 404 |
| Baja | Errores 4xx en URLs no enlazadas | Sin impacto si no están enlazadas | Bajo — revisar si hay links internos |
Consejo práctico: los fallos críticos de robots.txt y sitemap son los que resuelves primero porque pueden tener impacto inmediato y masivo. Los problemas de estructura de URLs son los de mayor esfuerzo y menor urgencia — solo tiene sentido abordarlos como parte de una reestructuración de arquitectura planificada, nunca de forma aislada.
Nuestro resultado en escala14.com: las 13 reglas de SEO técnico se superan sin fallos en nuestra auditoría. El sitio se sirve como Astro estático con generación automática de sitemap y robots.txt, lo que elimina la mayoría de los errores de configuración habituales en CMS dinámicos.
Checklist de las 13 reglas
Usa esta lista como referencia en cada auditoría. El estado indica el resultado sobre escala14.com como referencia real:
robots.txt (1–3)
sitemap.xml (4–6)
Estructura de URLs (7–8)
Páginas 404 (9)
Soft 404s y errores 4xx (10–11)
Errores de servidor (12–13)
Resultado de escala14.com: 13 superadas ✅ · 0 advertencias ⚠️ · 0 fallos ❌ → Score: 100/A
Preguntas frecuentes
¿Qué pasa si no tengo un archivo robots.txt?
Si el servidor devuelve 404 para robots.txt, la mayoría de rastreadores asumen que no hay restricciones y rastrean el sitio completo. No es un error crítico por sí solo, pero sí una oportunidad perdida: sin robots.txt, no puedes controlar qué partes del sitio rastrean los bots, no puedes indicar la ubicación del sitemap y no puedes evitar el rastreo de páginas de administración o duplicadas.
¿Un sitemap garantiza que Google indexe todas las páginas incluidas?
No. El sitemap es una recomendación, no una orden. Google puede decidir no indexar una URL que aparece en el sitemap si considera que el contenido es de baja calidad, está duplicado o tiene otras señales negativas. Lo que sí hace el sitemap es asegurarse de que Google descubra esas URLs — la decisión de indexarlas o no sigue siendo de Google.
¿Qué diferencia hay entre un 404 y un 410?
Ambos indican que la URL no tiene contenido, pero con matices distintos. El 404 (Not Found) indica que el recurso no se encontró — puede ser temporal o permanente. El 410 (Gone) indica que el recurso fue eliminado de forma permanente y no va a volver. En la práctica, Google tarda más en dejar de rastrear una URL con 404 que una con 410, porque el 404 puede ser transitorio. Para páginas eliminadas deliberadamente, usar 410 es más eficiente.
¿Cómo detecto soft 404s en mi web?
Google Search Console es la herramienta principal: en la sección de Cobertura → Excluidas busca el estado “Soft 404”. También puedes rastrear el sitio con Screaming Frog y exportar las páginas con código 200 y volumen de contenido muy bajo (columna “Word Count” menor de 50-100 palabras). Otro método es buscar manualmente: accede a URLs que esperas que no existan y comprueba el código de respuesta con las DevTools del navegador.
¿Cuántas URLs debería tener mi sitemap?
El protocolo de sitemaps tiene un límite de 50.000 URLs por archivo y 50 MB de tamaño. Para sitios con más URLs, se usa un sitemap index que apunta a múltiples sitemaps. En la práctica, la mayoría de webs corporativas, blogs y tiendas medianas tienen menos de 10.000 URLs y un único sitemap es suficiente. Lo importante no es el volumen sino la calidad: incluye solo URLs que quieres indexar y mantén el sitemap actualizado con las fechas de modificación reales.
¿Las URLs largas penalizan directamente en Google?
No hay una penalización directa confirmada por Google para URLs largas. El impacto es más indirecto: las URLs largas se truncan en los snippets de los resultados de búsqueda (lo que reduce el atractivo del resultado), son más difíciles de compartir, y suelen ser síntoma de una estructura de URLs con parámetros innecesarios que pueden generar contenido duplicado — ese sí es un problema SEO directo.
Conclusión
El SEO técnico es el equipamiento base que necesitas antes de empezar a escalar posiciones. Un robots.txt mal configurado puede bloquear secciones enteras del sitio sin que te enteres; un sitemap con URLs noindex envía señales contradictorias a Google; y los soft 404s son el tipo de problema que se acumula silenciosamente hasta que empiezas a perder posiciones sin una causa aparente.
Con estas 13 reglas como guía, tienes un mapa claro de qué revisar, qué priorizar y cómo resolver cada fallo. La mayoría de las correcciones son cambios de configuración o de código relativamente directos — la dificultad no está en la solución sino en detectar los problemas. Por eso la auditoría periódica es tan importante: muchos de estos errores no son visibles en el día a día y solo aparecen cuando los buscas explícitamente.
Si quieres que revisemos el SEO técnico de tu web y te entreguemos un informe con los problemas priorizados, cuéntanos qué necesitas. Sin compromiso.
Solicitar auditoría SEO gratuita → Ver servicios SEO → Seguridad web en SEO: 16 reglas para auditar → Links en SEO: 19 reglas para auditar →