Caso Carzuga: alinear un sitio con la operación real

El 2 y 3 de octubre de 2026 revisamos carzuga.com y corregimos una diferencia importante: el sitio destacaba el código propio y los chatbots más que el trabajo de conectar procesos, herramientas y personas. Este es un caso de nuestro propio sitio, con cambios publicados y evidencia técnica. Su resultado es una representación más fiel de Carzuga y la corrección de fallas verificables.

Para quien dirige un negocio, la lección es práctica: una página debe explicar qué problema resuelve, cómo se decide la solución y quién se hace responsable de mantenerla. Después, hay que comprobar que esa explicación y sus controles funcionan en la versión pública.

El problema inicial

Carzuga configura herramientas, integra procesos y desarrolla software cuando hace falta. También construye y mantiene sitios web y trabaja en contenido, SEO y soporte de plataformas según el alcance acordado. Sin embargo, el mensaje principal daba demasiado peso a construir código propio. Eso podía hacer que alguien entendiera una oferta más estrecha que la operación real.

La revisión encontró también problemas concretos:

• Texto morado con contraste insuficiente en la página de software: doce elementos reportados por Lighthouse, con relaciones aproximadas de 2.33 a 3.86:1.
• Una URL de imagen del fundador en los datos estructurados que devolvía 404, aunque el retrato visible sí cargaba.
• El enlace de consulta /#audit sin una sección de destino; durante la implementación encontramos además un desbordamiento horizontal en la página de software a tamaño de tableta.
• Afirmaciones generales sobre disponibilidad, indexación y resultados en buscadores o IA que no describían compromisos comprobados para cada proyecto.

El objetivo fue corregir esos puntos y explicar mejor el alcance. La revisión editorial de los artículos anteriores quedó como trabajo adicional.

Las decisiones de implementación

Presentamos la configuración y la integración como opciones completas. En la portada, el punto de partida pasó a ser conectar procesos, herramientas y personas. La página de software a la medida conserva su función: explicar cuándo una necesidad requiere desarrollo propio.

Hicimos visible la operación posterior a la entrega. La sección de operación digital reúne mantenimiento web, SEO, contenido y soporte de plataformas. Las condiciones de atención se acuerdan por proyecto; una infraestructura de Google Cloud no demuestra por sí sola la disponibilidad medida de todos los sistemas.

Unificamos contenido e identidad. El perfil de Carzuga, la identidad del fundador, las descripciones y los datos estructurados se revisaron para describir la misma empresa. La imagen del fundador en los metadatos se cambió al recurso real. Las páginas legales recibieron su URL canónica correspondiente.

Corregimos controles y lectura. La portada adoptó la navegación compartida. Los enlaces móviles cierran el menú, Escape devuelve el foco al control de apertura y el foco de teclado es visible. Ajustamos el contraste, el destino de consulta y la cuadrícula que desbordaba en tableta. También mantuvimos visible el contenido principal sin depender de un observador de desplazamiento.

Acotamos las promesas de búsqueda. En nuestro proceso SEO, las respuestas visibles y su marcado FAQ comparten una fuente. Eliminamos promesas generales de indexación inmediata, plazos fijos y recomendaciones garantizadas en IA. Son resultados que requieren evidencia posterior.

Cómo verificamos la publicación

Diagrama del método utilizado en este caso; no representa una medición de ventas ni una certificación.

La secuencia separó cinco comprobaciones:

1. Alcance. Contrastar el sitio con la descripción de la empresa y definir qué afirmaciones podían sostenerse.
2. Código. Implementar los cambios, revisar el diff y validar tipos y compilación.
3. Exportación. Recorrer las páginas generadas, sus enlaces, recursos, títulos, canónicas y datos estructurados.
4. Publicación. Desplegar desde una copia limpia del código aprobado e identificar la revisión y la versión de Hosting.
5. Sitio público. Comparar el HTML servido con la exportación exacta y probar controles representativos en navegador.

La publicación ocurrió el 3 de octubre de 2026 a las 19:13, hora de Ciudad Juárez. El registro de la plataforma usa UTC: 4 de octubre de 2026, 01:13:12.553Z. La revisión de código fue 9a66dff5cdb6b3a1bf9ad1748be33918c0d7bf8a y la versión finalizada de Firebase Hosting fue 9208449e62e90c20. Estos identificadores describen esta entrega concreta; una modificación posterior tendrá otra revisión.

Qué observamos y qué significan los números

Las comprobaciones del 3 de octubre verificaron 55 páginas del sitemap. El HTML público coincidió con los archivos de la exportación de esa revisión. En la exportación revisamos 1,679 enlaces internos y 928 referencias a recursos locales; son referencias revisadas, no visitantes ni recursos únicos. Las seis preguntas de la página de proceso SEO coincidieron exactamente entre contenido visible y JSON-LD.

Las pruebas manuales incluyeron portada y software en móvil y escritorio, software en tableta, cierre del menú, retorno del foco, preguntas desplegables y carga del retrato. El botón de software abrió WhatsApp con el contexto correcto. Esa prueba verificó el traspaso; no se envió un mensaje ni se contó como una consulta recibida.

También ejecutamos Lighthouse 12.8.2 sobre producción, con limitación simulada: tres ejecuciones por página y dispositivo, doce muestras en total. La portada y la página de software obtuvieron 100 en las comprobaciones automáticas de accesibilidad y SEO en las doce muestras. En la auditoría del 2 de octubre, software había obtenido 95 en accesibilidad; el contraste reportado quedó corregido y se volvió a comprobar.

Para rendimiento, la mediana móvil fue 99 en portada y 100 en software. Las ejecuciones móviles individuales fueron 90, 100 y 99 en portada; 99, 100 y 100 en software. La mediana de LCP, el tiempo hasta mostrar el elemento principal, fue de 1.930 segundos y 1.392 segundos, respectivamente. CLS, la medida de desplazamientos de diseño durante esas cargas, fue 0.

Conservamos la variación porque importa: la primera muestra móvil de portada cargó etiquetas externas retrasadas y mostró más bloqueo de JavaScript. Su puntuación de buenas prácticas fue 79 por una advertencia de cookies de Facebook, frente a 100 en las otras dos. Un seguimiento de rendimiento necesita incluir la interacción y esas herramientas externas. La documentación de Lighthouse explica por qué las puntuaciones varían con las condiciones de ejecución.

Estos números son pruebas de laboratorio con fecha, no datos de experiencia de todos los visitantes. Tampoco prueban cumplimiento integral de accesibilidad, mejoras de posicionamiento, ventas o retorno de inversión.

Lo que sigue para SEO, AEO y GEO

La claridad del contenido, los enlaces y la coherencia de los datos estructurados ayudan a construir una base comprobable. Para las funciones de IA de Google, su guía oficial mantiene la importancia del SEO y del contenido útil; el marcado no garantiza una aparición.

En este caso, aún hace falta actualizar la evidencia de Search Console, separar pruebas de consultas reales y reconciliar contactos con oportunidades calificadas. Un clic hacia WhatsApp mide intención de continuar; una conversación recibida y una oportunidad comercial requieren otras comprobaciones. Las citas en respuestas de IA también deben observarse directamente.

La auditoría dejó mantenimiento de dependencias, revisión editorial y optimización de etiquetas externas como líneas de seguimiento. El sitio está mejor alineado y los defectos descritos se corrigieron. La calidad del servicio, la confianza y los resultados del negocio se siguen demostrando con trabajo y medición.

Preguntas frecuentes

¿Qué demuestra este caso de Carzuga?

Demuestra cambios concretos en nuestro propio sitio y su verificación técnica: mensaje, navegación, contraste, metadatos y una publicación vinculada a una revisión de código. No demuestra resultados de clientes ni aumentos de ventas, tráfico o citas en respuestas de IA.

¿Un resultado de 100 en Lighthouse garantiza un sitio de clase mundial?

No. Es el resultado de comprobaciones automáticas en condiciones de laboratorio. Todavía hay que revisar la experiencia real, la accesibilidad manual, la carga de herramientas externas, la confianza y los resultados de negocio.

¿Qué debe comprobarse después de publicar un cambio?

Que la versión pública corresponda al código aprobado, que las páginas y recursos respondan, que los enlaces y controles funcionen y que el contenido visible coincida con sus metadatos. La indexación, las consultas recibidas y las oportunidades calificadas se comprueban por separado.

Aplicar el método a tu sitio

Si el sitio de tu empresa ya no explica bien lo que haces o sus controles dificultan el siguiente paso, podemos revisar el mensaje, el proceso y la base técnica antes de definir los cambios. Conoce cómo trabajamos o habla con Carzuga por WhatsApp.