Respuesta directa: «seo dev» es el trabajo de SEO que se hace tocando código y configuración del servidor, no redactando textos: rastreo, indexación, datos estructurados, rendimiento y arquitectura de URLs. En esta sección de GlobalTool tienes cuatro utilidades gratuitas que funcionan en el navegador, sin registro y sin enviar tus datos a ningún servidor:
- Generador de Meta Tags SEO — escribe el bloque de
<title>,meta description, Open Graph y Twitter Cards listo para pegar. - Generador de Slugs URL-Friendly — convierte un titular con tildes, eñes y signos en una ruta limpia.
- JSON Formatter — indenta y valida JSON; te avisa de dónde está el error de sintaxis.
- HTML Beautifier — devuelve legible el HTML minificado que escupe una plantilla o un build.
El resto de la página es la guía: qué controla cada mecanismo del rastreo, qué códigos de estado usar, cómo no romper el hreflang y qué partes del rendimiento dependen de ti y no del diseñador.
Qué hace un seo dev y dónde termina su trabajo
Hay una división de tareas que conviene tener clara desde el principio, porque evita discusiones de equipo y trabajo duplicado. El SEO de contenidos decide de qué se habla, con qué intención de búsqueda y con qué profundidad. El seo dev decide si eso que se ha escrito llega a existir para un buscador: si la URL se puede rastrear, si devuelve un 200, si el HTML que ve el robot contiene el texto, si el marcado describe la página y si se carga lo bastante rápido como para que el usuario no se vaya antes de verla.
Dicho de otra forma: el contenido es la oferta y la capa técnica es el escaparate. Puedes tener el mejor artículo del sector detrás de un Disallow mal escrito y no servirá de nada. Y al revés, una arquitectura impecable con textos vacíos tampoco rankea. Las dos capas se necesitan, pero los fallos técnicos tienen una propiedad incómoda: son silenciosos. Nadie recibe un aviso cuando un despliegue añade un noindex a la plantilla base; el tráfico simplemente empieza a bajar tres semanas después.
Un fallo de contenido se nota al leerlo. Un fallo técnico se nota cuando ya llevas un mes perdiendo visitas. Por eso la parte de seo dev se automatiza y se comprueba en cada despliegue, no cuando alguien se acuerda.
Las cinco áreas que cubre
Rastreo. Que el robot pueda llegar al recurso y descargarlo. Depende de robots.txt, de la arquitectura de enlaces, de si hay paredes de login o de JavaScript, de los tiempos de respuesta del servidor y de que no haya cadenas de redirecciones interminables.
Indexación. Que el buscador decida guardar esa URL en su índice. Depende de las directivas meta robots y X-Robots-Tag, del rel="canonical", de si el contenido aporta algo que no esté ya en otra URL del mismo sitio y de la calidad general del dominio.
Comprensión. Que entienda de qué va la página. Aquí entran los encabezados jerarquizados, el texto en el HTML servido, los atributos alt, los anclajes de los enlaces internos y los datos estructurados en JSON-LD.
Rendimiento. Que la experiencia sea razonable en el dispositivo real del usuario. Core Web Vitals, peso de recursos, bloqueos del hilo principal, estabilidad visual.
Arquitectura. Que el conjunto tenga sentido: URLs estables y legibles, paginación coherente, navegación facetada bajo control, versiones de idioma correctamente emparejadas y una jerarquía en la que ninguna página importante quede a seis clics de la portada.
Las cuatro herramientas de esta sección, una a una
Son utilidades pequeñas y deliberadamente aburridas. No prometen auditar tu sitio ni darte una puntuación: resuelven un paso concreto del día a día y te devuelven al editor. Todas se ejecutan en tu navegador, así que puedes pegar en ellas HTML o JSON de un proyecto privado sin que el contenido salga de tu equipo.
Generador de Meta Tags SEO
Escribes título, descripción, URL, idioma e imagen social, y te devuelve el bloque completo de etiquetas para pegar en el <head>: title, meta description, canonical, Open Graph y Twitter Card. Sirve sobre todo para dos cosas. La primera, no olvidarte de la mitad de las etiquetas cuando montas una plantilla nueva —el descuido típico es poner og:title y saltarte og:image, con lo que cualquier enlace compartido en redes sale con una tarjeta gris—. La segunda, ver el texto del título antes de publicarlo y decidir si aguanta.
Sobre la longitud del título hay mucho mito. Los resultados de búsqueda no se cortan por número de caracteres sino por ancho en píxeles del contenedor, que cambia según el dispositivo, y una «i» ocupa mucho menos que una «W». La regla práctica útil es distinta: pon lo que identifica la página en los primeros términos, porque es lo único que tienes garantizado que se lee. Y recuerda que el buscador puede reescribir tu título si considera que otro texto de la página describe mejor lo que hay dentro; eso no es un castigo, es una señal de que el título y el contenido no casaban del todo.
La meta description tampoco es un factor de posicionamiento y también se reescribe con frecuencia. Su trabajo real es ganar el clic frente a los nueve resultados que tiene alrededor. Escríbela como una promesa concreta y comprobable, no como un resumen de la página.
Generador de Slugs URL-Friendly
Pegas un titular en castellano —con tildes, eñes, signos de apertura, comillas tipográficas, guiones largos— y sale una ruta limpia en minúsculas separada por guiones. Parece trivial hasta que alguien publica una URL con un carácter que el CMS codifica en percent-encoding y acabas con algo como /c%C3%B3mo-hacerlo/ enlazado desde media web.
Dos convenciones que llevan años siendo recomendación estándar y que esta herramienta aplica sola: separa palabras con guiones y no con guiones bajos, y usa minúsculas de forma consistente. Lo segundo importa más de lo que parece en servidores sensibles a mayúsculas, donde /Guia/ y /guia/ son dos recursos distintos que pueden servir el mismo contenido y duplicarse en el índice.
Y una decisión que hay que tomar una vez y no volver a tocar: barra final sí o barra final no. Técnicamente /guia y /guia/ son URLs diferentes. Elige una, redirige la otra con un 301 permanente y asegúrate de que el canonical, el sitemap y los enlaces internos usan la misma forma. Ver las tres cosas discrepando entre sí es de lo más habitual en auditorías.
JSON Formatter
Indenta JSON ilegible y, sobre todo, valida. Cuando algo falla te dice en qué punto se rompe la sintaxis, que suele ser una coma de más antes de una llave de cierre o unas comillas tipográficas que se han colado al copiar desde un documento de texto.
En el contexto de esta sección su uso principal es revisar bloques de JSON-LD antes de meterlos en la plantilla. Un JSON-LD con un error de sintaxis no se ignora parcialmente: se descarta entero. Puedes tener cincuenta líneas de marcado perfecto invalidadas por una coma. Formatear y validar antes de pegar ahorra ese rato de buscar a ojo dentro de una sola línea minificada.
También sirve para leer respuestas de API cuando estás montando integraciones, o para revisar un archivo de configuración que el build ha aplanado.
HTML Beautifier
Toma HTML minificado o mal indentado y lo devuelve legible, con la anidación visible. Su momento típico es cuando abres el código fuente servido de una página generada por un framework o un tema y te encuentras con tres mil caracteres en una sola línea.
Con el HTML formateado se ven cosas que de otro modo pasan desapercibidas: un <div> sin cerrar que deja el <main> anidado donde no toca, un segundo <h1> escondido en un banner, dos <link rel="canonical"> distintos en el mismo <head>, o una etiqueta de plantilla que se ha colado sin sustituir. Todos esos son fallos que el navegador perdona pintando algo razonable y que un robot interpreta de forma mucho menos indulgente.
Rastreo e indexación: cuatro mecanismos que la gente confunde
La mayoría de los desastres técnicos que se ven en producción nacen de mezclar herramientas que hacen cosas distintas. robots.txt, meta robots, canonical y el sitemap no son intercambiables ni redundantes: cada uno actúa en un momento diferente del proceso y algunos se anulan entre sí.
robots.txt controla el rastreo, no la indexación
El protocolo de exclusión de robots quedó formalizado como estándar en la RFC 9309, después de veinticinco años siendo una convención de facto. Se sirve en la raíz de cada combinación de protocolo, host y puerto: el archivo de https://ejemplo.com/robots.txt no rige para https://sub.ejemplo.com/, que necesita el suyo.
Lo que hace un Disallow es pedir al robot que no descargue ese recurso. Lo que no hace es sacarlo del índice. Si otras páginas enlazan a esa URL, el buscador puede listarla igualmente sin descripción, con un texto del tipo «no hay información disponible para esta página». Es la confusión más repetida del oficio y tiene una consecuencia perversa: si bloqueas por robots.txt una URL que además lleva noindex, el robot nunca podrá descargarla para leer el noindex, así que la directiva no se aplica jamás. Para sacar algo del índice hay que dejar rastrear y decirlo con noindex.
Otros detalles que muerden en despliegues reales: el archivo se cachea, así que un cambio no se aplica al instante; los buscadores procesan solo los primeros cientos de kilobytes del archivo, de modo que las listas gigantescas de rutas generadas automáticamente pueden quedar cortadas; y bloquear las carpetas de CSS o JavaScript impide que el robot renderice la página como la ve el usuario, lo que degrada su comprensión de la maquetación.
meta robots y X-Robots-Tag controlan la indexación
La etiqueta <meta name="robots" content="noindex"> en el <head> es la forma directa de decir «rastréala si quieres, pero no la guardes». Funciona solo si la URL es rastreable, como acabamos de ver.
Para recursos que no son HTML —PDF, imágenes, archivos descargables— no hay <head> donde poner la etiqueta, así que se usa la cabecera HTTP X-Robots-Tag. Es la forma correcta de mantener fuera del índice un catálogo en PDF o una factura de ejemplo, y también la más cómoda de aplicar reglas por patrón desde la configuración del servidor sin tocar plantillas.
La combinación noindex, follow tiene menos utilidad de la que se le atribuye: cuando una página deja de estar indexada de forma permanente, sus enlaces acaban perdiendo peso de todos modos. Úsala para lo que sirve de verdad, que es no indexar páginas de utilidad —resultados de búsqueda interna, paneles de usuario, páginas de agradecimiento tras un formulario— manteniéndolas navegables.
El canonical es una señal fuerte, no una orden
rel="canonical" le dice al buscador cuál de varias URLs con contenido equivalente es la buena. Consolida señales en esa versión. Pero es una sugerencia ponderada junto a otras: si el canonical apunta a una página cuyo contenido no se parece al de la original, o si los enlaces internos y el sitemap dicen lo contrario, el buscador puede elegir otra URL como canónica y tú te enteras meses después.
Reglas que evitan el noventa por ciento de los problemas: toda página lleva canonical, aunque sea a sí misma; el canonical siempre es absoluto y con el mismo protocolo y host que usas de verdad; nunca hay dos etiquetas canonical en el mismo documento —si las hay, el buscador ignora ambas—; y el destino del canonical devuelve un 200, no un 301 ni un 404.
Si el canonical, el sitemap y los enlaces internos de tu sitio no coinciden en cuál es la URL buena, no tienes tres opiniones: tienes un problema de arquitectura que ninguna etiqueta va a arreglar.
El sitemap propone, no obliga
Un sitemap XML es una lista de candidatas para rastrear. No fuerza la indexación ni compensa una arquitectura en la que las páginas no se enlazan entre sí. Su valor real aparece en sitios grandes, en sitios nuevos sin enlaces externos y en contenido que cambia a menudo.
Los límites del formato están en el propio protocolo: un archivo admite hasta 50.000 URLs y no puede superar los 50 MB sin comprimir. Si necesitas más, se encadenan varios mediante un índice de sitemaps. Merece la pena partirlos por tipo de contenido —productos, artículos, categorías— porque así los informes de cobertura te dicen qué sección tiene el problema en lugar de darte un único número inútil.
Dos etiquetas del formato ya no se tienen en cuenta en la práctica: <priority> y <changefreq> se ignoran, porque los buscadores aprendieron hace tiempo que todo el mundo se asignaba prioridad 1.0. <lastmod> sí se usa, pero solo si es honesto: si tu generador pone la fecha de hoy en las 40.000 URLs cada noche, deja de ser información y se descarta.
Y una regla que parece obvia y se incumple constantemente: en el sitemap solo van URLs que devuelven 200, que son canónicas de sí mismas y que no llevan noindex. Un sitemap lleno de redirecciones y de páginas bloqueadas es ruido que resta credibilidad al resto.
Tabla de decisión rápida
| Quiero… | Mecanismo correcto | Error frecuente |
|---|---|---|
| Que el robot no gaste recursos en una carpeta interna | Disallow en robots.txt | Creer que además la saca del índice |
| Sacar una página HTML del índice | meta robots noindex, con la URL rastreable | Bloquearla también en robots.txt, con lo que el noindex nunca se lee |
| Sacar un PDF o una imagen del índice | Cabecera X-Robots-Tag: noindex | Intentarlo con una etiqueta meta que ese formato no tiene |
| Unificar variantes con el mismo contenido | rel="canonical" absoluto a la versión buena | Apuntar a una URL que redirige o que no existe |
| Que descubra antes el contenido nuevo | Sitemap XML con lastmod real | Meter en él URLs con noindex o con redirección |
| Retirar una URL para siempre | 410 Gone, o 301 si hay destino equivalente | Redirigir todo a la portada de forma masiva |
Códigos de estado y redirecciones sin romper nada
El código de estado es la primera información que recibe un robot, antes de leer una sola etiqueta. Devolver el código equivocado hace que todo lo que venga después se interprete mal.
| Código | Significado | Cuándo usarlo en seo dev |
|---|---|---|
| 200 | Correcto | Cualquier página que quieras indexada. Comprueba que tus páginas de error no devuelven 200 con un texto de «no encontrado» dentro: eso genera índices llenos de basura. |
| 301 | Movido permanentemente | Cambios de URL definitivos: migración de dominio, normalización de barra final, paso a HTTPS. Consolida señales en el destino. |
| 302 | Movido temporalmente | Pruebas A/B, mantenimiento breve, geolocalización opcional. Si lo dejas puesto meses, acabará tratándose como permanente de todos modos. |
| 307 / 308 | Temporal / permanente preservando el método | Cuando la petición original es POST y no quieres que se convierta en GET. Habitual en APIs y formularios. |
| 404 | No encontrado | Contenido que no existe y podría volver. Sirve una página de error útil con enlaces reales, no un callejón sin salida. |
| 410 | Eliminado definitivamente | Contenido retirado a propósito. Acelera la salida del índice frente al 404. |
| 503 | Servicio no disponible | Mantenimiento planificado, acompañado de Retry-After. Es la forma correcta de decir «vuelve luego» sin que se interprete como desaparición. |
Cadenas y bucles
Cada salto de una redirección añade latencia para el usuario y trabajo para el robot. Una cadena de cuatro saltos —de http a https, de sin www a con www, de URL antigua a nueva, de sin barra a con barra— es fácil de construir sin darse cuenta cuando cada regla la añadió una persona distinta en un momento distinto. Aplana las cadenas para que el origen apunte directamente al destino final y revisa que ningún bucle se cierre sobre sí mismo, porque eso deja la URL inaccesible para todo el mundo.
Un orden de reglas que funciona: primero se canoniza el protocolo y el host en un solo salto, luego se aplica la normalización de la ruta, y solo después las redirecciones de contenido concretas. Al revés produce los dos saltos que querías evitar.
Datos estructurados en JSON-LD
Los datos estructurados describen a una máquina lo que un humano lee en la página: que esto es una receta, que aquello es un producto con un precio, que esta lista son preguntas frecuentes. No suben posiciones por sí solos, pero habilitan formatos enriquecidos en los resultados y ayudan al buscador a construirse una representación fiable de tu contenido.
JSON-LD es el formato recomendado porque va en un bloque aparte, no se entremezcla con el marcado visible y se puede generar desde el servidor sin tocar la plantilla de presentación. Microdatos y RDFa siguen siendo válidos, pero mantenerlos en una plantilla moderna es incómodo.
La regla que nunca se debe romper
El marcado tiene que describir lo que está visible en la página. Marcar como FAQPage unas preguntas que no aparecen en el texto, declarar un precio distinto del que muestra la ficha o publicar un aggregateRating sobre valoraciones que no existen son incumplimientos de las directrices de datos estructurados, y son también la vía más rápida para que un sitio pierda sus resultados enriquecidos de golpe.
Esta página lo cumple de forma literal: el bloque JSON-LD del final enumera las cuatro herramientas que existen de verdad en /seo-dev/ y repite las preguntas frecuentes que puedes leer más abajo, con el mismo texto. Nada más.
Tipos que rinden y cómo validarlos
Para un sitio de utilidades o de contenido, el conjunto que cubre casi todo es: WebSite y Organization en la portada, BreadcrumbList en todas las páginas interiores, Article o BlogPosting en el blog, FAQPage donde haya preguntas visibles, SoftwareApplication o WebApplication en las herramientas, y Product con Offer en fichas de venta.
El flujo de validación razonable son tres pasos: pasar el bloque por el JSON Formatter para confirmar que la sintaxis es válida, comprobarlo después con el validador de marcado de schema.org para ver si los tipos y propiedades son correctos, y por último usar la prueba de resultados enriquecidos del buscador para saber si además da derecho a algún formato especial. Los tres dicen cosas distintas y hacen falta los tres.
JavaScript, renderizado e indexación
Los buscadores modernos ejecutan JavaScript, pero no lo hacen a la vez que descargan el HTML. El proceso ocurre en dos fases: primero se rastrea y se indexa lo que viene en la respuesta inicial, y más tarde —cuando hay recursos disponibles— se renderiza la página en un navegador sin interfaz y se indexa lo que haya aparecido. Esa segunda fase puede tardar, y no está garantizada para todas las URLs de un sitio grande.
La conclusión práctica no es «el JavaScript es malo», sino: todo lo que necesites que se indexe con seguridad y rapidez debe estar en el HTML que sale del servidor.
Las tres estrategias, y para qué sirve cada una
Renderizado en cliente (CSR). El servidor manda un HTML casi vacío y el navegador construye la página. Es la opción cómoda para paneles y aplicaciones tras un login, donde la indexación no importa. Para contenido público es la que más problemas da.
Renderizado en servidor (SSR). El servidor devuelve el HTML ya construido para cada petición. Va bien cuando el contenido es personalizado o cambia por minutos. Cuesta más infraestructura y obliga a cuidar la caché.
Generación estática (SSG). Las páginas se construyen en el momento del despliegue y se sirven como archivos. Es lo más rápido y lo más barato de servir, y encaja con la mayoría de sitios de contenido, documentación y catálogos que no cambian cada minuto. Las variantes con regeneración incremental permiten actualizar solo lo que cambia sin reconstruir el sitio entero.
Errores concretos que rompen la indexación en aplicaciones JavaScript
- Navegación con
onclickyrouter.pushen lugar de etiquetas<a href>: el robot no dispara eventos, así que esas rutas no se descubren. - Contenido que solo aparece tras una interacción —una pestaña, un acordeón, un «ver más» que hace una petición—. Si el texto no está en el DOM tras el renderizado, no se indexa.
- Bloquear en
robots.txtla carpeta de bundles: el robot descarga el HTML vacío y no puede completarlo. - Etiquetas del
<head>inyectadas por el cliente y luego sobrescritas por otra librería, con lo que conviven doscanonicalo dostitle. - Rutas que responden 200 con una pantalla de «no encontrado» pintada por el cliente, en vez de devolver un 404 real desde el servidor.
- Depender de
localStorageo de cookies para decidir qué contenido mostrar: el robot llega siempre como visitante nuevo.
Core Web Vitals: lo que depende del código
Las tres métricas que los buscadores usan como señal de experiencia de página miden cosas distintas y se arreglan con técnicas distintas. Se evalúan con datos de campo —usuarios reales— y tomando el percentil 75 de las visitas, no la media: optimizar para el caso bueno no sirve, hay que arreglar la cola lenta.
| Métrica | Qué mide | Umbral «bueno» | Palancas del desarrollador |
|---|---|---|---|
| LCP | Cuándo se pinta el elemento visible más grande | 2,5 s o menos | Respuesta rápida del servidor, preload del recurso LCP, fetchpriority="high", no diferir la imagen principal, CSS crítico en línea |
| INP | Latencia de respuesta a las interacciones del usuario | 200 ms o menos | Trocear tareas largas del hilo principal, quitar escuchadores pesados, aplazar scripts de terceros, no hacer trabajo síncrono en el click |
| CLS | Desplazamientos inesperados del contenido | 0,1 o menos | width y height en imágenes y vídeos, reservar el hueco de anuncios y banners, font-display: optional o fuentes precargadas, no insertar elementos por encima del contenido ya pintado |
El orden en que conviene atacarlo
Empieza siempre por medir con datos reales antes de tocar nada. Una herramienta de laboratorio te da un diagnóstico reproducible pero con un dispositivo y una red simulados; los datos de campo te dicen qué sufren de verdad tus usuarios, que quizá entran con un móvil de gama media y cobertura irregular.
Después, el reparto de esfuerzo suele ser este: la mayor parte del LCP se gana en el servidor y en cómo se prioriza el primer recurso, no comprimiendo imágenes una segunda vez. El INP casi siempre mejora quitando o aplazando JavaScript de terceros, empezando por lo que carga en el primer segundo. Y el CLS se arregla de una vez con dimensiones explícitas y huecos reservados; es la métrica más fácil de las tres y la que más se abandona sin arreglar.
Cuidado con una trampa recurrente: marcar como loading="lazy" la imagen principal de la cabecera. Es la peor cosa que puedes hacerle al LCP, porque retrasa justo el recurso que define la métrica. El lazy loading es para lo que está por debajo del pliegue.
URLs, arquitectura y contenido duplicado
La estructura de URLs es una de las pocas decisiones técnicas caras de revertir. Cambiarla obliga a redirigir, a perder algo de señal por el camino y a repasar todos los enlaces internos. Merece la pena pensarla una vez.
Qué hace buena a una URL
Corta, legible sin contexto, en minúsculas, con guiones, sin parámetros de seguimiento en la versión canónica y sin niveles de carpeta que no aporten información. /seo-dev/meta-tags.html se entiende. /index.php?cat=17&id=8842&sess=x no. Un usuario debería poder borrar el último segmento de la ruta y llegar a una página que existe y tiene sentido.
Evita meter la fecha en la ruta de contenido que vas a actualizar: te obliga a elegir entre una URL que miente o una migración. Y evita reflejar en la URL la estructura interna de tu base de datos, porque esa estructura cambiará antes que el contenido.
Los cuatro focos de duplicados
Variantes de host y protocolo. Con y sin www, HTTP y HTTPS. Elige una combinación, redirige el resto en un solo salto y que el canonical use esa forma.
Parámetros. Ordenaciones, filtros, identificadores de sesión y etiquetas de campaña multiplican las URLs de la misma página. La versión canónica debe ser siempre la limpia. Los filtros que generan combinaciones casi infinitas conviene dejarlos fuera del rastreo.
Paginación. Cada página del listado es una URL válida y distinta, con su propio canonical apuntando a sí misma. Apuntar todas las páginas de un listado al primer resultado es un error clásico: hace desaparecer del índice el contenido que solo está en la página siete.
Plantillas casi idénticas. Páginas generadas por combinación —ciudad, color, talla— cuyo texto solo cambia en una palabra. Si no puedes justificar por qué esa variante merece una página propia, probablemente deba ser un filtro y no una URL indexable.
Sitios multilingües: hreflang sin romperlo
El atributo hreflang indica qué versión de una página corresponde a qué idioma o región. No es una señal de posicionamiento: sirve para que, entre varias versiones equivalentes, se muestre la adecuada a cada usuario.
Las condiciones para que funcione son estrictas y poco perdonadas. Las referencias tienen que ser recíprocas: si la versión española apunta a la mexicana, la mexicana debe apuntar de vuelta a la española, y ambas deben incluirse a sí mismas en el conjunto. Los códigos son de idioma según ISO 639-1 y, opcionalmente, de región según ISO 3166-1 alpha-2, siempre en ese orden. Y el valor x-default marca la versión para quien no encaje en ninguna.
El fallo más caro es el que mezcla hreflang con canonical. Si la versión mexicana declara como canónica la española, le estás diciendo al buscador que la mexicana no debe existir por separado, y entonces todo el trabajo de hreflang se cae. Cada versión de idioma es canónica de sí misma; el emparejamiento lo hace hreflang y solo hreflang.
Si el conjunto de idiomas es grande, declararlo en el <head> de cada página multiplica el peso del HTML. En ese caso conviene declararlo en el sitemap XML, que admite las mismas anotaciones y se mantiene desde un único sitio.
Con hreflang no hay medias tintas: o el grafo de referencias está completo y es recíproco, o el buscador lo descarta entero. Media configuración vale lo mismo que ninguna.
Errores que se repiten en cada despliegue
Esta es la lista de comprobaciones que compensa automatizar en el proceso de publicación, porque son fallos que nadie ve al revisar visualmente la página y que cuestan semanas de tráfico.
- El
noindexdel entorno de pruebas que llega a producción. Ocurre cuando la directiva se controla por una variable de entorno que no se define en el despliegue. Es el fallo técnico más caro que existe, y el más fácil de detectar con una comprobación automática después de publicar. - El
robots.txtde staging conDisallow: /. Misma historia, distinto archivo. Comprueba su contenido en producción tras cada despliegue. - Etiquetas de plantilla sin sustituir. Un
{{title}}literal en el<title>o un marcador de posición en un enlace de afiliación. Pasa el HTML servido por el HTML Beautifier y búscalos. - Canonical duplicado o cruzado. Dos etiquetas en el mismo
<head>, o una que apunta a una página sin relación porque la plantilla la heredó de otra sección. - Redirecciones encadenadas tras una migración. Se acumulan reglas sin revisar las anteriores. Aplánalas.
- Enlaces internos rotos. Secciones que se retiraron y menús que siguen apuntando a ellas. Un rastreo interno periódico los saca en minutos.
- Imágenes sin dimensiones. Degrada el CLS en cuanto la conexión es lenta, y no se ve en local.
- Scripts de terceros añadidos «solo para probar». Se quedan, y cada uno paga su peaje en INP.
- Sitemap generado con URLs no canónicas. Suele pasar cuando el generador lee de la base de datos y la normalización de barra final se hace en el servidor.
- Contenido que solo existe tras renderizar. Revisa el HTML sin JavaScript activado y comprueba que el texto principal está.
Un flujo de trabajo que se sostiene
Las herramientas sueltas ayudan poco si no hay un orden detrás. El que funciona para la mayoría de proyectos tiene cuatro momentos.
Antes de escribir código. Decide el esquema de URLs, la política de barra final, el host canónico y qué se va a indexar y qué no. Esas cuatro decisiones tomadas al principio ahorran la migración que nadie quiere hacer.
Mientras desarrollas. Genera el bloque de etiquetas con el Generador de Meta Tags SEO y las rutas con el Generador de Slugs, para que todas salgan con el mismo criterio y no dependan de quién las escriba ese día. Valida el JSON-LD antes de pegarlo.
Al desplegar. Comprueba automáticamente cuatro cosas en producción: que la portada devuelve 200, que no hay noindex donde no debe, que robots.txt es el bueno y que el sitemap se genera y responde. Con eso se atrapa casi todo lo grave.
Después. Revisa los informes de cobertura y los datos de campo de rendimiento con cadencia fija, no cuando alguien se alarma. Los problemas técnicos aparecen ahí antes que en la gráfica de visitas.
Preguntas frecuentes sobre seo dev
¿Hay que registrarse para usar estas herramientas?
No. Las cuatro utilidades de /seo-dev/ se ejecutan en tu navegador, sin cuenta ni suscripción. El texto o el código que pegas no se envía a ningún servidor de GlobalTool, así que puedes usarlas con material de proyectos privados.
¿Cuál es la longitud correcta de un title?
No existe un número exacto de caracteres, porque el resultado se recorta por ancho en píxeles y ese ancho depende del dispositivo y de las letras que uses. La regla práctica es poner delante lo que identifica la página y no repetir el nombre del sitio en medio del texto. El Generador de Meta Tags te muestra el título mientras lo escribes para que valores si aguanta.
¿Cuánta densidad de palabra clave debo tener?
Ninguna en concreto: la densidad de palabras clave no es una métrica que los buscadores usen, y perseguir un porcentaje produce textos peores. Escribe para que se entienda y usa el término principal donde toca de forma natural, que suele ser el título, el primer párrafo y algún encabezado.
¿Bloquear una URL en robots.txt la saca de Google?
No. robots.txt impide descargar la URL, no indexarla. Una página bloqueada puede seguir apareciendo en resultados si hay enlaces hacia ella, normalmente sin descripción. Para retirarla del índice hay que permitir el rastreo y añadir noindex, o devolver un 410 si ya no existe.
¿Uso 301 o 302 para una URL que he cambiado?
Si el cambio es definitivo, 301. El 302 es para situaciones temporales de verdad, como una promoción con fecha de fin o un mantenimiento. Dejar un 302 durante meses acaba tratándose como permanente igualmente, así que no ganas nada.
¿Google indexa el contenido generado con JavaScript?
Sí, pero en una segunda pasada posterior al rastreo inicial, que puede retrasarse y que no está garantizada para todas las URLs de un sitio grande. Todo lo que necesites indexado con seguridad debe estar en el HTML que devuelve el servidor: renderizado en servidor o generación estática.
¿Los datos estructurados mejoran el posicionamiento?
No directamente. Lo que hacen es habilitar formatos enriquecidos en los resultados y ayudar al buscador a entender la página. Ese efecto en el porcentaje de clics suele ser el beneficio real. El marcado tiene que describir lo que hay visible en la página; si no, incumple las directrices.
¿Por qué mi JSON-LD no se detecta?
Lo más habitual es un error de sintaxis —una coma sobrante, comillas tipográficas copiadas de un documento— que invalida el bloque entero. Pásalo por el JSON Formatter primero y después por el validador de schema.org. También pasa cuando el bloque se inyecta por JavaScript y se sobrescribe, o cuando está dentro de una zona bloqueada al rastreo.
¿Guiones o guiones bajos en las URLs?
Guiones. La recomendación estándar desde hace años es separar palabras con guiones medios, porque el guion bajo puede tratarse como parte de la palabra. El Generador de Slugs ya lo hace, además de quitar tildes y caracteres que obligarían a codificar la URL.
¿Con barra final o sin ella?
Da igual cuál elijas; lo que importa es que sea siempre la misma. Técnicamente son dos URLs distintas, así que fija una, redirige la otra con 301 y comprueba que los enlaces internos, el canonical y el sitemap coinciden con esa decisión.
¿Qué métrica de Core Web Vitals arreglo primero?
La que esté fuera de umbral en tus datos de campo, no la que peor pinte en una prueba de laboratorio. Si están las tres mal, el CLS suele ser el arreglo más rápido —dimensiones en imágenes y huecos reservados—, y el INP el más lento, porque casi siempre implica quitar JavaScript de terceros.
¿Necesito un sitemap si mi sitio es pequeño?
No es obligatorio. Con pocas páginas bien enlazadas entre sí, el rastreo llega igual. Aporta valor en sitios grandes, en dominios nuevos sin enlaces externos y cuando publicas con frecuencia. Si lo pones, que solo contenga URLs canónicas que devuelvan 200.
Sigue explorando GlobalTool
- Generador de Meta Tags SEO — etiquetas del
<head>, Open Graph y Twitter Card. - Generador de Slugs URL-Friendly — rutas limpias a partir de titulares.
- JSON Formatter — indenta y valida JSON y JSON-LD.
- HTML Beautifier — HTML minificado, legible otra vez.
- Herramientas SEO — el resto de utilidades de posicionamiento del sitio.
- Herramientas de código — formateadores, conversores y validadores para desarrollo.
- Generadores — contraseñas, códigos QR, texto de relleno y números aleatorios.
- Convertidores — unidades, colores, bases numéricas y divisas.
- Calculadoras — porcentajes, descuentos, préstamos, fechas y regla de tres.
- Blog — guías largas y explicaciones paso a paso.