Qué ocurre entre la decisión y la publicación: los pasos de un proyecto web

El contrato está firmado, el pago a cuenta está hecho, y entonces se instala el silencio. La empresa espera a que aparezca el sitio web, el desarrollador espera los textos y las fotografías, y ninguno de los dos piensa que está esperando exactamente la misma semana, de modo que al cabo de un mes las dos partes están insatisfechas y ninguna ha hecho nada mal; simplemente nadie había dejado por escrito quién entrega qué y hasta qué fecha.

Este artículo trata de lo que ocurre entre la decisión y la publicación, y sobre todo del reparto del trabajo entre las dos partes, porque eso es lo que decide el plazo con mucha más frecuencia que la velocidad del desarrollo o la tecnología elegida. De los errores que cometen los clientes hemos escrito aparte, en el artículo sobre diez errores al encargar el desarrollo de un sitio web, y aquí no los repetimos. Tampoco hay aquí precios ni una comparación entre hacerlo uno mismo y encargarlo, porque ambos son temas de otros artículos; se trata solo de la secuencia y de lo que hay que preparar en cada paso.

El descubrimiento no es el inicio de la construcción

Casi todo proceso de desarrollo empieza con una fase llamada descubrimiento o investigación, y precisamente esta fase es la que se entiende mal con más frecuencia, porque el cliente la trata como un trámite antes del trabajo real. Nielsen Norman Group, que usa el concepto de forma profesional, lo define como una fase preparatoria en la que se investiga el propio problema y su contexto, se formula qué es resoluble y se reúnen pruebas suficientes para saber qué hacer después, y subraya de forma expresa que en el descubrimiento no se comprueban soluciones.

En el sector público esta idea está formalizada con más rigor, porque la guía de servicios digitales del Gobierno británico distingue cinco fases —descubrimiento, alfa, beta, puesta en servicio y retirada del servicio— y del descubrimiento dice, simplemente, que en esa fase no se empieza a construir el servicio. Al final de la fase el equipo decide si sigue adelante o se detiene, y la propia guía no impone una duración fija, aunque indica que en la práctica esta fase suele durar de cuatro a ocho semanas.

Aquí hay que hacer de inmediato una salvedad, porque de lo contrario se forma una imagen equivocada: esa guía describe el ciclo de vida de un servicio digital del Estado, no el sitio web de diez páginas de una empresa, y trasladar sus plazos a un proyecto de desarrollo ordinario sería engañoso. Lo valioso es el principio, no el calendario: antes de construir hay una fase cuyo objetivo es entender el encargo, y el resultado de esa fase puede ser también la decisión de no construir en absoluto.

En un proyecto práctico esta fase suele tomar la forma de una conversación sobre procesos, roles de usuario y alcance, y su resultado es un plan por escrito, no un boceto de diseño, aunque el cliente a menudo quiera ver precisamente lo segundo. Para el cliente se siguen de ahí dos consecuencias directas, y la primera es que, sin un resultado escrito del descubrimiento, más adelante no hay con qué comparar lo que se construyó, de modo que una disputa sobre el alcance se queda sin prueba para ninguna de las dos partes. La segunda es que precisamente en esta fase cambiar de idea es barato, mientras que, una vez empezada la construcción, cada cambio cuesta también lo que ya está construido y habrá que rehacer.

El prototipo es el lugar más barato para cambiar de idea

Entre el plan y la construcción hay una fase que los clientes a veces consideran un gasto superfluo, y es exactamente la fase que más a menudo ahorra dinero. Un prototipo es una versión clicable del sitio sin el código real, en la que se pueden recorrer los caminos principales y ver dónde falta algo, y su único objetivo es permitir cambiar de idea mientras cambiar de idea todavía es barato.

La guía del Gobierno británico formula esta idea sin contemplaciones, al escribir de la fase alfa que hay que contar con que todo el código escrito en esa fase y una gran parte de las ideas comprobadas se tirarán al final de la fase, y eso no contradice un buen trabajo, sino que es su sentido: tirar un prototipo es barato, tirar un sistema ya construido no lo es. En la escala de un sitio web de empresa el mismo principio funciona en un volumen menor, y precisamente por eso preparamos el prototipo antes de la primera línea de código de producción.

Para el cliente se sigue de ahí un requisito práctico que conviene decir en voz alta: aprobar el prototipo no es marcar una casilla de trámite, sino el único momento en el que los cambios cuestan solo tiempo, de modo que precisamente entonces conviene sentar a la mesa a las personas que más adelante dirán que nadie les preguntó nada. Después de aprobado el prototipo, cada conversación de ese tipo ya cuesta lo construido.

Lo segundo que en esta fase merece la pena es el contenido en borrador, porque un prototipo con texto de relleno se aprueba con facilidad y después se descubre que los textos reales no caben, o que una sección a la que se había destinado un párrafo necesita en realidad tres. Si los textos aún no están listos, en el prototipo conviene incluir al menos borradores de una longitud aproximadamente correcta, porque la longitud cambia el diseño más que cualquier color.

La mayor parte de la espera ocurre del lado del cliente

El plazo de un proyecto lo marca casi nunca la velocidad del desarrollo, sino lo rápido que el cliente entrega el contenido, y en nuestra experiencia esa es la causa más frecuente de retraso. En el sector no hay un estudio independiente con metodología y fecha, así que lo decimos como experiencia propia y no fingimos que detrás haya porcentajes.

Aquí conviene hacer otra salvedad, porque de lo contrario esta sección sonaría a echar la culpa a otro: en el sector público la producción de contenidos es una profesión aparte y un rol de equipo, y en la guía del Gobierno el diseñador de contenidos figura entre las competencias necesarias, pero de ahí no se sigue que en un proyecto de desarrollo ordinario los textos los escriba el desarrollador. Quién los escribe es una cuestión de acuerdo, y la única respuesta incorrecta es que nadie lo haya aclarado antes de empezar el trabajo.

En concreto, del lado del cliente suele haber cinco entregas, y a cada una conviene ponerle ya en el contrato una fecha concreta, no dejarla en una mera conversación. La primera son los textos, y son la más pesada de todas, porque no se pueden escribir en una tarde y suele escribirlos alguien para quien escribir no forma parte del trabajo principal y tiene que encajarlo entre el resto de obligaciones. La segunda son las fotografías y los logotipos en formato vectorial, la tercera son los accesos a los sistemas existentes si hay que trasladar algo de ellos, la cuarta son las aprobaciones en puntos determinados del proyecto, y la quinta, que no es un documento sino una persona, es un único aprobador que en nombre de la empresa puede decir que sí.

Esta quinta es la que más a menudo falta, y su ausencia cuesta más que cualquier complicación técnica: un proyecto en el que la aprobación la da un comité se alarga no porque alguien trabaje mal, sino porque cada aprobación exige una reunión, las reuniones son cada dos semanas, y entre ellas el trabajo simplemente se para. Si en la empresa hay varias partes interesadas, la solución correcta no es intentar dejarlas fuera, sino acordar quién de ellas es el decisor final y en qué plazo se espera la respuesta.

En España no hay una norma equivalente que nombre al titular de un organismo como responsable del contenido de su sitio web oficial. El Real Decreto 1112/2018, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público, obliga al organismo, no a un cargo concreto. A una empresa privada eso no le vincula, pero la idea es la misma y se puede asumir de forma voluntaria: la responsabilidad del contenido corresponde al cliente, y hay que asignársela a una persona concreta, con nombre y apellidos.

Las imágenes son una cuestión de derechos, no de archivos

Las fotografías son el punto en el que los clientes actúan con la mejor intención y aun así generan un riesgo, porque se da por hecho que el archivo que está en el ordenador es también el archivo que se puede usar; en la Ley de Propiedad Intelectual la fotografía es una obra protegida, la propiedad intelectual corresponde al autor por el solo hecho de su creación, sin registro alguno, y el autor es siempre la persona natural que tomó la imagen.

De ahí se sigue una conclusión que sorprende a casi todas las empresas: el pago de una sesión fotográfica no significa por sí mismo que el cliente haya adquirido los derechos de explotación. El fotógrafo sigue siendo el autor, los derechos morales, entre ellos el de ser nombrado, son irrenunciables e inalienables, y los derechos de explotación solo pasan por licencia o por cesión, de modo que, para una empresa que planea usar las fotografías en el sitio web, en las redes sociales y en imprenta, eso significa que en la licencia o en la cesión tienen que enumerarse exactamente esos modos de explotación.

Con los bancos de imágenes ocurre exactamente lo mismo, solo que allí las condiciones están escritas con claridad y en público, así que se pueden leer antes de comprar: la Licencia estándar de Shutterstock concede un derecho no exclusivo e intransferible a usar la imagen, también en sitios web, y en la misma página se indica que el cliente no obtiene ni la propiedad ni derechos exclusivos. Allí mismo hay restricciones que se suelen incumplir sin querer: la imagen no se puede ceder a terceros, no se puede usar como logotipo o marca, y las imágenes marcadas como de uso exclusivamente editorial no se pueden usar con fines comerciales. Una empresa que ha comprado una Licencia estándar ha adquirido el derecho a usar la imagen en el sitio, no un archivo que pueda entregar al desarrollador como cosa propia.

Hay otro caso que casi siempre se entiende al revés. El artículo 35.2 de la Ley de Propiedad Intelectual permite reproducir, distribuir y comunicar libremente, por medio de pinturas, dibujos, fotografías y procedimientos audiovisuales, las obras situadas de forma permanente en parques, calles, plazas u otras vías públicas. El precepto no limita ese uso a fines personales, informativos o no comerciales, de modo que la fotografía de la fachada de un edificio o de una escultura situados de forma permanente en la vía pública, publicada en el sitio web de una empresa, queda cubierta. No cubre el interior de un edificio, ni las obras colocadas de forma temporal, ni una reproducción tridimensional de la obra.

Por último, las personas que aparecen en las imágenes son una cuestión de datos personales, no solo de cortesía: según el Reglamento general de protección de datos, la fotografía de una persona identificable es un dato personal, y la base jurídica puede ser el consentimiento o un contrato; el consentimiento ha de ser libre, específico, informado e inequívoco. Lo esencial en la práctica es que el consentimiento se puede retirar, y tras la retirada las imágenes han de desaparecer del entorno público, de modo que las fotografías del equipo en el sitio web hay que organizarlas de forma que un empleado que se marche no se convierta en un problema.

El entorno de preproducción y el error que se comete con buena intención

Antes de publicar, el trabajo transcurre en un entorno aparte, y hace falta por una razón sencilla: el cliente tiene que ver una página real en un navegador real, no una imagen de una herramienta de diseño, y los errores hay que detectarlos en un sitio donde no los vean los clientes. La única pregunta es cómo se cierra ese entorno, y precisamente aquí se comete un error que parece correcto.

La solución extendida es escribir una regla Disallow en el archivo robots.txt, y no hace lo que la gente cree, porque la documentación de Google lo dice con claridad: este archivo indica a los rastreadores a qué direcciones pueden acceder, y sirve sobre todo para que el sitio no se sature de solicitudes, pero no es un mecanismo para impedir que una página aparezca en Google. Para que una página no figure en los resultados de búsqueda hay que usar una directiva noindex o proteger el entorno con contraseña.

A continuación viene el detalle por el que los dos métodos juntos funcionan peor que cada uno por separado. La directiva noindex solo funciona si la página se puede rastrear, porque el rastreador tiene que leerla; si la página está bloqueada en el archivo robots.txt, el rastreador no verá nunca esa directiva, y la página puede seguir apareciendo en los resultados, por ejemplo si hay enlaces hacia ella desde otros sitios; además, Google no admite en absoluto una directiva noindex en el archivo robots.txt.

Hay también una segunda razón por la que esto no es un problema teórico: si el entorno de preproducción contiene el mismo contenido que el sitio terminado, el buscador puede tomar precisamente ese entorno por la versión principal y mostrarlo en los resultados en lugar de su sitio, lo que significa que el visitante llega a una página inacabada con datos de prueba. Este error es difícil de notar, porque el propio sitio funciona sin tacha y el problema solo se ve en los resultados de búsqueda.

La respuesta práctica es por tanto sencilla, y conviene pedirla de forma expresa: proteja el entorno de preproducción con una contraseña. Es la única solución que, con independencia del comportamiento de los rastreadores, garantiza que un sitio inacabado no aparece en ninguna parte, y al mismo tiempo elimina el segundo riesgo, en el que se piensa menos: que un entorno de preproducción con el mismo contenido pueda tomarse por la versión principal y empiece a competir con el sitio real.

Qué decisiones, después de publicar, salen más caras

La mayor parte de las decisiones de un proyecto web se pueden cambiar también después de publicar, y conviene decirlo con claridad, porque los clientes a menudo se preocupan precisamente de las cosas que después se cambian con más facilidad. Los colores, el diseño, la plantilla, los textos e incluso la posición de las páginas en el menú se pueden cambiar prácticamente en cualquier momento, y eso cuesta solo horas de trabajo, no una reconstrucción, pero hay dos cosas que sí son distintas, y precisamente sobre esas conviene pensar antes de publicar, mientras el cambio aún no cuesta nada.

La primera es la estructura de direcciones, y se convierte en una decisión en el momento en que las páginas están indexadas y hacia ellas apuntan enlaces ajenos, porque a partir de entonces cambiar las direcciones ya no es una elección visual, sino un traslado del sitio, que Google describe como un procedimiento aparte, con sus propios requisitos. Hay que usar redirecciones permanentes del lado del servidor y conservarlas al menos un año; Google advierte además de no cambiar de una vez las direcciones, el sistema de gestión de contenidos y el diseño, y para un sitio web de empresa ordinario recomienda trasladar todas las direcciones de una sola vez, no por partes. En la misma página hay una nota útil que reduce el miedo: las redirecciones permanentes no provocan por sí mismas una pérdida de PageRank, aunque las posiciones pueden oscilar durante un tiempo.

La segunda es el propio dominio, porque un cambio de dominio es el mismo traslado con todos sus requisitos, solo que a mayor escala, y se le añade todo lo que ya está impreso en tarjetas de visita y papel de carta. Sobre a nombre de quién hay que registrar el dominio hemos escrito en el artículo sobre diez errores al encargar el desarrollo de un sitio web, y aquí no lo repetimos; aquí solo conviene decir que la elección del dominio es una de las pocas decisiones que más adelante cambiar cuesta más que acertar a la primera.

Hay un detalle de procedimiento que conviene conocer para no pedirlo sin necesidad: la solicitud de cambio de dirección en Search Console se presenta solo si cambia el dominio o el subdominio; para pasar de una conexión insegura a una segura, o para elegir entre una dirección con prefijo y sin él en el mismo dominio, no está prevista, y ahí bastan las redirecciones correctas. Para una empresa eso significa que la mayor parte de los cambios se resuelven del lado del servidor, no en un formulario.

En la práctica se sigue de ahí una recomendación antes de publicar: si el sitio antiguo ya existe y tiene visitantes que llegan desde los buscadores, entonces la lista de direcciones con redirecciones hacia las nuevas hay que prepararla antes de la publicación, no después de que alguien note la caída de visitas. Esta lista es también uno de esos trabajos que el cliente puede preparar él mismo y que, si nadie la prepara, después de publicar se convierte en una semana de trabajo de búsqueda.

Accesibilidad: para quién es una obligación y para quién no

Para los organismos del sector público la accesibilidad es una obligación desde hace varios años; para una empresa privada, solo si presta un servicio enumerado en la ley, con más frecuencia el comercio electrónico, y no es una microempresa. Un sitio web informativo que no vende nada no entra en esa lista. En el mercado se confunden a menudo estas dos normas, y ese error cuesta.

La primera se refiere al sector público, y está en vigor desde hace varios años, así que para los organismos no es una novedad. La Directiva de la Unión Europea sobre la accesibilidad de los sitios web del sector público la transpone en España el Real Decreto 1112/2018, que exige respetar cuatro principios —que los contenidos sean perceptibles, operables, comprensibles y robustos— y publicar una declaración de accesibilidad aparte. Esta regulación vincula a los organismos y no se aplica a una empresa privada, aunque en el mercado a veces se ofrezca como un requisito general.

La segunda es más reciente, y precisamente ella genera la mayor parte de los malentendidos, porque la fecha de entrada en vigor se ha anunciado mucho y el alcance no: el Acta Europea de Accesibilidad la transpone en España el título I de la Ley 11/2023, de 8 de mayo, que es aplicable desde el 28 de junio de 2025. Eso no significa que a partir de esa fecha cada sitio web de empresa tenga que cumplir un estándar de accesibilidad, y precisamente esta afirmación demasiado amplia es la que más se repite en el mercado, a veces junto con la oferta de resolverlo.

La ley se aplica a una lista concreta de servicios, no a cualquier sitio, y en ella entran los servicios de comunicaciones electrónicas, el acceso a los servicios de comunicación audiovisual, determinados elementos del transporte de viajeros por aire, autobús, ferrocarril y vías navegables, los servicios financieros a consumidores enumerados, los libros electrónicos y los servicios de comercio electrónico. La ley española añade además los sitios y aplicaciones de consumo de electricidad, agua y gas, los de agencias de viajes y operadores turísticos, y las redes sociales. Un sitio web informativo de empresa que no vende nada y no es un banco, un operador de transporte, una plataforma de libros, una comercializadora, una agencia de viajes ni una red social no entra en esa lista.

Hay también una excepción para las empresas pequeñas, y hay que formularla con precisión, porque a menudo se cuenta demasiado amplia. El comerciante que emplea a menos de diez personas y cuyo volumen de negocio anual no supera los dos millones de euros o cuyo balance anual no supera los dos millones de euros, y que presta un servicio incluido en el ámbito de la ley, está exento de la obligación de cumplir los requisitos de accesibilidad de los servicios. La excepción se refiere a los servicios; las obligaciones relacionadas con los productos son más ligeras para las microempresas, pero no quedan anuladas, de modo que la frase de que las microempresas están exentas de la ley no es correcta.

La conclusión práctica para el cliente es breve: si usted monta una tienda online y no es una microempresa, entonces los requisitos de accesibilidad hay que escribirlos ya en el pliego técnico, porque más adelante significan rehacer el trabajo. Si monta un sitio informativo, entonces una obligación jurídica, lo más probable, no existe, pero sigue siendo un argumento a favor de que la página se pueda usar con el teclado y se pueda leer con un lector de pantalla, porque una parte de sus clientes los usa con independencia de la ley.

Cuánto tiempo lleva todo esto

La pregunta del plazo es aquella a la que el cliente quiere respuesta en primer lugar, y es también aquella a la que más cuesta dar una respuesta honesta. Los plazos publicados en el sector casi siempre salen de las propias páginas de los desarrolladores, donde sirven como promesa de rapidez, así que no se pueden usar como un dato independiente, y un estudio independiente con metodología no lo hemos encontrado.

Por eso es más correcto hablar de lo que marca el plazo que buscar una cifra media que, de todos modos, no sirve para ningún proyecto concreto: el plazo lo marcan el alcance, la rapidez de las aprobaciones y lo listo que esté el contenido, y en los dos últimos de estos tres la influencia decisiva está del lado del cliente. Un proyecto en el que los textos están listos antes de empezar y las decisiones las toma una sola persona discurre de forma considerablemente más rápida que un proyecto del mismo alcance sin esas dos condiciones, y esa es una diferencia que se puede medir en semanas.

Nuestro propio plazo publicado en la página de desarrollo WordPress es de cuatro a diez semanas, y se refiere a un sitio web de empresa ordinario, mientras que para proyectos más complejos es más largo, y para una tienda online todavía más, pero para un proyecto concreto el único plazo útil es el que se sigue del alcance, no de una media.

Hay otra forma de mirar esta pregunta, y para el cliente suele ser más útil que cualquier cifra: pregunte al desarrollador no cuánto tardará, sino qué semanas dependen de usted y cuáles de él. La respuesta a esa pregunta se puede comprobar, y muestra de inmediato cuánto del plazo controla usted mismo.

Y una cosa más, que influye en el plazo más de lo que parece, es el crecimiento del alcance a lo largo del trabajo: cada sugerencia nueva es, por separado, pequeña y justificada, pero juntas desplazan la fecha de entrega, y ocurre sin que se note, porque ninguna de ellas parece nunca una decisión de alargar el proyecto. Lo único que ayuda frente a eso es el acuerdo de que los cambios fuera del alcance inicial se anotan aparte, junto con su efecto sobre el plazo, y no se incluyen en silencio.

Qué acordar antes de que empiece el trabajo

Antes de la primera línea de factura conviene hablar y dejar por escrito un calendario de contenidos con fechas: quién escribe los textos, hasta qué fecha están en manos del desarrollador y qué ocurre si se retrasan, porque sin este punto el retraso siempre parece culpa del desarrollador.

Lo segundo es el origen de las imágenes y los derechos, es decir, de dónde salen las fotografías, qué licencia tienen, si en la licencia se menciona el uso precisamente en el sitio y si las personas que aparecen han dado un consentimiento que más adelante pueden retirar. Lo tercero es un único aprobador con nombre y apellidos, y un acuerdo sobre en cuántos días laborables se espera la respuesta a una petición de aprobación, porque sin plazo una aprobación no es una magnitud planificable.

Lo cuarto es un entorno de preproducción protegido con contraseña, no con una regla Disallow en el archivo robots.txt, y lo quinto es una lista de redirecciones de las direcciones antiguas a las nuevas, si el sitio antiguo ya existe y tiene visitantes. Lo sexto es la pregunta de la accesibilidad, cuya respuesta depende de lo que hace su sitio, y que es mucho más barato plantear en el momento de redactar el pliego técnico que después de la entrega.

Esta lista conviene recorrerla en una sola conversación, no a trozos, porque precisamente en conjunto muestra qué parte tan grande del proyecto depende del cliente, y suele ser mayor de lo que el cliente esperaba. Ninguno de estos requisitos es caro, y ninguno pide conocimientos técnicos; solo piden que alguien los plantee antes de empezar el trabajo.

Y lo séptimo, que no es técnico pero decide más que los otros seis: un acuerdo sobre cuál es el alcance mínimo con el que se puede publicar el sitio. Un proyecto en el que se publica solo cuando está todo listo suele no publicarse nunca, mientras que un proyecto con un alcance mínimo claro se publica a tiempo y después crece. Si quiere que mantengamos esta conversación con usted, escríbanos.