Lista de Verificación SEO Pre-publicación

El aseguramiento de calidad (QA) pre-publicación es la puerta de lanzamiento final en el proceso SEO . Es donde convergen tres contratos: la conformidad con el tipo de publicación, el uso correcto de elementos y la finalización del trabajo previo de investigación, evidencia, implementación y revisión. Una página que no cumpla con algún elemento aplicable regresa para corrección.

Puerta: QA pre-publicación final. Tiempo asignado: 60–90 minutos para una página estándar; agregue tiempo de especialistas para afirmaciones reguladas, de seguridad, financieras, médicas o técnicamente relevantes. Responsable: un editor, líder de contenido o líder de SEO que no haya realizado la implementación final y tenga autoridad para bloquear el lanzamiento.

Una lista de verificación flexible no es una lista de verificación porque “casi terminado” no tiene un significado estable. Bajo presión de plazos, el lenguaje opcional se convierte en una ayuda de memoria y las comprobaciones difíciles desaparecen. Nombre la autoridad de lanzamiento antes de que comience la QA. El responsable de QA puede aprobar o reprobar; solo el jefe de contenido designado, el líder de SEO o equivalente puede aprobar una excepción por escrito o declarar un elemento como no aplicable. No pueden renunciar a una afirmación falsa, un elemento obligatorio faltante, un activo placeholder, una canónica rota o una indexabilidad bloqueada para cumplir con una fecha.

Por qué existe esta puerta y por qué opera aquí

Esta puerta consume la especificación de tipo de publicación aprobada, los contratos de elementos, el registro de fuentes, el texto final, el candidato implementado y las aprobaciones de especialistas. Opera después de que estas entradas están congeladas porque la QA no puede verificar un objetivo en movimiento, y antes de la publicación porque un defecto puede copiarse tan pronto como la URL esté activa.

La QA anterior certifica un borrador que puede cambiar. Omitirla deja a los auditores posteriores sin poder distinguir entre desviación de página, una especificación cambiada y una página nunca revisada. La QA posterior a la publicación convierte correcciones económicas en defectos públicos.

Entradas y salidas

La salida es un contrato, no un mensaje de chat. El publicador debe poder actuar sobre él sin reconstruir la revisión.

La lista de verificación

Cada elemento a continuación incluye la acción, razón, método, herramienta y condición observable de “listo”. “SEO revisado” o “se ve bien” nunca es evidencia aceptable.

1. Conformidad con el tipo de publicación

Confirmar el tipo de publicación y alcance seleccionados. Qué: emparejar el candidato con una entrada de la biblioteca de tipos de publicación y eliminar material perteneciente a un tipo hermano. Por qué: el tipo de página determina la intención, estructura, evidencia y comportamiento de conversión. Cómo: etiquete cada sección con la decisión del lector que respalda y compárela con el propósito y las exclusiones del tipo. Herramienta: brief aprobado, mapa temático y páginas de tipos de publicación. Listo cuando: exactamente un tipo principal está registrado, la apertura, el cuerpo y la CTA lo sirven, y cero secciones existen únicamente para el trabajo de otro tipo.

Rastrear estructura requerida y rangos de palabras. Qué: mapear cada sección requerida al candidato renderizado y contar sus palabras contra el rango especificado. Por qué: las secciones faltantes crean preguntas sin respuesta, mientras que la longitud sin control oculta lagunas detrás del volumen. Cómo: use una matriz de requisito a encabezado y conteos automatizados, luego inspeccione los casos límite manualmente. Herramienta: especificación de tipo de publicación, fuente y página renderizada. Listo cuando: cero secciones requeridas faltan y cada sección está dentro de su mínimo y máximo establecidos.

2. Conformidad de elementos

Verificar elementos, posiciones y parámetros. Qué: comparar el mapa de elementos con la fuente y el renderizado. Por qué: la posición y los campos son parte de la función; una respuesta directa enterrada ya no responde primero, y los parámetros mal formados pueden romper la salida. Cómo: inspeccione de arriba a abajo y valide campos permitidos, valores, anidamiento y sintaxis. Herramienta: especificaciones de elementos, validador y navegador. Listo cuando: cada elemento obligatorio está en su posición requerida, cada parámetro es válido y no queda ningún duplicado sin explicación.

Aplicar precedencia de elementos tipificados. Qué: aplicar las reglas de redacción de elementos dondequiera que un pasaje tenga un propósito registrado. Por qué: el texto libre puede parecer similar pero no puede transmitir la identidad del componente, los campos, el comportamiento de accesibilidad ni la salida estructurada. Cómo: exprese la función de cada bloque como un verbo — definir, advertir, comparar, instruir, resumir — y verifique si hay un elemento coincidente. Herramienta: biblioteca de elementos e inspector de fuente. Listo cuando: cero pasajes usan texto libre donde un elemento tipificado es obligatorio.

3. Calidad del contenido

Probar la respuesta de forma aislada. Qué: leer el bloque de respuesta directa sin su encabezado ni párrafos circundantes. Por qué: los sistemas de búsqueda y recuperación con IA pueden extraer solo ese pasaje. Cómo: verifique que nombre el tema, responda la pregunta, incluya la calificación necesaria y no dependa de “esto”, “ello” o “como se indicó anteriormente”. Herramienta: vista de texto aislado y revisor humano. Listo cuando: la respuesta es autónoma, precisa y está dentro de su rango especificado de 40 a 60 palabras cuando ese elemento es requerido.

Verificar afirmaciones, lenguaje y singularidad. Qué: rastrear afirmaciones materiales hasta la evidencia, explicar la jerga en el primer uso y comparar el candidato con páginas que sirven la misma intención. Por qué: las afirmaciones no respaldadas dañan la confianza, mientras que los casi duplicados compiten y divergen. Cómo: marque nombres, fechas, números, afirmaciones causales, comportamiento de productos y candidatos de similitud; respalde, califique, consolide o elimine. Herramienta: registro de evidencia, fuentes primarias, búsqueda en el sitio e informe de similitud. Listo cuando: cero afirmaciones materiales carecen de respaldo, cero términos especializados permanecen sin explicación y ninguna página existente responde a la misma intención y alcance sin un plan de consolidación.

4. Frontmatter

Validar campos de identidad y vista previa. Qué: aplicar la especificación de frontmatter al título, descripción, palabras clave, entity y uniones de tipo de publicación. Por qué: estos campos impulsan el enrutamiento, las vistas previas, los esquemas y las relaciones sin leer el cuerpo. Cómo: ejecute validación de campos y longitud, luego compare el significado con la página visible. Herramienta: linter de frontmatter y vista previa humana. Listo cuando: el título es único y preciso, la descripción tiene entre 150 y 160 caracteres, las palabras clave contienen de 6 a 8 entradas relevantes y entity coincide con el contrato del tipo de publicación.

Verificar campos de gobernanza y preguntas frecuentes. Qué: verificar fechas, autor, revisor, propiedad y estructura de preguntas frecuentes visible contra el frontmatter. Por qué: los registros anónimos impiden la rendición de cuentas, mientras que la desviación en las preguntas frecuentes hace que las respuestas visibles y estructuradas discrepen. Cómo: compare los campos con el rastro de lanzamiento y el texto visible normalizado. Herramienta: analizador de fuente, rastreador y página renderizada. Listo cuando: las fechas y propietarios requeridos son válidos, el revisor humano está nombrado donde se requiere, la cantidad de preguntas frecuentes cumple con el mínimo del tipo, cada par coincide y no quedan entradas ocultas o vacías.

5. Datos estructurados

Exigir el esquema correcto. Qué: confirmar que existe el marcado de esquema aplicable para la página y sus elementos visibles. Por qué: la falta de marcado o un marcado genérico descarta el significado legible por máquina que el modelo de contenido ya proporciona. Cómo: compare los tipos y propiedades emitidos con los contratos de tipo de publicación y elementos. Herramienta: HTML renderizado y validador de esquema. Listo cuando: cada tipo de esquema requerido está presente una vez, las propiedades requeridas están pobladas y no se emite ningún tipo no aplicable.

Validar paridad, no solo sintaxis. Qué: comparar nombres, fechas, autor, entidad, preguntas frecuentes, pasos y afirmaciones del esquema con el contenido visible. Por qué: la sintaxis válida aún puede describir información invisible o contradictoria. Cómo: valide JSON-LD, luego compare los valores con la página. Herramienta: prueba de datos estructurados y revisión humana. Listo cuando: hay cero errores y cero hechos en el esquema que contradigan o excedan el contenido visible.

6. Enlazado interno

Enlazar hacia arriba y hacia afuera. Qué: proporcionar una ruta al pilar relevante y rutas contextuales a nodos relacionados. Por qué: la jerarquía ayuda a los lectores y rastreadores a entender dónde pertenece la página, mientras que los enlaces laterales continúan la tarea del lector. Cómo: mapee cada enlace interno a una pregunta genuina siguiente en lugar de llenar una cuota. Herramienta: grafo de enlaces y página renderizada. Listo cuando: la página tiene al menos un enlace a su pilar, al menos un enlace lateral relevante donde existe un nodo relacionado, y al menos una página existente enlaza hacia ella antes o durante la publicación para que no quede huérfana.

Inspeccionar destinos y anclajes. Qué: abrir cada destino y revisar su texto de anclaje . Por qué: una URL plausible puede estar faltante, redirigida o no relacionada, y las etiquetas genéricas ocultan el propósito del destino. Cómo: ejecute un verificador de enlaces internos, luego inspeccione manualmente los anclajes en contexto de oración. Herramienta: rastreador y navegador. Listo cuando: cero enlaces internos devuelven un error, cada destino respalda la afirmación circundante y no queda ningún “haga clic aquí” aislado, URL sin formato o anclaje de coincidencia exacta engañoso.

7. Medios

Verificar activos, alternativas y actualidad. Qué: confirmar que cada imagen existe, tiene texto alternativo significativo o una alternativa vacía justificada, y refleja la interfaz actual. Por qué: los medios rotos, vagos, placeholder o desactualizados eliminan información y pueden hacer que las instrucciones sean inutilizables. Cómo: deshabilite imágenes, inspeccione rutas, reproduzca pasos del producto y compare etiquetas, valores, recortes y redacción. Herramienta: verificador de activos, auditoría de accesibilidad, producto en vivo y navegador. Listo cuando: cero activos faltan o son placeholders, las alternativas son precisas y cada captura de pantalla representa el paso actual.

8. Lanzamiento técnico

Verificar enrutamiento, indexabilidad y reemplazo. Qué: verificar slug, una URL canónica auto-referenciada, estado, comportamiento de robots, indexabilidad y redirecciones. Por qué: el contenido no puede rendir en la ruta incorrecta, detrás de noindex o después de que URLs antiguas queden abandonadas. Cómo: inspeccione el head renderizado y la respuesta, compare el registro y siga cada ruta reemplazada. Herramienta: verificador de encabezados, mapa de redirecciones, inspector de fuente e inspección de URL. Listo cuando: la URL aprobada devuelve 200 con una canónica prevista y sin bloqueo; cada URL reemplazada realiza un salto permanente a la sustitución válida más cercana.

Probar estabilidad móvil. Qué: inspeccionar lectura en ancho reducido, interacción, desbordamiento y desplazamiento acumulativo del diseño . Por qué: los componentes que funcionan en escritorio pueden ocultar controles, recortar tablas o mover contenido a medida que se cargan los medios. Cómo: pruebe anchos móviles representativos y cargue la página con limitación. Herramienta: modo de dispositivo del navegador e informe de rendimiento. Listo cuando: todo el contenido y los controles permanecen utilizables sin desbordamiento horizontal de página y el CLS medido es 0.1 o inferior.

9. Preparación para IA

Probar extracción y HTML inicial. Qué: inspeccionar respuestas, definiciones, hechos clave, comparaciones y conclusiones como pasajes independientes en el HTML servido. Por qué: los sistemas de recuperación pueden seleccionar un pasaje y pueden no ejecutar código del lado del cliente. Cómo: obtenga el HTML inicial, elimine el contexto circundante y verifique nombres de entidades, calificadores, unidades y pronombres. Herramienta: obtención de HTML, extractor de pasajes, navegador y auditoría de AmICited. Listo cuando: cada hecho prioritario está presente sin JavaScript y retiene su sujeto, significado y limitaciones por sí solo.

Exponer estructura procesal. Qué: verificar que los pares de preguntas frecuentes y los pasos ordenados estén codificados como campos reconocibles y permanezcan visibles. Por qué: los encabezados y las cajas estilizadas pueden verse correctos mientras que las máquinas reciben prosa no estructurada. Cómo: compare la salida de elementos, la estructura accesible y el esquema con la secuencia visible. Herramienta: árbol de accesibilidad y validador de datos estructurados. Listo cuando: cada pregunta frecuente requerida es legible por máquina como un par pregunta-respuesta y cada procedimiento requerido conserva pasos ordenados en la salida visible y estructurada.

Herramientas en AmICited

Utilice el producto para inspeccionar el candidato y establecer evidencia de transferencia; no reemplaza el juicio humano.

1. Abra la auditoría de preparación para agentes junto con Accesibilidad y preparación para IA para inspeccionar accesibilidad, alcance del rastreador, cobertura del sitemap y contenido legible por agentes.
2. Inspeccione la URL candidata con Inspección de URL para verificar el estado del índice, la usabilidad móvil y el veredicto de resultados enriquecidos. Asigne la inspección en vivo en la transferencia para una URL nueva.
3. Abra la auditoría de actualidad con Actualidad del contenido para dar a las páginas sensibles al tiempo una señal de mantenimiento y una fecha de próxima revisión. El historial comienza cuando comienza el seguimiento; la ausencia de historial no significa que no haya cambios.
4. Use SEO MCP a través de la conexión del espacio de trabajo para comprobaciones repetibles de solo lectura de URL, actualidad, Web Vitals y accesibilidad. Almacene la salida o el identificador de ejecución.

Automatización: programe las comprobaciones deterministas, preserve las decisiones humanas

Una comprobación que se puede programar pero que sigue siendo manual será omitida bajo presión. Automatice resultados estables y observables por máquina; requiera un humano para el propósito, la verdad y el contexto.

La automatización escribe evidencia, no aprobación. Un fallo bloquea la puerta; un script que pasa no aprueba las columnas humanas.

Reglas de decisión

“Mal” debe ser observable. Utilice estos umbrales a menos que el tipo de publicación o elemento seleccionado defina uno más estricto; el contrato más específico prevalece.

N/A no es una aprobación más flexible. Es válido solo cuando el elemento realmente no aplica — por ejemplo, no se necesita redirección porque ninguna URL está siendo reemplazada — y el registro indica por qué. Una excepción debe nombrar la regla cambiada, la razón comercial, el riesgo, el aprobador, el responsable de la corrección y la fecha de vencimiento. La autoridad de lanzamiento la firma; el revisor de QA no se auto-aprueba.

Entregable: el registro de aprobación

Adjunte un registro inmutable al candidato exacto. Una auditoría posterior debe poder distinguir “nunca revisado” de “revisado y aprobado bajo la versión de especificación 1”. Almacene campos estructurados en lugar de una captura de pantalla de marcas verdes.

Ruta de página / canónica:
ID del candidato de lanzamiento o hash de contenido:
Tipo de publicación y entidad:
Versión de especificación:
Responsable de QA:
Autoridad de lanzamiento:
Iniciado / completado (marca de tiempo):

Verificaciones:
- Grupo / elemento:
- Resultado: APROBADO | REPROBADO | N/A
- Evidencia: salida del validador, ubicación de la fuente, destino u observación
- Revisado por / en:

Excepciones:
- Regla y alcance:
- Razón y riesgo:
- Aprobador:
- Responsable de corrección / vencimiento:

Decisión: APROBADO — PUBLICAR | REPROBADO — RETENER
Responsable de verificación en vivo y plazo:
Próxima fecha de revisión de mantenimiento:

Un registro de aprobación es de solo adición. Una especificación o candidato cambiado obtiene una nueva auditoría, no un historial reescrito.

Qué sucede en caso de fallo

El fallo inicia un bucle de corrección, no una negociación en el hilo de revisión.

1. El responsable de QA marca el candidato como REPROBADO — RETENER, registra la evidencia y se detiene en el punto donde continuar probaría una versión que seguramente cambiará.
2. El propietario del contenido corrige fallos de tipo de publicación, elementos, texto, metadatos y evidencia. El propietario de la implementación corrige fallos de esquema, enlaces, medios, enrutamiento, renderizado y automatización. Un especialista vuelve a verificar las afirmaciones en su dominio.
3. Quien corrige identifica cada superficie cambiada. El responsable de QA vuelve a ejecutar el elemento fallido, sus elementos dependientes y cualquier grupo afectado por el cambio. Una respuesta reescrita, por ejemplo, reabre afirmaciones, conformidad de elementos, paridad de esquema y extracción de IA.
4. El responsable de QA crea un nuevo resultado con marca de tiempo. La publicación permanece bloqueada hasta que cada elemento aplicable pase y cada N/A o excepción tenga autoridad válida.

El autor no certifica su corrección. QA posee el registro, producción posee las correcciones, los especialistas poseen la aprobación del dominio y la autoridad de lanzamiento posee las excepciones.

Qué sale mal

• Tratar la puerta como corrección de estilo. La gramática puede ser impecable mientras la página usa el tipo de publicación incorrecto, contradice su esquema o no puede ser indexada.
• Probar la fuente en lugar del candidato de lanzamiento. Un Markdown válido no prueba que las plantillas emitieron la canónica prevista, la estructura accesible o el diseño responsivo.
• Hacer que cada elemento sea manual. Los revisores hacen clic repetidamente en comprobaciones deterministas hasta que una fecha límite les enseña a saltarse la lista.
• Hacer que cada elemento sea automatizado. Un validador verde no puede decidir si la evidencia respalda una afirmación causal o si una comparación responde a la decisión del lector.
• Aceptar “lo arreglaré después del lanzamiento”. Eso convierte una puerta pre-publicación en un backlog no documentado y borra el significado de APROBADO.
• Permitir que la misma persona implemente y apruebe. La auto-revisión omite suposiciones porque el revisor recuerda el comportamiento previsto en lugar de observar el resultado real.

Transferencia

El siguiente estado es la publicación y la verificación en vivo. QA entrega el candidato aprobado, el registro APROBADO, la ruta canónica, el mapa de redirecciones, la ventana de lanzamiento y las excepciones aprobadas. El publicador devuelve la URL en vivo y la hora de despliegue; el responsable de verificación en vivo repite las comprobaciones de estado, canónica, indexabilidad, redirecciones, esquema, enlaces, medios, móvil y CTA.

Si la producción difiere, las comprobaciones afectadas se reabren. Si coincide, agregue la URL en vivo y la evidencia sin sobrescribir el resultado del candidato. Las auditorías posteriores utilizan la versión de especificación almacenada para distinguir la desviación de un estándar cambiado.

Preguntas frecuentes

Preguntas frecuentes

Aprobado significa que el candidato cumple con el contrato actual con evidencia inspeccionable. Cualquier otra cosa es una retención. El CTA de cierre del diseño de academy sigue a estas preguntas frecuentes.