Primero distingue el propósito de la tecnología
Los tipos de páginas web se pueden ordenar por muchas características: su propósito, quién publica, cómo se construyen o si permiten transacciones. Para decidir una inversión, la clasificación más útil comienza por lo que una persona necesita hacer. Aquí agrupamos formatos comerciales por esa tarea; no es una taxonomía técnica universal.
Un sitio puede ser corporativo y autoadministrable al mismo tiempo. Una tienda puede tener un blog. Una plataforma puede incluir páginas públicas muy simples. WordPress, desarrollo a medida y una página estática describen decisiones tecnológicas, no por sí solos el problema de negocio que resuelven. Separar esas capas evita comprar una herramienta antes de entender para qué la usarás.
Ponerlo en prácticaExplora el ejemplo o pliega este espacio para seguir leyendo.
Elige una tarea, encuentra un formato
Es una orientación inicial. Un mismo proyecto puede combinar formatos sin convertirlos en páginas duplicadas.
Landing: una decisión concentrada
Tiene sentido para una campaña, inscripción o lanzamiento con una acción definida.
Una comprobación concretaEscribe oferta, público y siguiente paso antes de diseñar.
Sitio corporativo: orientar y profundizar
Organiza necesidades distintas con contexto, evidencia y contacto pertinentes.
Una comprobación concretaCada URL debería responder una pregunta propia, no repetir la portada.
Catálogo: comparar antes de confirmar
Permite explorar especificaciones y consultar medidas, stock o condiciones sin forzar un pago inmediato.
Una comprobación concretaDefine qué información necesita tu equipo para preparar la cotización.
Tienda: del catálogo al pedido
Añade pago, estados, stock y reglas de entrega que alguien debe mantener.
Una comprobación concretaPrueba también rechazo de pago, devolución y falta de disponibilidad.
Plataforma: acciones, permisos y estados
La complejidad está en lo que cada usuario puede hacer y en las excepciones, no solo en las pantallas.
Una comprobación concretaDibuja quién crea, revisa y autoriza cada paso.
Cinco formatos frecuentes, con ejemplos concretos
Usa esta comparación como un primer filtro. No presupone una cantidad fija de URLs: una institución puede necesitar más contenido que una pequeña tienda y seguir teniendo una operación técnicamente sencilla. La diferencia importante aparece en las acciones y en los datos que el sistema debe administrar.
| Tipo | Tarea principal | Ejemplo de necesidad |
|---|---|---|
| Landing | Entender una oferta y dar un paso | Inscribirse a un taller |
| Sitio corporativo o institucional | Conocer servicios, experiencia y contacto | Elegir una asesoría o conocer una escuela |
| Catálogo sin compra | Explorar opciones y pedir una cotización | Consultar disponibilidad de equipos técnicos |
| Tienda online | Elegir, pagar y seguir un pedido | Comprar un producto con despacho |
| Plataforma o portal | Operar con usuarios, datos y reglas | Gestionar solicitudes con permisos distintos |
Cuándo una landing basta y cuándo necesitas varias páginas
Si lanzas un único taller, puedes reunir programa, docente, fecha, condiciones e inscripción en una landing. Pero si ofreces formación a empresas, cursos abiertos y asesorías individuales, cada público puede necesitar una explicación distinta. En ese caso, una portada que derive a páginas de servicio suele ordenar mejor la conversación.
Antes de sumar una URL, escribe la pregunta exclusiva que responderá. «Servicios» y «Soluciones» no necesitan dos páginas si contienen exactamente lo mismo. En cambio, «capacitación para equipos» puede justificar una URL propia si cambia el alcance, quién compra, cómo se cotiza y qué evidencia resulta relevante.
Mostrar productos no es lo mismo que vender online
Un catálogo permite encontrar productos, comparar especificaciones y consultar. Una tienda añade carrito, pago, estados del pedido y reglas de entrega. Esas funciones afectan al equipo: alguien debe mantener disponibilidad, preparar pedidos y resolver anulaciones o devoluciones. Un botón de compra no crea esa capacidad por sí solo.
Piensa en una empresa que fabrica muebles a pedido. Si cada mueble exige confirmar medidas, materiales y traslado, quizá convenga un catálogo con cotización guiada antes que un pago inmediato. Para vender repuestos estandarizados con precio y stock conocidos, el ecommerce puede evitar intercambios manuales innecesarios. Elige según la operación que puedas cumplir.
Cuándo aparecen requisitos de plataforma
Hay lógica propia cuando el sitio debe aplicar reglas particulares: un cliente ve solo sus documentos, una persona aprueba solicitudes o el precio depende de contratos y permisos. Estas necesidades merecen un mapa de usuarios, acciones y datos antes de calcular pantallas. No todo requiere programar desde cero, pero tampoco todo cabe responsablemente en un formulario.
Por ejemplo, un portal de solicitudes podría distinguir quien crea, quien revisa y quien autoriza. La misma pantalla se ve distinta según el rol, y cada cambio debe quedar registrado. La complejidad está en los estados y las excepciones. Dibujar solo una portada y un panel no permite estimar ese trabajo con seriedad.
Un blog y un CMS son decisiones complementarias
Un blog sirve para publicar contenidos que responden preguntas o documentan conocimiento. Necesita una persona responsable, temas con sentido y capacidad para mantener lo publicado. Abrirlo para que la web «se vea completa» suele dejar artículos sin continuidad. Puede añadirse cuando exista una función editorial clara.
Un CMS es el sistema que permite administrar contenido. Define qué podrás modificar: textos, imágenes, productos o estructuras más amplias. Autoadministrable no significa que cualquier elemento visual deba ser editable sin límites. Si los cambios serán escasos, una gestión delegada también puede ser válida; lo importante es acordar tiempos, responsabilidades y costos.
Haz estas preguntas antes de solicitar un presupuesto
Describe una jornada real del visitante y otra del equipo. Qué busca, qué necesita revisar, qué envía o compra y quién continúa el trabajo. Después anota qué pasaría si falta stock, si un pago se rechaza o si una persona pide corregir sus datos. Las excepciones ayudan a precisar el alcance.
Con ese mapa, escoge el formato más pequeño que resuelva bien la necesidad actual y documenta qué quedará para otra fase. Reducir el inicio no significa bloquear el crecimiento. Significa no mantener hoy funciones que nadie utilizará y reservar el presupuesto para contenido, pruebas y operación.
- ¿Qué acción principal debe resolver el visitante?
- ¿Hay varios servicios con dudas y públicos diferentes?
- ¿Necesito cobrar ahora o primero confirmar una cotización?
- ¿Quién actualizará el contenido y atenderá las solicitudes?
- ¿Qué reglas o integraciones no resuelve una herramienta estándar?