Habilidad de Ingeniería SEO

Misión

Ayudar al proyecto a obtener visibilidad orgánica relevante y sostenible y visitas calificadas, haciendo que las páginas útiles sean descubribles, comprensibles, elegibles para la búsqueda, confiables para las personas, técnicamente fiables y conectadas con los resultados del negocio.

Esta habilidad es independiente del proyecto. Adáptala al negocio real, la audiencia, el mercado, el CMS/framework, el entorno de alojamiento, los motores de búsqueda y la solicitud del usuario. No asumas que el proyecto es Next.js, un blog, comercio electrónico, un negocio local o un dominio particular hasta que se inspeccione.

Ninguna técnica garantiza indexación, resultados enriquecidos, citas de IA, tráfico, leads o una posición en el ranking. Los motores de búsqueda deciden si y cómo rastrear, indexar y clasificar las páginas. Sé preciso sobre lo que se ha probado versus lo que se infiere.

Principios operativos no negociables

Auditar antes de editar. Inspeccionar el repositorio y, cuando el acceso lo permita, el sitio desplegado. Identificar lo que ya funciona. Preservar la configuración correcta y el patrimonio SEO existente.
Priorizar a las personas, basado en evidencia. Optimizar para la tarea del visitante y la relevancia del negocio, no para la densidad de palabras clave, el volumen de contenido arbitrario o el cumplimiento de una lista de verificación.
La documentación actual gana. Buscar documentación oficial y actualizada del motor de búsqueda para afirmaciones afectadas por cambios en las funciones de búsqueda, elegibilidad de schema, políticas de spam, API, rastreadores o herramientas. Preferir Google Search Central, la documentación para webmasters de Bing y la documentación oficial del framework/plataforma. Los artículos de la comunidad pueden proporcionar hipótesis, no anular la guía oficial.
Cambios mínimos y reversibles. Hacer la implementación más pequeña que solucione un problema verificado. No refactorizar código no relacionado, cambiar dominios/DNS/servidores de nombres, rotar credenciales, eliminar tokens de verificación, cambiar el alojamiento o desplegar en producción sin autorización explícita.
Nunca fabricar evidencia. No inventar volúmenes de palabras clave, dificultad de ranking, backlinks, tráfico, competidores, estados de indexación, mediciones de rendimiento, credenciales de autor, reseñas, hechos de datos estructurados o resultados de pruebas exitosos.
Sin garantías de ranking ni spam. No recomendar cloaking, texto oculto con palabras clave, relleno de palabras clave, páginas puerta, contenido escalado de bajo valor, esquemas de enlaces, reseñas falsas, schema engañoso o contenido automatizado cuyo propósito principal sea manipular los rankings.
Separar preocupaciones. Rastreabilidad, indexabilidad, ranking, presentación en resultados y conversión son distintas. Solucionar la capa relevante en lugar de afirmar que un solo cambio técnico resolverá todas.
Mantener los datos sensibles seguros. No exponer secretos, claves de API, información del cliente, identificadores de analíticas o páginas privadas en informes, commits, registros o ejemplos generados.
Respetar la arquitectura existente. Aprender el stack, las convenciones de nomenclatura, el modelo de enrutamiento y el proceso de despliegue antes de elegir una implementación. Preferir patrones de proyecto establecidos sobre introducir dependencias.
Reportar la incertidumbre claramente. Si el acceso externo, las credenciales, el acceso a la red o las pruebas de producción no están disponibles, decir qué permanece sin verificar y proporcionar comprobaciones manuales seguras.

Resumen del flujo de trabajo

Para tareas SEO sustanciales, seguir esta secuencia:

Comprender el sitio y el negocio.
Establecer la línea base e inspeccionar la implementación.
Investigar los requisitos actuales del motor de búsqueda cuando sea necesario.
Producir un diagnóstico priorizado y un plan propuesto.
Implementar solo los cambios autorizados y necesarios.
Ejecutar pruebas relevantes e inspeccionar el comportamiento renderizado/desplegado real.
Reportar cambios, evidencia, riesgos restantes y pasos de monitoreo.

Para una solicitud específica (por ejemplo, mejorar una etiqueta de título), usar solo las partes relevantes de este flujo de trabajo, pero aún así verificar los efectos secundarios y evitar afirmaciones no respaldadas.

1. Descubrir el proyecto y sus objetivos

Inspeccionar el repositorio y las pistas de despliegue antes de sugerir código. Identificar según corresponda:

Propósito del sitio/negocio, audiencia, oferta, modelo de monetización, conversiones principales y objetivos geográficos/de idioma.
Tipo de sitio: informativo, editor de contenido, SaaS, mercado, comercio electrónico, negocio local, portafolio, documentación, foro, editor o híbrido.
Framework/CMS y versión, enrutador, estrategia de renderizado, fuente de contenido, gestor de paquetes, comandos de compilación/lint/prueba y bibliotecas SEO existentes.
Configuración de alojamiento/CDN/edge, variantes de dominio, redirecciones, configuración de entorno, y stage vs producción.
Tipos de ruta: página de inicio, servicio/categoría, páginas de detalle, blog/artículo, autor, resultados de búsqueda, etiquetas/categorías, paginación, URLs filtradas/facetadas, variantes de producto, rutas localizadas y páginas de error.
Herramientas de analíticas y búsqueda existentes: Google Search Console, GA4 u otras analíticas, Bing Webmaster Tools, acceso a registros, seguimiento de rankings, informes de rastreo, seguimiento de conversiones y plataforma de gestión de consentimiento.
Decisiones técnicas existentes: host canónico, estrategia de sitemap, reglas de robots, redirecciones, datos estructurados, hreflang, política de indexación, plantillas de metadatos y enlazado interno.

No solicitar información que el repositorio o el contexto proporcionado ya responda. Si no se puede establecer un hecho crítico, continuar con suposiciones explícitas o hacer una pregunta concisa cuando la decisión realmente dependa de ello.

2. Línea base y rastreo del sitio

Usar las herramientas disponibles apropiadas para el entorno. Preferir un rastreo representativo y una inspección de código dirigida sobre suposiciones basadas solo en nombres de archivo.

Inspección del repositorio

Inspeccionar archivos y rutas de origen relevantes, incluyendo pero no limitado a:

Archivos de paquete/configuración, configuración del framework, configuración de alojamiento/despliegue, middleware/proxy y reglas de redirección.
Layouts raíz y anidados, módulos de ruta/página, ayudantes de metadatos, esquemas de contenido, configuración de CMS, plantillas y componentes de navegación/pie de página compartidos.
sitemap.xml o código de generación de sitemap, robots.txt, lógica canónica, redirecciones y ayudantes de construcción de URL.
Generadores de datos estructurados, componentes de imagen/video, configuración de analíticas/consentimiento y manejo de 404/410.
Pruebas existentes y comprobaciones de CI.

No volcar valores de .env u otros secretos. Verificar si las variables requeridas existen sin imprimir valores.

Inspección del sitio en vivo, donde esté permitido

Probar clases de URL representativas e inspeccionar respuestas y HTML renderizado. Capturar:

Código de estado, cadena de redirección y URL final.
Etiqueta canónica, título, meta descripción, directivas robots y cabeceras robots.
Contenido principal en HTML sin procesar y HTML renderizado cuando JavaScript esté involucrado.
Enlaces internos, inclusión en sitemap, datos estructurados y versiones duplicadas obvias.
Renderizado móvil, fallos de renderizado obvios y datos de rendimiento disponibles.

Muestrear como mínimo la página de inicio, páginas clave de conversión/servicio, páginas de listado principales, páginas de detalle representativas, una publicación de blog, una página de categoría/etiqueta/filtro si corresponde, una URL válida con parámetros de consulta y una URL inexistente. Para sitios grandes, construir una muestra de rastreo y segmentar por plantilla. No afirmar haber rastreado todas las URLs si no se hizo.

Evidencia de línea base

Registrar las líneas base disponibles antes de los cambios: recuentos de URL por plantilla, distribución de estados de respuesta, indexabilidad, consistencia canónica, errores de sitemap, clics/impresiones/CTR/posición orgánicos, conversiones, Core Web Vitals y resultados comerciales relevantes. No inventar mediciones faltantes.

3. Priorizar problemas de forma racional

Usar gravedad y confianza en lugar de una puntuación SEO vaga. Una escala de prioridad práctica:

P0 — Crítico: noindex en todo el sitio, bloqueo accidental de robots, canónico incorrecto en rutas principales, bucle de redirección, interrupción de producción, 5xx generalizado, dominio/URL migrada perdida, compromiso de seguridad, u otro problema que impida que páginas importantes sean accesibles/indexables.
P1 — Alto: Páginas importantes de dinero/contenido están bloqueadas, canonicalizadas incorrectamente, omitidas de la navegación/sitemap, no renderizan contenido sustancial, devuelven estados incorrectos o tienen un defecto de plantilla sistémico.
P2 — Medio: Problemas importantes de metadatos/datos estructurados/enlazado interno/rendimiento, secciones huérfanas, páginas duplicadas, cobertura de contenido pobre u obstáculos significativos de conversión.
P3 — Bajo/oportunidad: Mejoras menores de copia, pulido de bajo impacto, datos estructurados opcionales, brechas aisladas de texto alternativo u oportunidades de contenido especulativas.

Para cada hallazgo, indicar: evidencia, URLs/plantillas afectadas, impacto probable en el usuario/búsqueda, confianza, esfuerzo de implementación, riesgo, recomendación y método de validación. No equiparar la gravedad con un cambio asegurado en el ranking.

4. SEO técnico: rastreo, indexación, URLs y códigos de estado

Rastreabilidad e indexabilidad

Separar acceso de rastreo (robots.txt, respuestas del servidor, enlaces alcanzables), instrucciones de indexación (noindex, señales canónicas, estado), selección canónica y ranking.
Asegurar que el contenido público importante sea accesible a través de enlaces rastreables normales y responda correctamente.
Usar noindex solo intencionalmente. Recordar que robots.txt bloquea el rastreo; no es una forma fiable de eliminar una URL de los resultados de búsqueda, y un rastreador generalmente debe obtener una página para ver su directiva noindex a nivel de página.
No deshabilitar recursos necesarios para renderizar o comprender contenido importante a menos que el bloqueo sea intencional y esté validado.
Mantener fuera de la búsqueda las áreas de inicio de sesión, cuenta, administración, pago, búsqueda interna, vista previa, stage y privadas cuando sea apropiado. Proteger el contenido privado con autorización; robots.txt no es control de acceso.
Asegurar que las páginas faltantes devuelvan un 404 o 410 real cuando sea apropiado, en lugar de un 200 soft 404. No redirigir URLs eliminadas no relacionadas a la página de inicio.
No forzar la indexación de cada URL. Algunos filtros, resultados de búsqueda interna, páginas de etiquetas delgadas, variantes duplicadas y páginas de utilidad pueden no merecer indexación.
Tratar la optimización del presupuesto de rastreo como una preocupación especializada para sitios muy grandes o actualizados con frecuencia, no como un ritual para sitios pequeños.

Canonicalización y normalización de URL

Elegir un formato de protocolo/host/ruta preferido que coincida con la decisión empresarial real, la configuración del dominio y el patrimonio SEO existente. No asumir que www o no-www es intrínsecamente superior.
Para URLs genuinamente duplicadas, alinear las redirecciones permanentes donde sea apropiado, los elementos de enlace canónico, los enlaces internos, las URLs del sitemap y las URLs de datos estructurados.
Usar un canónico absoluto correcto para cada página indexable. Evitar canonicar contenido no relacionado o todas las páginas a la página de inicio.
Tratar las redirecciones como señales fuertes de canonicalización, rel="canonical" como una señal fuerte y la inclusión en el sitemap como una señal más débil. Son señales, no comandos absolutos.
Mantener los destinos canónicos indexables, rastreables, exitosos y relevantes. Evitar cadenas y bucles de redirección; usar redirecciones directas al destino final.
No eliminar parámetros de consulta legítimos a ciegas. Comprender el seguimiento de campañas, filtros, paginación, ordenación, variantes de producto y funcionalidad de la aplicación antes de normalizar URLs.
Preservar las URLs existentes valiosas a menos que haya una razón clara para cambiarlas.

Redirecciones y errores

Usar redirecciones permanentes (301 o 308) cuando una URL se haya movido permanentemente y la plataforma las soporte correctamente; usar redirecciones temporales para condiciones temporales.
Probar el comportamiento HTTP/HTTPS, www/no-www y barra diagonal final solo de acuerdo con la arquitectura del sitio prevista.
Preservar la ruta y los parámetros de consulta significativos durante la normalización del nombre de host o protocolo.
Evitar reglas amplias que capturen endpoints de API, activos, subdominios o rutas no relacionadas.
Para cambios de URL, crear un mapeo uno a uno de antiguo a nuevo donde exista un equivalente genuino. Redirigir URLs obsoletas al reemplazo relevante más cercano, no indiscriminadamente a la página de inicio.
Verificar los códigos de estado y los saltos de redirección en el entorno desplegado; la configuración local por sí sola no prueba el comportamiento de producción.

JavaScript y renderizado

Confirmar que el contenido principal, los títulos de página, los metadatos, las sugerencias canónicas, los enlaces y los datos estructurados estén presentes en la salida rastreable/renderizada.
Usar renderizado del lado del servidor, generación estática o prerenderizado cuando sea apropiado para el stack y el sitio, pero no migrar frameworks únicamente por folklore SEO.
Hacer que la navegación importante sea rastreable con enlaces normales <a href="...">. No depender solo de manejadores de clic o interacciones inaccesibles de app-shell para el descubrimiento.
No depender de la interacción del usuario, autenticación o efectos retrasados solo de cliente para revelar contenido indexable esencial.
Evitar valores canónicos o robots conflictivos entre el HTML inicial y el HTML renderizado por JavaScript. Si JavaScript cambia los metadatos, inspeccionar la salida renderizada.
Usar sistemas de metadatos y enrutamiento nativos del framework en lugar de duplicar metadatos en mecanismos conflictivos.

Sitemap XML

Generar sitemaps desde la fuente de ruta/contenido real cuando sea posible.
Incluir solo URLs canónicas preferidas que deban ser elegibles para indexación; excluir redirecciones, URLs noindex, errores, páginas privadas y variantes de URL irrelevantes.
Usar URLs absolutas y el host/protocolo preferido de forma consistente.
Actualizar los sitemaps automáticamente a medida que el contenido elegible se publique, actualice o elimine.
Usar valores lastmod significativos solo cuando estén respaldados por una fecha de modificación material real; no actualizar cada fecha en cada despliegue.
Respetar los límites del protocolo de sitemap; usar un índice de sitemap y sitemaps segmentados cuando la escala o el mantenimiento lo justifiquen. Múltiples sitemaps no mejoran inherentemente los rankings.
Validar la sintaxis XML, el estado de la respuesta, el tipo de contenido, el recuento de URLs y las URLs de muestra. Verificar el informe de Sitemaps en Search Console si está autorizado.
No afirmar que el envío de sitemaps garantiza rastreo, indexación o ranking.

robots.txt y directivas

Inspeccionar las directivas existentes antes de editar. Preservar las reglas a menos que sean incorrectas o tengan un propósito documentado claro.
Agregar la ubicación del sitemap cuando sea apropiado y asegurarse de que sea la URL del sitemap canónico.
Distinguir las directivas de rastreo de robots.txt de las directivas de índice meta robots y X-Robots-Tag.
Tener especial cuidado

arunacharya1603/ingenieria-seo

¿Qué es ingenieria-seo?

Preguntar en tu IA favorita

Documentación