Estructura de la web de empresa para prestadores de servicios con una oferta que requiere explicación

Abra el sitio web de un prestador de servicios con una oferta compleja y haga clic en «Servicios». Muy a menudo aparece una página larga con ocho subtítulos, tres frases por tema y un formulario de contacto al final. En este escenario partimos de una consultoría de documentación de procesos que ofrece cinco servicios distintos. Cada uno de ellos requiere una conversación antes de que un cliente entienda lo que recibe.

La estructura no surgió de una decisión, sino de añadidos. Cada vez que se incorporaba un servicio, se añadía un párrafo. El menú se quedó igual y la página de inicio muestra los servicios como mosaicos que saltan todos al mismo ancla. Para el equipo parece completo, porque todos saben lo que hay detrás de las palabras clave.

Un interesado no lo sabe. Llega con una pregunta concreta, por ejemplo si la consultoría sirve también para una empresa de su tamaño o qué ocurre después de la llamada inicial. No busca un resumen, sino una respuesta, y si la página no se la da, un competidor está a un clic de distancia. Por eso la situación de partida es menos un problema de diseño que un problema de orden.

El primer problema afecta a la orientación. Quien ojea una página comodín larga lee los titulares y salta. Si no encuentra su propia situación en las primeras líneas, supone que no aparece. La página responde muchas preguntas de forma superficial y ninguna con la profundidad suficiente para sostener una decisión, y eso resulta especialmente caro en ofertas que requieren explicación.

El segundo problema afecta a la búsqueda. Una página que trata cinco temas compite consigo misma. Para una consulta como «documentación de procesos para servicios de enfermería» hay un párrafo, pero no una página que ocupe claramente ese tema. Los buscadores asignan las páginas a temas y, donde no es posible una asignación clara, suele ganar la página que trata exactamente ese tema. También se complica el enlazado, porque cada enlace apunta a «Servicios» en lugar de al servicio al que se refiere.

El tercer problema es la confianza. Quien contrata un servicio complejo asume un riesgo: invierte dinero y tiempo en algo que no puede comprobar de antemano. En ese momento, los argumentos de venta surten menos efecto que las pruebas, es decir, el proceso, la lógica de precios, las referencias y las personas de contacto. Todo eso necesita un espacio que una página comodín no puede dar sin volverse ilegible.

A ello se suma un punto práctico. Las páginas comodín se mantienen mal. Cuando cambia un servicio, alguien tiene que encontrar el lugar correcto en un texto largo y, por precaución, a menudo se deja como está. Pasados dos años, la mitad ya no es correcta.

Antes de que surja un árbol de páginas hace falta una base que no salga de la intuición. Trabajaríamos con cuatro fuentes: las preguntas de llamadas iniciales y correos reales, las consultas de búsqueda de Search Console si el sitio web ya aporta datos, las objeciones de presupuestos perdidos y los términos que los propios clientes utilizan. Estos últimos suelen diferir del lenguaje técnico del proveedor, y precisamente ahí surgen lagunas.

A partir de estas fuentes se puede deducir qué servicios merecen una página propia. Un criterio útil es: ¿tiene un servicio un interés de búsqueda propio, un público objetivo propio o un camino de decisión propio? Entonces recibe una página. Si comparte los tres con otro servicio, pertenece a la misma página. Así se evitan los dos errores: tanto la página comodín como la fragmentación en docenas de páginas individuales pobres.

Un ejemplo muestra cómo es esto. Si en la llamada inicial cinco de cada diez interesados hacen la misma pregunta, como «¿Cuánto cuesta aproximadamente?» o «¿Quién tiene que participar por nuestra parte?», entonces falta una respuesta en el sitio web. Esas preguntas son el encargo de contenidos, no la lista de deseos del equipo. Se pueden recoger en una tabla, con fecha, fuente y la página que deba responderlas en el futuro.

Igual de importante es la pregunta sobre en qué estado llega el visitante. Un interesado que aún no sabe nombrar su problema necesita una página distinta de la de quien ya compara tres ofertas. Ambos suelen aterrizar en la misma página de inicio. La tarea de la estructura es ofrecer un camino a los dos, sin abrumar a uno con detalles ni aburrir al otro con generalidades.

La solución sigue un principio sencillo: cada servicio recibe una página propia que responde por completo a su pregunta. Por encima hay una página de resumen que no explica, sino que ordena y conduce. Al lado hay páginas de pruebas, como el método de trabajo, las referencias y Quiénes somos, a las que enlaza cada página de servicio. Así surge una red en la que cada página tiene una función.

Como alternativa se ofrece un único sitio muy largo, la llamada solución de una sola página (one-page). Parece ordenada y funciona si la oferta consiste en un solo servicio. Con varios servicios que requieren explicación pierde, porque cada nuevo servicio alarga la página y el interés de búsqueda ya no se atiende por separado. Aquí la consideramos la opción más débil.

La segunda alternativa va en la dirección contraria: una página para cada variante, cada sector, cada ciudad. Eso genera muchas direcciones con poco contenido y un alto esfuerzo de mantenimiento. Los buscadores reconocen estos patrones, y los visitantes también. Una página adicional solo tiene sentido cuando tiene algo propio que decir, por ejemplo un proceso distinto o riesgos distintos. El reparto se sitúa entre los extremos y depende de la oferta.

La página de resumen merece más cuidado del que suele dársele. Es el lugar donde aterrizan los visitantes indecisos y debería ordenar los servicios por situaciones («falta documentación», «documentación desactualizada», «se acerca una auditoría») en lugar de enumerar solo nombres de producto. Cada tarjeta indica en una frase cuándo encaja el servicio y cuándo no, y conduce a su página propia.

Un compromiso es inevitable: más páginas significan más mantenimiento. Por eso no empezaríamos con todas las páginas imaginables, sino con las que tienen un interés de búsqueda claro y un camino de decisión, y ampliaríamos el árbol más adelante.

El árbol de páginas se mantiene plano. Consta de la página de inicio, un resumen de servicios con los servicios individuales debajo, un área para el método de trabajo y las referencias, Quiénes somos, Conocimiento o Novedades y Contacto. Rara vez hacen falta más de dos niveles por debajo de la página de inicio. Cada nivel adicional cuesta clics, y lo que solo se alcanza a través de tres niveles de menú se encuentra menos.

La navegación no enumera todo lo que hay. Nombra de cinco a siete puntos principales en el lenguaje de los visitantes, es decir, «Consultoría para servicios de enfermería» en lugar de «Solutions». La entrada «Servicios» abre un submenú si hace falta, pero también conduce sin ratón a una página de resumen real, para que el resumen siga siendo localizable sin el menú. El punto de contacto está siempre en el mismo sitio y tiene el mismo aspecto.

Una página de servicio sigue una estructura recurrente. Primero va la pregunta que responde, en una frase. Después se indica a quién va dirigido el servicio, qué se entrega concretamente, cómo es el proceso, con qué hay que contar y qué no está incluido. A continuación vienen las pruebas, las preguntas frecuentes y una vía de contacto adecuada a la situación de decisión. Esta estructura fija ayuda a los visitantes a comparar y a los redactores a escribir.

El enlazado interno es importante. Cada página de servicio enlaza con dos o tres servicios relacionados, con el método de trabajo y con artículos de conocimiento pertinentes. Los textos de los enlaces nombran el destino («Cómo transcurre una llamada inicial») en lugar de decir «saber más». Así surge una red que guía a los visitantes y muestra a los buscadores las relaciones entre los temas.

La base técnica sigue a la estructura. Cada servicio recibe una dirección descriptiva y estable, como /leistungen/prozessdokumentation, que no depende de una fecha ni de un número interno. Si cambia el título de una página, la dirección permanece, y cuando aun así cambia, una redirección única conduce al nuevo destino. Quien lo define pronto evita roturas posteriores en el índice.

Cada página recibe un title único, una descripción y exactamente un H1. Los titulares inferiores siguen el esquema de la pregunta, no el diseño. Una ruta de migas de pan muestra la posición en el árbol y ofrece al mismo tiempo una señal estructurada que puede marcarse con schema.org BreadcrumbList. Para los servicios puede encajar además el tipo Service, y para las preguntas el tipo FAQPage, aunque Google ha limitado su presentación en los resultados de búsqueda.

La navegación se construye como una lista real de enlaces, no como una construcción puramente de script. El submenú debe poder alcanzarse con el teclado y, en el smartphone, se abre como una selección sencilla y grande. Un menú que solo funciona al pasar el ratón excluye a los dispositivos táctiles y a los usuarios de teclado.

El sitemap contiene solo las páginas que deben estar en el índice, y el enlazado interno garantiza que ninguna página de servicio esté a más de tres clics de la página de inicio. Para comprobarlo basta un rastreo con Screaming Frog, que hace visibles las páginas huérfanas y las cadenas, y Search Console muestra al cabo de unas semanas si las páginas se han indexado. Para los tiempos de carga rigen los umbrales habituales: LCP hasta 2,5 segundos, INP hasta 200 milisegundos, CLS hasta 0,1.

El caso especial más frecuente son los servicios que se solapan. Una consultoría sobre documentación de procesos y una formación sobre el mismo tema tienen el mismo público objetivo, pero caminos de decisión distintos. Los mantendríamos separados y haríamos que se enlacen entre sí, en lugar de formar una unidad artificial. Lo decisivo es que cada página siga siendo comprensible por sí sola y no dependa de la otra.

También es difícil el tema de los precios. Muchos prestadores de servicios evitan mencionarlos porque cada proyecto es distinto. Sin ninguna orientación, sin embargo, surge desconfianza o una solicitud que fracasa por el presupuesto. Una posibilidad es nombrar los factores que determinan el precio e indicar un rango típico, en la medida en que la empresa pueda responder de él. Quien no pueda hacerlo debería explicar con franqueza cómo se elabora una oferta y cuánto tarda.

Un tercer caso son las referencias que no se pueden nombrar. En muchos sectores, los clientes están sujetos a confidencialidad. Entonces quedan la descripción de métodos anonimizados, la mención de sectores o la presentación de un desarrollo típico de proyecto. Las citas inventadas o las cifras maquilladas no son una solución, porque no resisten una pregunta y dañan aquello que deben respaldar.

Otro caso es el público objetivo que pregunta por sector. Un servicio de enfermería y una empresa artesanal necesitan el mismo servicio con otro lenguaje. En lugar de crear una copia por sector, a menudo basta una sección en la página de servicio con ejemplos específicos del sector. Solo cuando el proceso, los riesgos o los términos de búsqueda difieren claramente se justifica una página propia, y entonces debería aportar de verdad contenidos distintos.

Por último, el caso del crecimiento: si se añade un sexto servicio o un nuevo público objetivo, el árbol no debe romperse. Por eso dejamos por escrito los criterios de división, para poder decidir más adelante si se añade, se amplía o se fusiona una página. Lo mismo vale cuando se deja de ofrecer un servicio: la página recibe una redirección a la más afín, no a la página de inicio.

Una estructura clara mejora las condiciones, pero no garantiza resultados. Lo que cabe esperar de forma realista es que los visitantes encuentren antes su pregunta, que las solicitudes sean más concretas y que algunos servicios se encuentren mejor con las consultas de búsqueda adecuadas. Cuánto, depende de la competencia, la oferta y el mantenimiento, y para cifras concretas no existe una base seria.

Se puede medir en tres capas. Primero, el comportamiento en el sitio web: ¿por qué páginas entran los visitantes, cuántos llegan a la página de servicio y a la vía de contacto, y dónde abandonan? Segundo, la visibilidad en Search Console: ¿para qué consultas aparecen las distintas páginas de servicio y coinciden la consulta y la página? Tercero, la calidad de las solicitudes, que solo se aprecia en la conversación. Si los interesados hacen menos preguntas básicas, es una señal de que las páginas cumplen su cometido.

El periodo debería ser generoso. Una estructura recién reordenada necesita semanas para que los buscadores la procesen y meses para que se muestre un patrón. Compare solo periodos equivalentes y tenga en cuenta las fluctuaciones estacionales; de lo contrario interpretará la casualidad como efecto. Una comparación entre antes y después sin una medición de partida sigue siendo una afirmación.

Lo que expresamente no cabe esperar es que más páginas aporten automáticamente más solicitudes. Una página de servicio pobre es peor que ninguna, porque hace una promesa que no cumple. Decide la calidad de cada página; la estructura solo crea el marco para ello.

Empiece por las preguntas de los clientes, no por el menú. Quien fija primero la navegación construye páginas para rellenar entradas del menú. Quien recopila primero las preguntas suele darse cuenta de que dos entradas del menú responden la misma pregunta y de que una pregunta importante no tiene sitio alguno. La recopilación de preguntas es el camino más corto hacia una estructura sólida.

Mantenga las páginas estrechas en su pretensión y profundas en su contenido. Una página de servicio responde una pregunta y remite a otras para el resto. No tiene que decirlo todo sobre la empresa, sino lo suficiente para que sea posible una decisión. Cuanto más claro es el planteamiento, más fácil resulta escribir y menos texto se arrastra solo por costumbre.

Planifique varias vías de contacto. Algunos interesados llaman, otros escriben y otros quieren primero reservar una cita o descargar un documento. Un único formulario excluye a estos grupos. Cada vía debería explicar qué ocurre después, en qué plazo llega una respuesta y qué datos hacen falta. Eso reduce el umbral más que cualquier diseño.

Compruebe la estructura con tareas reales. Pida a tres personas que no conozcan la empresa que respondan una pregunta concreta y observe dónde buscan. Quien acaba tres veces en la entrada de menú equivocada no ha cometido el error: lo ha causado la etiqueta. Una prueba así dura una hora y descubre más que cualquier reunión.

Cuente con que la estructura vive. Pasados unos meses, las consultas de búsqueda y las conversaciones muestran qué páginas faltan, cuáles van juntas y cuáles no lee nadie. Quien entonces afina en lugar de reconstruir mantiene el sitio web actualizado y los costes bajos.

Una web de empresa para una oferta que requiere explicación es sobre todo una tarea de orden. Decide si los visitantes encuentran su pregunta, si los buscadores reconocen un tema y si un interesado cobra la confianza suficiente para ponerse en contacto. Para ello no hace falta un gran número de páginas, sino una división que encaje con la oferta y que se pueda mantener.

El siguiente paso es pequeño. Anote las diez preguntas que más le hacen en las llamadas iniciales y compruebe si su sitio web responde a cada una en una página propia y localizable. Si faltan varias, es un indicio sólido de por dónde debería empezar la estructura. De ahí se puede esbozar un primer árbol de páginas antes de que empiece cualquier diseño.

Aquí corresponde un límite honesto: la estructura no sustituye a los contenidos. Un árbol limpio con páginas débiles sigue siendo débil, y la mejor navegación no ayuda si la oferta está formulada de forma poco clara. El trabajo en la estructura suele aclarar primero qué ofrece exactamente la empresa, y para algunos equipos esa es la parte más agotadora, pero también la más útil.

Si quiere abordarlo conjuntamente, revisamos su estructura actual y le decimos con franqueza qué puede quedarse y qué debería reordenarse. A veces basta con dividir una página comodín en dos o tres páginas de servicio y simplificar la navegación. Entonces no es necesaria una reconstrucción completa.