Una página web puede tener buenas fotografías, un diseño atractivo, un menú que funciona, información comercial, formularios y hasta testimonios de clientes.
Para quien la visita —e incluso para la empresa propietaria— todo puede parecer perfectamente normal.
Pero una web tiene dos realidades.
La primera es la que vemos en el navegador.
La segunda está debajo: el CMS, las versiones de software, el código, las extensiones, la seguridad, las URLs, las redirecciones, el HTML que reciben los buscadores, los canonical, el sitemap, los datos estructurados y decenas de señales técnicas que un usuario normalmente nunca observa.
Hace poco trabajamos sobre el sitio de una empresa B2B peruana. Por confidencialidad no identificaremos al cliente. Lo importante de este caso no es quién era la empresa, sino una pregunta que cualquier propietario de una web debería hacerse:
¿Cómo sabemos que una web está realmente bien solo porque se ve bien?
La primera impresión era una web funcional
El sitio estaba en línea. Tenía contenido, productos, servicios, imágenes, menú y diferentes secciones corporativas.
No estábamos frente a una pantalla blanca ni ante una página visiblemente abandonada.
Ese es precisamente el problema.
Muchas deficiencias importantes de una web no producen un defecto visual inmediato.
Un visitante puede navegar durante meses o años sin saber qué versión del CMS está funcionando, qué extensiones continúan instaladas, qué código quedó de desarrollos anteriores, qué URL considera Google como principal o si existe siquiera un sitemap válido.
Por eso una auditoría profesional no puede terminar mirando la portada.
Lo primero fue mirar debajo de la superficie
Antes de pensar en palabras clave o modificar textos, era necesario determinar si la plataforma sobre la cual íbamos a trabajar era confiable.
La investigación reveló que el sitio necesitaba una recuperación técnica importante. Existía historial de compromiso y componentes que no podíamos continuar considerando confiables.
Nuestra prioridad no fue SEO.
Fue contener, preservar evidencia, realizar copias de seguridad, clasificar lo encontrado y reconstruir una base conocida.
El core de Joomla 4.4.14 se reconstruyó utilizando el paquete oficial hasta obtener una comparación sin diferencias frente a los archivos oficiales.
Ese detalle es importante.
Encontrar un archivo PHP extraño no significa automáticamente encontrar malware, del mismo modo que restaurar el core tampoco demuestra que todo el sitio está limpio. Los sitios Joomla contienen extensiones, módulos, plugins, templates y desarrollos personalizados que legítimamente incorporan PHP.
Después de reconstruir el core encontramos aproximadamente 1.300 archivos ejecutables que no pertenecían al núcleo de Joomla.
No dijimos “encontramos 1.300 virus”.
Los convertimos en un inventario que debía ser clasificado.
Ese principio —distinguir evidencia de sospecha— evitó eliminar código legítimo de una aplicación en producción.
El código personalizado también tenía que sobrevivir
La empresa utilizaba funcionalidades desarrolladas específicamente para su sitio.
Deshabilitarlas indiscriminadamente habría sido una manera muy rápida de “limpiar” la instalación y, al mismo tiempo, romper el negocio.
Auditamos el código personalizado activo. El alcance comprendió 19 extensiones propias y 190 archivos PHP. Esos archivos pasaron validación sintáctica y no mostraron los indicadores conocidos que estábamos buscando.
Solo después de separar core, extensiones de terceros, código propio, residuos históricos y elementos realmente peligrosos era razonable avanzar.
Esta parte casi nunca aparece en una propuesta de “diseño web”.
Sin embargo, determina si el sitio que visualmente funciona también tiene una base que podemos mantener con confianza.
De una versión heredada a una plataforma actual
Una actualización mayor de un CMS comprometido no debe hacerse pulsando un botón y esperando que todo funcione.
El proceso fue progresivo.
El sitio pasó de Joomla 4.4.14 a Joomla 5.4.9 y posteriormente a Joomla 6.1.4. El entorno quedó funcionando sobre PHP 8.4.26.
Entre una versión y otra comprobamos la base de datos, compatibilidad de extensiones, funcionalidades personalizadas, frontend, administrador y componentes que seguían siendo necesarios.
También hubo elementos que tuvieron que actualizarse, adaptarse o eliminarse porque pertenecían a generaciones anteriores del sitio.
El objetivo no era simplemente obtener un número de versión mayor.
El objetivo era poder afirmar que la plataforma continuaba funcionando después del cambio.
Entonces apareció otra web invisible: la que veía el buscador
Cuando llegamos al SEO técnico encontramos una diferencia llamativa entre lo que veía una persona y lo que describía realmente el documento HTML.
La portada utilizaba un title tan genérico como:
Inicio
No existía meta description en la home.
Tampoco existía una canonical declarada, Open Graph ni datos estructurados JSON-LD.
La jerarquía de encabezados tampoco representaba adecuadamente la estructura documental: la portada llegaba a presentar cinco H1.
Visualmente nada de eso impedía que una persona viera fotografías, textos o botones.
Para un buscador, sin embargo, esos elementos ayudan a entender qué documento está rastreando, cuál es su versión preferida, cuál es su tema principal y cómo se relaciona con el resto del sitio.
Aquí aparece una de las principales diferencias entre diseñar una web y construir una web que además pueda ser entendida correctamente por buscadores.
Las URLs contaban otra parte de la historia
Las principales páginas funcionaban mediante direcciones heredadas que contenían /index.php/.
Mientras estas rutas devolvían contenido correctamente, sus equivalentes limpios devolvían 404.
Es decir, una empresa podía navegar por su web normalmente mientras la arquitectura pública seguía condicionada por decisiones técnicas históricas.
Reconstruimos las rutas semánticas y establecimos una arquitectura limpia para páginas como quiénes somos, servicios, productos y contacto.
Las antiguas direcciones no se eliminaron arbitrariamente.
Se creó una estrategia de redirecciones permanentes hacia los destinos correspondientes, evitando cadenas innecesarias y consolidando la versión HTTPS con www como hostname canónico.
También se corrigieron enlaces internos para que el propio sitio dejara de alimentar rutas antiguas.
Metadata: sí, pero como parte de un sistema
Los titles y meta descriptions fueron revisados página por página de acuerdo con el contenido real del negocio.
No utilizamos una plantilla donde todas las páginas repiten las mismas palabras.
La home, Quiénes somos, Servicios, Productos y Contacto recibieron títulos, descriptions y canonical propios. Las páginas institucionales y legales se incorporaron a la arquitectura correspondiente.
También se revisó la jerarquía H1/H2 para que el HTML expresara una estructura coherente sin alterar innecesariamente el diseño que veía el cliente.
Después añadimos y validamos Open Graph y Twitter Cards utilizando contenido e imágenes existentes de la empresa, evitando duplicaciones.
Para los datos estructurados se trabajó con entidades que podíamos sustentar realmente. La home quedó relacionada mediante Organization, WebSite y WebPage, sin inventar premios, ratings, certificaciones o información que no estuviera comprobada.
El propósito del marcado estructurado no es “meter más Schema”.
Es describir correctamente aquello que realmente existe.
El sitemap mostró claramente el antes y el después
Search Console conservaba el historial de varios sitemaps antiguos con avisos y errores.
Era otra huella de la evolución técnica del sitio.
La arquitectura final utiliza un único sitemap canónico con siete URLs públicas relevantes.
Ese XML fue validado sintácticamente, responde directamente mediante HTTP 200, puede ser obtenido correctamente por Googlebot y coincide con las URLs que queremos que los buscadores descubran.
robots.txt referencia explícitamente ese sitemap.
En Search Console, el sitemap canónico actual ya aparece procesado sin warnings ni errors.
Es un cambio pequeño visualmente.
Ningún cliente entra a su web y piensa: “qué buen sitemap”.
Pero para un buscador es parte de la infraestructura mediante la cual descubre y vuelve a visitar documentos.
La recuperación no terminó cuando la web volvió a abrir
También limpiamos residuos temporales y artefactos históricos, comprobamos permisos, preservamos backups y generamos una referencia limpia posterior a la intervención.
El cierre técnico registró cero detecciones finales de malware en la comprobación utilizada, cero indicadores físicos conocidos del incidente y una aplicación pública saludable.
Ese cierre es tan importante como el SEO.
No tendría sentido optimizar para Google una aplicación cuya integridad todavía está en duda.
¿Y qué ocurrió inmediatamente en Google?
Aquí conviene diferenciar ingeniería de resultados.
Una intervención técnica puede realizarse en horas o días.
Google no elimina instantáneamente todas las señales que ha aprendido durante años.
Después de la reconstrucción, Search Console todavía mostraba señales pertenecientes a la arquitectura anterior: variantes de hostname, rutas antiguas y canonical históricas. Al mismo tiempo, las nuevas URLs limpias comenzaban su proceso de descubrimiento.
Eso es normal en una migración.
Por eso no presentamos este caso como “subimos posiciones en 48 horas”.
Todavía no existe un periodo posterior suficientemente amplio para afirmar eso de manera responsable.
Lo que sí podemos demostrar es algo anterior y necesario: la web que ahora recibe Google es técnicamente muy distinta de la que recibía antes.
Seguiremos midiendo indexación, impresiones, consultas y posiciones y actualizaremos este caso cuando exista suficiente información para realizar una comparación válida.
Una web bonita no garantiza una web saludable
Este caso nos dejó una reflexión que creemos útil para cualquier empresa.
Diseño y salud técnica no son lo mismo.
Una web puede verse excelente y tener un CMS obsoleto.
Puede tener un formulario que funciona y arrastrar extensiones antiguas.
Puede tener fotografías espectaculares y un <title>Inicio</title>.
Puede tener un menú perfectamente visible y utilizar una arquitectura de URLs que nunca fue revisada.
Puede aparecer correctamente en un navegador y no disponer de una canonical clara.
Puede funcionar para el propietario y seguir enviando señales inconsistentes a los buscadores.
Nada de eso significa que el diseño sea irrelevante.
Significa que la calidad de una web no puede juzgarse únicamente por aquello que vemos.
Qué debería preguntar una empresa sobre su propia web
La pregunta no debería ser solamente:
“¿Mi web se ve bien?”
También debería ser:
“¿Quién revisa lo que hay detrás?”
¿El CMS está actualizado? ¿Las extensiones siguen mantenidas? ¿El código personalizado continúa siendo compatible? ¿Las URLs son las correctas? ¿Existen duplicados? ¿Google recibe la canonical adecuada? ¿El sitemap representa realmente la arquitectura pública? ¿El HTML tiene la estructura que creemos? ¿Existe una estrategia de backup y actualización?
Son preguntas menos vistosas que elegir una tipografía o una fotografía hero.
Pero pueden determinar cuánto durará realmente una web y qué tan fácil será mantenerla, protegerla y posicionarla.
El SEO técnico comienza antes de las keywords
Una de las mayores enseñanzas de esta intervención es que el SEO técnico no puede aislarse del sistema que produce las páginas.
Antes de optimizar palabras clave necesitamos saber que el CMS es mantenible, que la URL correcta responde, que los robots pueden acceder a ella, que su canonical es coherente, que el sitemap la identifica y que la versión antigua no continúa compitiendo innecesariamente.
Solo entonces tiene sentido trabajar contenido, enlazado interno, autoridad y posiciones.
Ese orden puede no ser tan atractivo como prometer resultados rápidos.
Pero construye una base mucho más difícil de perder.
Este caso ha sido anonimizado para proteger la información técnica y comercial del cliente. Los datos incluidos corresponden a comprobaciones reales realizadas durante la intervención; no se han atribuido resultados de posicionamiento que todavía no puedan demostrarse.
Si quieres conocer cómo revisamos una web más allá de su apariencia, consulta nuestra Auditoría SEO y nuestro enfoque de SEO técnico.
← Volver a nuestros casos reales
Una página web puede tener buenas fotografías, un diseño atractivo, un menú que funciona, información comercial, formularios y hasta testimonios de clientes.
Para quien la visita e incluso para la empresa propietaria todo puede parecer perfectamente normal.
Pero una web tiene dos realidades.
La primera es la que vemos en el navegador.
La segunda está debajo: el CMS, las versiones de software, el código, las extensiones, la seguridad, las URLs, las redirecciones, el HTML que reciben los buscadores, los canonical, el sitemap, los datos estructurados y decenas de señales técnicas que un usuario normalmente nunca observa.
Hace poco trabajamos sobre el sitio de una empresa B2B peruana. Por confidencialidad no identificaremos al cliente. Lo importante de este caso no es quién era la empresa, sino una pregunta que cualquier propietario de una web debería hacerse:
¿Cómo sabemos que una web está realmente bien solo porque se ve bien?
La primera impresión era una web funcional
El sitio estaba en línea. Tenía contenido, productos, servicios, imágenes, menú y diferentes secciones corporativas.
No estábamos frente a una pantalla blanca ni ante una página visiblemente abandonada.
Ese es precisamente el problema.
Muchas deficiencias importantes de una web no producen un defecto visual inmediato.
Un visitante puede navegar durante meses o años sin saber qué versión del CMS está funcionando, qué extensiones continúan instaladas, qué código quedó de desarrollos anteriores, qué URL considera Google como principal o si existe siquiera un sitemap válido.
Por eso una auditoría profesional no puede terminar mirando la portada.
Lo primero fue mirar debajo de la superficie
Antes de pensar en palabras clave o modificar textos, era necesario determinar si la plataforma sobre la cual íbamos a trabajar era confiable.
La investigación reveló que el sitio necesitaba una recuperación técnica importante. Existía historial de compromiso y componentes que no podíamos continuar considerando confiables.
Nuestra prioridad no fue SEO.
Fue contener, preservar evidencia, realizar copias de seguridad, clasificar lo encontrado y reconstruir una base conocida.
El core de Joomla 4.4.14 se reconstruyó utilizando el paquete oficial hasta obtener una comparación sin diferencias frente a los archivos oficiales.
Ese detalle es importante.
Encontrar un archivo PHP extraño no significa automáticamente encontrar malware, del mismo modo que restaurar el core tampoco demuestra que todo el sitio está limpio. Los sitios Joomla contienen extensiones, módulos, plugins, templates y desarrollos personalizados que legítimamente incorporan PHP.
Después de reconstruir el core encontramos aproximadamente 1.300 archivos ejecutables que no pertenecían al núcleo de Joomla.
No dijimos “encontramos 1.300 virus”.
Los convertimos en un inventario que debía ser clasificado.
Ese principio distinguir evidencia de sospecha evitó eliminar código legítimo de una aplicación en producción.
El código personalizado también tenía que sobrevivir
La empresa utilizaba funcionalidades desarrolladas específicamente para su sitio.
Deshabilitarlas indiscriminadamente habría sido una manera muy rápida de “limpiar” la instalación y, al mismo tiempo, romper el negocio.
Auditamos el código personalizado activo. El alcance comprendió 19 extensiones propias y 190 archivos PHP. Esos archivos pasaron validación sintáctica y no mostraron los indicadores conocidos que estábamos buscando.
Solo después de separar core, extensiones de terceros, código propio, residuos históricos y elementos realmente peligrosos era razonable avanzar.
Esta parte casi nunca aparece en una propuesta de “diseño web”.
Sin embargo, determina si el sitio que visualmente funciona también tiene una base que podemos mantener con confianza.
De una versión heredada a una plataforma actual
Una actualización mayor de un CMS comprometido no debe hacerse pulsando un botón y esperando que todo funcione.
El proceso fue progresivo.
El sitio pasó de Joomla 4.4.14 a Joomla 5.4.9 y posteriormente a Joomla 6.1.4. El entorno quedó funcionando sobre PHP 8.4.26.
Entre una versión y otra comprobamos la base de datos, compatibilidad de extensiones, funcionalidades personalizadas, frontend, administrador y componentes que seguían siendo necesarios.
También hubo elementos que tuvieron que actualizarse, adaptarse o eliminarse porque pertenecían a generaciones anteriores del sitio.
El objetivo no era simplemente obtener un número de versión mayor.
El objetivo era poder afirmar que la plataforma continuaba funcionando después del cambio.
Entonces apareció otra web invisible: la que veía el buscador
Cuando llegamos al SEO técnico encontramos una diferencia llamativa entre lo que veía una persona y lo que describía realmente el documento HTML.
La portada utilizaba un title tan genérico como:
Inicio
No existía meta description en la home.
Tampoco existía una canonical declarada, Open Graph ni datos estructurados JSON-LD.
La jerarquía de encabezados tampoco representaba adecuadamente la estructura documental: la portada llegaba a presentar cinco H1.
Visualmente nada de eso impedía que una persona viera fotografías, textos o botones.
Para un buscador, sin embargo, esos elementos ayudan a entender qué documento está rastreando, cuál es su versión preferida, cuál es su tema principal y cómo se relaciona con el resto del sitio.
Aquí aparece una de las principales diferencias entre diseñar una web y construir una web que además pueda ser entendida correctamente por buscadores.
Las URLs contaban otra parte de la historia
Las principales páginas funcionaban mediante direcciones heredadas que contenían /index.php/.
Mientras estas rutas devolvían contenido correctamente, sus equivalentes limpios devolvían 404.
Es decir, una empresa podía navegar por su web normalmente mientras la arquitectura pública seguía condicionada por decisiones técnicas históricas.
Reconstruimos las rutas semánticas y establecimos una arquitectura limpia para páginas como quiénes somos, servicios, productos y contacto.
Las antiguas direcciones no se eliminaron arbitrariamente.
Se creó una estrategia de redirecciones permanentes hacia los destinos correspondientes, evitando cadenas innecesarias y consolidando la versión HTTPS con www como hostname canónico.
También se corrigieron enlaces internos para que el propio sitio dejara de alimentar rutas antiguas.
Metadata: sí, pero como parte de un sistema
Los titles y meta descriptions fueron revisados página por página de acuerdo con el contenido real del negocio.
No utilizamos una plantilla donde todas las páginas repiten las mismas palabras.
La home, Quiénes somos, Servicios, Productos y Contacto recibieron títulos, descriptions y canonical propios. Las páginas institucionales y legales se incorporaron a la arquitectura correspondiente.
También se revisó la jerarquía H1/H2 para que el HTML expresara una estructura coherente sin alterar innecesariamente el diseño que veía el cliente.
Después añadimos y validamos Open Graph y Twitter Cards utilizando contenido e imágenes existentes de la empresa, evitando duplicaciones.
Para los datos estructurados se trabajó con entidades que podíamos sustentar realmente. La home quedó relacionada mediante Organization, WebSite y WebPage, sin inventar premios, ratings, certificaciones o información que no estuviera comprobada.
El propósito del marcado estructurado no es “meter más Schema”.
Es describir correctamente aquello que realmente existe.
El sitemap mostró claramente el antes y el después
Search Console conservaba el historial de varios sitemaps antiguos con avisos y errores.
Era otra huella de la evolución técnica del sitio.
La arquitectura final utiliza un único sitemap canónico con siete URLs públicas relevantes.
Ese XML fue validado sintácticamente, responde directamente mediante HTTP 200, puede ser obtenido correctamente por Googlebot y coincide con las URLs que queremos que los buscadores descubran.
robots.txt referencia explícitamente ese sitemap.
En Search Console, el sitemap canónico actual ya aparece procesado sin warnings ni errors.
Es un cambio pequeño visualmente.
Ningún cliente entra a su web y piensa: “qué buen sitemap”.
Pero para un buscador es parte de la infraestructura mediante la cual descubre y vuelve a visitar documentos.
La recuperación no terminó cuando la web volvió a abrir
También limpiamos residuos temporales y artefactos históricos, comprobamos permisos, preservamos backups y generamos una referencia limpia posterior a la intervención.
El cierre técnico registró cero detecciones finales de malware en la comprobación utilizada, cero indicadores físicos conocidos del incidente y una aplicación pública saludable.
Ese cierre es tan importante como el SEO.
No tendría sentido optimizar para Google una aplicación cuya integridad todavía está en duda.
¿Y qué ocurrió inmediatamente en Google?
Aquí conviene diferenciar ingeniería de resultados.
Una intervención técnica puede realizarse en horas o días.
Google no elimina instantáneamente todas las señales que ha aprendido durante años.
Después de la reconstrucción, Search Console todavía mostraba señales pertenecientes a la arquitectura anterior: variantes de hostname, rutas antiguas y canonical históricas. Al mismo tiempo, las nuevas URLs limpias comenzaban su proceso de descubrimiento.
Eso es normal en una migración.
Por eso no presentamos este caso como “subimos posiciones en 48 horas”.
Todavía no existe un periodo posterior suficientemente amplio para afirmar eso de manera responsable.
Lo que sí podemos demostrar es algo anterior y necesario: la web que ahora recibe Google es técnicamente muy distinta de la que recibía antes.
Seguiremos midiendo indexación, impresiones, consultas y posiciones y actualizaremos este caso cuando exista suficiente información para realizar una comparación válida.
Una web bonita no garantiza una web saludable
Este caso nos dejó una reflexión que creemos útil para cualquier empresa.
Diseño y salud técnica no son lo mismo.
Una web puede verse excelente y tener un CMS obsoleto.
Puede tener un formulario que funciona y arrastrar extensiones antiguas.
Puede tener fotografías espectaculares y un <title>Inicio</title>.
Puede tener un menú perfectamente visible y utilizar una arquitectura de URLs que nunca fue revisada.
Puede aparecer correctamente en un navegador y no disponer de una canonical clara.
Puede funcionar para el propietario y seguir enviando señales inconsistentes a los buscadores.
Nada de eso significa que el diseño sea irrelevante.
Significa que la calidad de una web no puede juzgarse únicamente por aquello que vemos.
Qué debería preguntar una empresa sobre su propia web
La pregunta no debería ser solamente:
“¿Mi web se ve bien?”
También debería ser:
“¿Quién revisa lo que hay detrás?”
¿El CMS está actualizado? ¿Las extensiones siguen mantenidas? ¿El código personalizado continúa siendo compatible? ¿Las URLs son las correctas? ¿Existen duplicados? ¿Google recibe la canonical adecuada? ¿El sitemap representa realmente la arquitectura pública? ¿El HTML tiene la estructura que creemos? ¿Existe una estrategia de backup y actualización?
Son preguntas menos vistosas que elegir una tipografía o una fotografía hero.
Pero pueden determinar cuánto durará realmente una web y qué tan fácil será mantenerla, protegerla y posicionarla.
El SEO técnico comienza antes de las keywords
Una de las mayores enseñanzas de esta intervención es que el SEO técnico no puede aislarse del sistema que produce las páginas.
Antes de optimizar palabras clave necesitamos saber que el CMS es mantenible, que la URL correcta responde, que los robots pueden acceder a ella, que su canonical es coherente, que el sitemap la identifica y que la versión antigua no continúa compitiendo innecesariamente.
Solo entonces tiene sentido trabajar contenido, enlazado interno, autoridad y posiciones.
Ese orden puede no ser tan atractivo como prometer resultados rápidos.
Pero construye una base mucho más difícil de perder.
Este caso ha sido anonimizado para proteger la información técnica y comercial del cliente. Los datos incluidos corresponden a comprobaciones reales realizadas durante la intervención; no se han atribuido resultados de posicionamiento que todavía no puedan demostrarse.
Si quieres conocer cómo revisamos una web más allá de su apariencia, consulta nuestra Auditoría SEO y nuestro enfoque de SEO técnico.