# websitedevelopment.biz — texto completo > El texto completo de cada guía en este idioma, para que un motor de respuestas pueda leer el catálogo en una sola petición. Nada de esto falta en las páginas visibles. ## Cuándo rediseñar su sitio web (y cuándo no) https://websitedevelopment.biz/es/guides/cuando-redisenar-la-web Actualizado el 2026-08-07 · Mantenimiento Los rediseños se lanzan a menudo por el motivo equivocado —el sitio parece anticuado a quienes lo ven a diario— y conllevan riesgo real: una reconstrucción completa reinicia las señales de búsqueda acumuladas, tira el conocimiento sobre conversión y a menudo sustituye un problema conocido por uno desconocido. Esta guía cubre qué justifica de verdad un rediseño, qué no, y la vía incremental que da mejores resultados en casi todos los sitios. ### Motivos que justifican un rediseño Son problemas estructurales que no se arreglan cambiando páginas, y eso es lo que los convierte en motivos de rediseño en vez de motivos de mejora. - La plataforma está al final de su vida o ya no recibe actualizaciones de seguridad. - El sitio no es adaptable y no se puede hacer que lo sea sin reconstruirlo. - La estructura ya no encaja con el negocio: vende algo que la arquitectura de información no puede expresar. - Editar es imposible sin desarrollo, así que el contenido está caducado por defecto. - El rendimiento es estructuralmente malo por cómo se construyó, no por unas cuantas imágenes grandes. - Los fallos de accesibilidad están en los propios componentes y no se pueden parchear. - Una fusión o un cambio de marca cambia el nombre, no solo los colores. Fíjese en lo que no está en esta lista: «parece anticuado». Eso suele ser un proyecto de restilizado, y los restilizados cuestan una fracción y no conllevan casi ninguno de los riesgos. ### Motivos que no lo justifican Cada uno tiene un arreglo más barato y de menor riesgo que aborda el problema real. | «Parece anticuado» | Estilo visual | Restilizar: tipografía, color, espaciado | | «El tráfico está cayendo» | Problema de contenido o técnico | Diagnostique primero; un rediseño suele empeorarlo | | «Las conversiones son bajas» | Páginas concretas o un formulario | Probar cambios en esas páginas | | «Un competidor ha relanzado» | Nada medible | No es un motivo | | «Nueva dirección de marketing» | Titularidad, no la web | Revisar juntos los datos primero | | «Tiene tres años» | La edad no es un defecto | Arreglar lo que esté mal de forma medible | ### Por qué los rediseños completos suelen perder tráfico Un rediseño completo cambia estructura, contenido, URLs y plantillas a la vez. Si el rendimiento cae, no puede saber qué cambio lo causó, y si mejora, tampoco. - Los cambios de URL pierden señales acumuladas salvo que cada redirección esté bien mapeada. - El contenido reescrito «para ser más conciso» elimina con frecuencia justo el texto que posicionaba. - Las plantillas nuevas pueden perder enlaces internos, datos estructurados o metadatos que tenían las viejas. - Los cambios de diseño pueden reducir la conversión de formas que solo se ven semanas después. - Todo cambia a la vez, así que atribuir después es adivinar. Si un rediseño es realmente necesario, conserve la estructura de URLs y el contenido que posiciona donde pueda. Cambie la apariencia y el código, no las direcciones. ### La alternativa incremental Para casi todos los sitios, una serie de cambios dirigidos supera a una reconstrucción: es más barata, es medible y cada paso se puede revertir. - Mida primero: analítica, Core Web Vitals, Search Console y un puñado de sesiones de usuario. - Arregle rendimiento y accesibilidad en las plantillas existentes. Suelen pagarse solos. - Reescriba las páginas que reciben tráfico pero no convierten, de una en una. - Restilice: tipografía, color, espaciado. Esto resuelve «parece anticuado» por una fracción del coste. - Sustituya plantillas individuales una a una, conservando sus URLs. - Mejore la experiencia de edición para que el contenido deje de caducar. - Vuelva a medir tras cada paso, para saber qué cambio hizo qué. Q: ¿Cada cuánto debe rediseñarse un sitio web? A: No hay intervalo correcto. Un sitio bien mantenido y mejorado de forma incremental puede funcionar muchos años sin reconstruirse. El detonante debería ser un problema estructural que no puede arreglar dentro de la construcción actual, no una fecha en el calendario. Los sitios rediseñados cada tres años por norma suelen perder terreno cada vez. Q: ¿Un rediseño mejorará mi SEO? A: No por sí mismo, y puede perjudicar fácilmente. Lo que ayuda es lo que a veces incluye un rediseño: páginas más rápidas, mejor estructura, mejor contenido. Esas mejoras se pueden hacer sin rediseñar, con menos riesgo. Si el objetivo es el rendimiento en búsqueda, diagnostique la causa real antes de comprometerse con una reconstrucción. Q: ¿Debo conservar mis URLs en un rediseño? A: Siempre que le sea posible. Conservar las URLs elimina el mayor riesgo de un relanzamiento. Si tienen que cambiar —una estructura realmente rota o un cambio de dominio—, mapee cada URL antigua a una nueva concreta con un 301 y conserve esas redirecciones indefinidamente. Q: ¿Cuánto tarda un rediseño? A: Similar a una construcción nueva, y a menudo más por la migración: de dos a cinco meses para un sitio mediano. Rara vez sale más barato que empezar de cero una vez cuenta la migración de contenido, el mapeo de URLs y replicar el comportamiento existente, lo que sorprende a casi todo el mundo que espera un descuento por tener ya un sitio. ## Monitorización web: enterarse antes que sus clientes https://websitedevelopment.biz/es/guides/monitorizacion-de-sitios-web Actualizado el 2026-08-07 · Mantenimiento La monitorización de disponibilidad responde a una pregunta: ¿responde la portada? Casi todos los fallos reales son más silenciosos que eso. El sitio está en pie y el formulario de contacto lleva tres semanas fallando, o la caja funciona para todos menos para quienes usan un método de pago. Esta guía cubre qué monitorizar, cómo fijar umbrales que signifiquen algo y cómo mantener las alertas creíbles. ### Más allá de «¿está en pie?» Los fallos que cuestan dinero suelen ser parciales. Monitorice los resultados que le importan, no solo que el servidor responda. | Disponibilidad HTTP | Servidor caído, fallo de DNS | Cada 1–5 minutos | | Comprobación de transacción | Formulario roto, caja rota | Cada 15–60 minutos | | Tasa de error | Excepciones subiendo tras un despliegue | Continua | | Caducidad del certificado | La clásica caída del domingo por la mañana | Diaria, alerta 30 días antes | | Caducidad del dominio | La peor caída posible | Diaria, alerta 60 días antes | | Core Web Vitals | Degradación lenta que nadie nota | Semanal | | Cobertura de Search Console | Páginas cayéndose del índice | Semanal | | Tamaño de disco y base de datos | Crecimiento silencioso hacia un límite duro | Diaria | | Éxito de las copias | Copias que dejaron de ejecutarse hace meses | Diaria | Una transacción sintética que envía un formulario real a una dirección de prueba es el monitor de mayor valor para casi cualquier sitio de empresa. Los formularios rotos son invisibles y caros. ### Fijar umbrales que signifiquen algo Un monitor que alerta ante cualquier hipo enseña a la gente a ignorarlo, y entonces no funciona cuando importa. Los umbrales deberían reflejar lo que de verdad le haría actuar. - Exija dos o tres fallos consecutivos antes de alertar, desde más de una ubicación. - Alerte sobre la tasa de error en vez de sobre errores individuales: un solo 500 es ruido, un cambio de tasa es señal. - Fije alertas de rendimiento sobre una tendencia de días, no sobre una medición lenta. - Separe gravedades: sitio caído va a un teléfono; una página lenta va a un resumen semanal. - Dirija las alertas a una persona, no a un buzón compartido que nadie asume. - Revise cada alerta que se disparó: si no requirió acción, cambie el umbral o borre el monitor. ### Qué hacer cuando salta una alerta Tener un orden de operaciones escrito convierte un incidente de improvisación en procedimiento, lo que importa sobre todo cuando quien está de guardia no es quien construyó el sitio. - Confirme que es real: cargue el sitio usted desde otra red. - Compruebe primero lo obvio: ¿se desplegó algo, caducó un certificado, informa el proveedor de un incidente? - Publique una actualización de estado si hay clientes afectados. El silencio es peor que una mala noticia. - Restaure el servicio antes de diagnosticar. Revierta el despliegue y luego investigue con calma. - Escriba qué pasó, por qué y qué lo habría detectado antes. - Añada el monitor que lo habría detectado. Así es como crece bien la lista anterior. El resultado más útil de un incidente es un monitor nuevo y una forma menos de que vuelva a pasar en silencio. ### Valores por defecto sensatos para un sitio pequeño No necesita una plataforma de observabilidad. Para casi cualquier sitio de empresa este conjunto basta y se configura en una tarde. - Comprobación de disponibilidad en la portada y en una página profunda, cada cinco minutos, desde dos ubicaciones. - Un envío sintético de formulario a diario, a una dirección que lea una persona. - Alertas de caducidad de certificado y de dominio, con mucha antelación. - Alertas de errores de servidor desde la aplicación, con un umbral de tasa. - Un correo semanal con Core Web Vitals y cobertura de Search Console. - Una confirmación diaria de que la copia se ejecutó y su tamaño parece normal. Q: ¿Cada cuánto debo comprobar la disponibilidad? A: Cada uno a cinco minutos es lo habitual, desde al menos dos ubicaciones geográficas para que un problema de red en un nodo de monitorización no le despierte a las 3 de la madrugada. Comprobaciones más frecuentes rara vez cambian el desenlace, porque el tiempo hasta notarlo es pequeño comparado con el tiempo hasta arreglarlo. Q: ¿Qué disponibilidad debo esperar? A: Un alojamiento compartido decente da alrededor del 99,9 %, que son unas nueve horas de caída al año. Las plataformas gestionadas y las buenas configuraciones en la nube llegan al 99,95 % o mejor. Importa más que la cifra si la caída son minutos dispersos o una única caída larga en horario comercial. Q: ¿Bastan las herramientas de monitorización gratuitas? A: Para la disponibilidad de un sitio pequeño, en general sí: los planes gratuitos cubren un puñado de comprobaciones cada cinco minutos. Lo que suele faltar en los planes gratuitos son las transacciones sintéticas y las comprobaciones de varios pasos, que es justo donde está la monitorización valiosa. Reserve un pequeño presupuesto específicamente para eso. Q: ¿Cómo evito la fatiga de alertas? A: Borre los monitores que nunca han requerido acción, exija varios fallos consecutivos antes de alertar y separe el enrutamiento urgente del informativo. Después revise mensualmente las alertas disparadas. Un canal de alertas que la gente silencia es peor que no tener alertas, porque crea la creencia de que alguien está vigilando. ## Estrategia de copias de seguridad: qué guardar y cada cuánto https://websitedevelopment.biz/es/guides/estrategia-copias-de-seguridad-web Actualizado el 2026-08-07 · Mantenimiento Casi todos los sitios tienen copias de seguridad. Menos tienen copias que se hayan restaurado alguna vez. La diferencia entre ambas cosas se descubre en el peor momento posible, normalmente junto con el descubrimiento de que a la copia le faltaba la base de datos, o los archivos subidos, o las últimas tres semanas. Esta guía cubre qué guardar, cada cuánto, dónde conservarlo y cómo verificar que una restauración funciona de verdad. ### Qué contiene una copia completa Un sitio no es una sola cosa. Que falte cualquiera de estos elementos hace que la restauración sea parcial, y una restauración parcial suele ser peor que ninguna porque parece que funcionó. - Base de datos: contenido, usuarios, pedidos, ajustes. La parte que cambia constantemente. - Archivos subidos: imágenes, documentos, todo lo que hayan añadido usuarios o redacción. - Código de la aplicación: idealmente en control de versiones, que es una forma de copia con historial. - Configuración: variables de entorno, configuración del servidor, tareas programadas, reglas de redirección. - Certificados y registros DNS: baratos de exportar, dolorosos de reconstruir bajo presión. - Ajustes de terceros: URLs de webhook de pago, configuración de correo, claves de API. La configuración es lo que más a menudo falta. Una base de datos y unos archivos restaurados sobre un servidor configurado de otro modo no son el mismo sitio. ### Cada cuánto y cuánto conservar La frecuencia se deduce de una pregunta: ¿cuánto trabajo puede permitirse perder? La retención se deduce de otra: ¿cuánto tardaría en notar un problema? | Sitio de presentación estático | Semanal | Semanal | 30 días | | Sitio de empresa con blog | Diaria | Diaria | 30–60 días | | Sitio de contenido con mucho tráfico | Diaria u horaria | Diaria | 60–90 días | | Tienda online | Horaria o continua | Diaria | Más de 90 días, y guarde archivos mensuales | | Aplicación web | Continua con recuperación a un punto en el tiempo | Diaria | Según su política de datos | La retención importa porque existen problemas de evolución lenta. Una importación corrupta o una intrusión silenciosa pueden pasar semanas sin notarse, y para entonces una rotación de 7 días solo contiene copias malas. ### Dónde guardarlas La regla clásica sigue vigente: tres copias, en dos tipos de soporte, con una fuera de las instalaciones. Adaptada a sitios web significa que la copia debe sobrevivir tanto a que el servidor falle como a que el servidor sea comprometido. - Nunca guarde la única copia en el mismo servidor que el sitio. - Use un proveedor distinto para al menos una copia, para que un fallo del proveedor no se lleve las dos. - Haga al menos una copia inmutable o de escritura única, para que las credenciales que operan el sitio no puedan borrarla. - Cifre las copias en reposo: contienen todo, incluidos datos personales. - Conserve un archivo mensual fuera de la rotación para los problemas de descubrimiento lento. - Documente dónde están y cómo restaurar, en un sitio que no sea solo el propio sitio web. ### Probar: el paso que lo hace real Una copia que nunca ha restaurado es una suposición. Probarla lleva una hora y la convierte en un hecho. - Restaure en un entorno de preproducción aparte, no encima del sitio en línea. - Compruebe que la base de datos se restauró por completo: cuente filas en las tablas que importan. - Compruebe que los archivos subidos están, incluidos los recientes. - Inicie sesión y realice una tarea real: publicar una página, hacer un pedido de prueba. - Cronométrelo. «¿Cuánto tardaría una restauración?» es una pregunta que quiere tener respondida de antemano. - Escriba el procedimiento para que no lo tenga solo quien lo configuró. - Repítalo cada mes y después de cualquier cambio en el alojamiento. Cronometre la restauración. Saber que tarda cuatro horas cambia lo que promete a los responsables durante una caída, y es el dato que nadie tiene cuando lo necesita. Q: ¿Basta con la copia de mi proveedor de alojamiento? A: Es una buena base y una mala estrategia única. Las copias del proveedor suelen tener retención corta, están en la misma infraestructura y se pierden junto con la cuenta si hay una disputa de facturación o un fallo del proveedor. Guarde su propia copia en otro sitio: el coste es pequeño y es la copia que necesitará justo en el escenario en que las del proveedor no ayudan. Q: ¿Cuánto tiempo debo conservar las copias? A: El suficiente para cubrir un problema de descubrimiento lento. Treinta días es un mínimo razonable, noventa es más seguro para una tienda, y un archivo mensual conservado un año cuesta casi nada. Equilíbrelo con las obligaciones de protección de datos: las copias con datos personales también están sujetas a normas de conservación. Q: ¿Necesito copias si mi código está en control de versiones? A: Sí. El control de versiones cubre el código y su historial, y no contiene la base de datos, los archivos subidos ni la configuración del servidor. Ahí viven el contenido y los datos de clientes, que es justo la parte que no se puede recrear volviendo a ejecutar un despliegue. Q: ¿Qué es la recuperación a un punto en el tiempo? A: La capacidad de restaurar la base de datos a cualquier momento, en vez de a la última instantánea programada, lograda archivando de forma continua el registro de transacciones. Importa cuando perder aunque sea una hora de pedidos es inaceptable. Para un sitio de presentación es innecesaria; para una tienda que recibe pedidos de madrugada, compensa la configuración extra. ## Seguridad web: las prácticas que evitan casi todos los incidentes https://websitedevelopment.biz/es/guides/seguridad-web-buenas-practicas Actualizado el 2026-08-07 · Mantenimiento Casi todas las intrusiones en sitios web no son dirigidas. Son escáneres automáticos encontrando una vulnerabilidad conocida en software desactualizado, o una contraseña reutilizada en una cuenta de administración. Defenderse de los ataques corrientes cubre la gran mayoría del riesgo real. Esta guía cubre las prácticas que evitan casi todos los incidentes, aproximadamente por efecto, y qué hacer si un sitio ya está comprometido. ### Las medidas que evitan casi todos los incidentes Por orden de cuánto riesgo eliminan por unidad de esfuerzo. - Mantenga el software al día. La abrumadora mayoría de las intrusiones explotan una vulnerabilidad con parche disponible. Este único punto pesa más que todo lo que viene debajo. - Contraseñas únicas y fuertes más doble factor en cada cuenta de administración, panel de alojamiento, registrador de dominio y cuenta de correo. - Mínimo privilegio. Quien edita no necesita cuenta de administrador. Elimine cuentas cuando la gente se va. - HTTPS en todas partes, con HSTS una vez esté seguro de que todos los subrecursos están disponibles por TLS. - Copias de seguridad probadas, guardadas fuera del servidor. Una copia en la máquina comprometida se cifra junto con todo lo demás. - Restrinja el área de administración por IP donde sea práctico, y limite siempre los intentos de acceso. - Elimine lo que no use. Cada plugin inactivo, tema y instalación vieja es superficie de ataque sin beneficio. Las instalaciones viejas y olvidadas —una copia de pruebas en /antiguo, un blog de prueba en una subcarpeta— son una vía de entrada habitual precisamente porque nadie las actualiza. ### Entrada, salida y las vulnerabilidades clásicas Son responsabilidades del desarrollo y explican casi todas las vulnerabilidades que no son «no actualizó». | Inyección SQL | Lee o destruye su base de datos | Consultas parametrizadas, siempre; nunca concatenación de cadenas | | Cross-site scripting | Ejecuta script del atacante en la sesión de un visitante | Escapar en la salida según el contexto; una Content-Security-Policy estricta | | Cross-site request forgery | Ejecuta acciones como un usuario autenticado | Tokens por sesión en cada petición que cambia estado | | Abuso de subida de archivos | Sube y ejecuta código | Validar el tipo por contenido, guardar fuera de la raíz web, nunca ejecutar | | Control de acceso roto | Los usuarios alcanzan datos que no son suyos | Comprobar autorización en servidor en cada petición, no en la interfaz | | Exposición de datos sensibles | Filtra claves y credenciales | Variables de entorno, nunca en el repositorio | | Server-side request forgery | Hace que su servidor llame a sistemas internos | Lista de permitidos para destinos salientes | ### Configuración y cabeceras Medidas baratas que cierran categorías enteras de problema, y casi todas se aplican en minutos. - Sirva cabeceras de seguridad: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, X-Frame-Options. - Desactive el listado de directorios; asegúrese de que /.git, /.env y los archivos de copia no son accesibles por HTTP. - Desactive la salida detallada de errores en producción: las trazas son reconocimiento para el atacante. - Bloquee el acceso a rutas de administración y configuración desde internet público donde pueda. - Establezca las cookies con HttpOnly, Secure y un valor SameSite adecuado. - Mantenga auditadas las dependencias; una librería vulnerable en su compilación es su vulnerabilidad. - Registre los eventos de autenticación y alerte ante patrones inusuales. ### Si el sitio ya está comprometido Aquí el orden importa. Limpiar archivos antes de rotar credenciales significa que el atacante simplemente vuelve por la misma puerta. - Ponga el sitio fuera de línea o en modo mantenimiento. No lo deje sirviendo malware a los visitantes. - Preserve pruebas: copie los registros y una instantánea de los archivos antes de cambiar nada. - Rote todas las credenciales: alojamiento, base de datos, usuarios de administración, claves de API, correo. Dé por hecho que todas se conocen. - Restaure desde una copia anterior a la intrusión, si puede identificar una con fiabilidad. - Si no puede, reconstruya desde el código fuente e importe solo datos, nunca archivos de origen desconocido. - Parchee la vulnerabilidad que les dejó entrar. Sin este paso repetirá todo el proceso. - Busque persistencia: tareas programadas, usuarios de administración extra, archivos del núcleo modificados, contenido inyectado. - Solicite una revisión en Search Console si el sitio fue marcado, y busque páginas de spam inyectadas. - Notifique a los usuarios afectados si se expusieron datos personales, en muchas jurisdicciones dentro de un plazo legal. Restaurar una copia sin cerrar la vía de entrada es el motivo más común de que un sitio se vea comprometido dos veces en quince días. Q: ¿Basta con un plugin de seguridad? A: Ayuda en algunas cosas —limitar intentos de acceso, vigilar cambios en archivos, un cortafuegos básico— y no sustituye a las actualizaciones, las credenciales fuertes ni el mínimo privilegio. Un sitio con plugin de seguridad y dieciocho meses de actualizaciones sin aplicar no es seguro. Arregle primero lo fundamental y luego añada herramientas. Q: ¿De verdad atacan a los sitios pequeños? A: Constantemente, y no por quién es usted. Los escáneres automáticos prueban cada host alcanzable en busca de vulnerabilidades conocidas; los sitios pequeños resultan atractivos justo porque es menos probable que estén parcheados. Los sitios pequeños comprometidos se usan para spam, páginas de phishing y redirecciones, y por eso el nivel de tráfico de su sitio es irrelevante para el riesgo. Q: ¿Dónde deben guardarse las copias de seguridad? A: En un lugar donde el servidor web no pueda escribir, idealmente con otro proveedor, y con al menos una copia que no puedan borrar las mismas credenciales que operan el sitio. El ransomware y los ataques destructivos apuntan específicamente a las copias accesibles desde la máquina comprometida, que es exactamente el momento en que las necesita. Q: ¿Cuál es la medida de seguridad de mayor valor? A: Aplicar las actualizaciones con prontitud. Es poco vistoso y evita más intrusiones reales que todo lo demás junto, porque los ataques que de verdad ocurren son explotación automatizada de vulnerabilidades conocidas y ya parcheadas. En segundo lugar, el doble factor en las cuentas de administración y de alojamiento. ## Mantenimiento web: qué implica realmente https://websitedevelopment.biz/es/guides/guia-mantenimiento-web Actualizado el 2026-08-07 · Mantenimiento El mantenimiento web es el trabajo que mantiene un sitio seguro, actualizado y funcionando tras el lanzamiento. Es invisible cuando se hace y extremadamente visible cuando no: normalmente como una caída, una intrusión o un formulario que lleva un mes fallando en silencio. Esta guía cubre qué incluye realmente el mantenimiento, cuánto cuesta, qué debe especificar un contrato y cómo verificar que lo está recibiendo. ### En qué consiste el trabajo El mantenimiento se divide en trabajo rutinario planificado y trabajo reactivo cuando pasa algo. Un contrato que solo cubre lo segundo no es mantenimiento, es soporte. | Parches de seguridad | Al publicarse, en días | Las vulnerabilidades conocidas se explotan de forma automática | | Actualizaciones de plataforma y plugins | Mensual, probadas en preproducción | Quedarse atrás hace la actualización más difícil cada mes | | Verificación de copias de seguridad | Prueba de restauración mensual | Una copia sin probar no es una copia | | Monitorización de disponibilidad | Continua | No debería enterarse de una caída por una clienta | | Revisión de registros de error | Semanal | Fallos silenciosos: formularios rotos, pagos fallidos | | Comprobación de rendimiento | Mensual | El peso de página sube en silencio según se añade contenido | | Comprobación de enlaces rotos | Trimestral | Los enlaces externos se pudren a ritmo constante | | Revisión de contenido | Trimestral | Precios caducados y teléfonos muertos cuestan más que los fallos | | Auditoría de dependencias | Trimestral | Las librerías abandonadas hay que sustituirlas antes de que rompan | ### Cuánto cuesta Una cifra útil de planificación es del 10 al 20 % del coste de construcción al año para un sitio con CMS, más para una tienda o una aplicación. Por debajo de eso normalmente está comprando disponibilidad y no trabajo real. | Sitio de presentación pequeño | 50 – 200 $ | Actualizaciones, copias, monitorización de disponibilidad, ediciones menores | | Sitio de empresa mediano | 200 – 800 $ | Lo anterior más pruebas en preproducción, rendimiento y revisión de errores | | Tienda online | 500 – 3.000 $ | Lo anterior más monitorización de pagos y stock, respuesta más rápida | | Aplicación web | Desde 1.500 $ | Lo anterior más gestión de versiones y guardia | Un contrato barato sin informe es difícil de distinguir de no tener contrato. El informe es lo que está comprando de verdad. ### Qué debe especificar un contrato Los contratos vagos provocan disputas justo en el peor momento. Estos puntos deberían estar por escrito antes de firmar. - Exactamente qué tareas rutinarias se realizan y con qué frecuencia. - Objetivos de tiempo de respuesta, separados por gravedad: sitio caído, función rota, cosmético. - Horario de cobertura y qué ocurre fuera de él. - Cuántas horas de cambios se incluyen y si las horas no usadas se acumulan. - Qué cuenta como cambio frente a proyecto nuevo, con ejemplos. - Quién tiene acceso a qué, y cómo se revoca al terminar el acuerdo. - Qué recibe cada mes: un informe de verdad, no una factura. - Plazo de preaviso y qué pasa con sus datos y accesos al final. ### Hacerlo usted mismo Para un sitio pequeño es del todo razonable, siempre que esté planificado y no solo pretendido. Póngalo en un calendario con una persona responsable, porque el mantenimiento hecho «cuando nos acordemos» no se hace. - Semanal: compruebe que el sitio carga, envíe el formulario de contacto, eche un vistazo a los registros de error. - Mensual: aplique actualizaciones primero en preproducción y luego en producción. Verifique que una copia se restaura. - Mensual: revise Search Console por errores de cobertura nuevos y acciones manuales. - Trimestral: pase un comprobador de enlaces, una prueba de rendimiento y un análisis de accesibilidad. - Trimestral: revise el contenido por precios, fechas, nombres de personas y enlaces muertos. - Anual: revise las renovaciones de dominio y certificado, y audite quién sigue teniendo acceso. Ponga recordatorios de calendario a una persona con nombre, no a un equipo. La responsabilidad compartida sobre una tarea recurrente se convierte de forma fiable en responsabilidad de nadie. Q: ¿Qué pasa si me salto el mantenimiento? A: Durante un tiempo, nada visible, que es justo por lo que se salta. Luego ocurre una de tres cosas: un escáner automático explota una vulnerabilidad conocida, actualizar se vuelve imposible porque va varias versiones mayores por detrás, o algo lleva semanas roto y nadie lo notó. Las tres cuestan más de lo que habría costado el mantenimiento. Q: ¿Puedo usar el paquete de mantenimiento de mi proveedor de alojamiento? A: El alojamiento gestionado suele cubrir el servidor, y a menudo las actualizaciones del núcleo de la plataforma y las copias. Rara vez cubre sus plugins, su código propio, sus registros de error o su contenido. Lea qué se incluye; la brecha entre «alojamiento gestionado» y «mantenimiento del sitio» es donde ocurren casi todos los incidentes. Q: ¿Cómo sé que el mantenimiento se está haciendo? A: Pida un informe mensual: qué se actualizó, qué se parcheó, la disponibilidad, los errores encontrados y corregidos y la fecha de la última restauración de copia exitosa. Si un contrato no produce informe, no puede distinguir buen mantenimiento de ninguno, y normalmente se descubre cuál era durante un incidente. Q: ¿Las actualizaciones deben aplicarse automáticamente? A: Los parches de seguridad del núcleo de la plataforma, en general sí: el riesgo de esperar suele superar al de romper algo. Las actualizaciones de plugins y de versión mayor deberían probarse antes en preproducción, porque son las que rompen maquetaciones y código propio. El reparto adecuado depende de cuánto vale el sitio por hora de caída. ## SEO para tiendas online: las prácticas que de verdad importan https://websitedevelopment.biz/es/guides/seo-para-tiendas-online Actualizado el 2026-08-07 · Comercio electrónico El SEO de tienda se diferencia del SEO de contenido en algo importante: el sitio genera URLs por sí solo. Filtros, ordenaciones, variantes y paginación pueden convertir un catálogo de 500 productos en 50.000 páginas indexables, y ahí empiezan casi todos los problemas de SEO de una tienda. Esta guía cubre cómo estructurar una tienda para que posicionen las páginas correctas y las generadas por la máquina se queden fuera del índice. ### Las categorías son sus páginas más valiosas Casi toda la demanda comercial de búsqueda es de categoría y no de un producto concreto: se busca «botas de montaña impermeables» mucho más que un modelo específico. Las páginas de categoría son, por tanto, en las que merece la pena invertir, y suelen ser las más pobres. - Dé a cada categoría texto de verdad: una introducción breve sobre la rejilla y detalle útil debajo. - Ajuste la categoría a cómo busca la gente, no a cómo está organizado su almacén. - Enlace las categorías relacionadas entre sí; una rejilla de productos sin enlaces editoriales es un callejón sin salida. - Mantenga estables las URLs de categoría aunque cambie la gama. La URL sobrevive a los productos que contiene. - Muestre productos suficientes en la parte visible para que la página responda a la consulta de inmediato. Una página de categoría sin texto compite solo con títulos de producto. Por eso las categorías pierden tan a menudo frente a sitios de contenido que analizan esos mismos productos. ### Navegación facetada: la principal fuente de problemas Los filtros multiplican URLs de forma combinatoria. Si se dejan abiertos, consumen presupuesto de rastreo, diluyen señales y llenan el índice de casi duplicados que tardan en irse. | Categoría base | Indexar, autocanónica | | Filtro único con demanda alta (p. ej. marca) | Indexar si hay demanda real y suficientes productos | | Varios filtros combinados | noindex, follow | | Orden de clasificación | noindex, o no crear una URL distinta | | Paginación | Indexar, cada página autocanónica, enlaces rastreables reales | | Resultado de filtro vacío | noindex, y valorar devolver un 404 | | Parámetros de seguimiento | Eliminar, o canonicalizar a la URL limpia | ### Páginas de producto: URLs, variantes y stock Tres decisiones causan aquí casi todos los problemas de página de producto, y las tres son más baratas de cerrar antes de lanzar. - Una URL por producto, no una por ruta de categoría. Un producto en tres categorías no debería existir en tres URLs. - Variantes: una página de producto indexable con selección de variante, salvo que una variante tenga demanda genuinamente propia: el color rara vez, la talla nunca. - Agotado: mantenga la página en línea con la disponibilidad marcada y alternativas visibles. Borrarla tira señales de posicionamiento acumuladas de un producto que puede volver el mes que viene. - Descatalogado de forma permanente: 301 al equivalente más cercano o a la categoría, no a la portada. - Descripciones propias. El texto del fabricante está en el sitio de cada competidor; es la definición de contenido duplicado. - Datos estructurados con precio y disponibilidad que coincidan exactamente con la página visible. ### Puntos técnicos propios de las tiendas Aparecen en casi cualquier tienda y rara vez en un sitio de presentación. | Resultados de búsqueda interna | noindex: son infinitos y pobres | | Cesta y caja | noindex, y bloquear el rastreo | | Cuentas de cliente | noindex; nunca permitir indexar páginas de pedido | | Varias monedas | Una URL canónica; no crear una URL por moneda | | Varios mercados | URLs con prefijo más hreflang recíproco | | Reseñas | Mostrar en HTML; marcado de reseña solo para reseñas reales en la página | | Rendimiento de listados | Vigilarlo según crece el catálogo: se degrada primero | | Sitemaps | Dividir por tipo y mantenerlos al día según cambia el stock | Los feeds de producto para anuncios de compras no sustituyen a las páginas de producto indexables. Son sistemas separados y uno no posiciona al otro. Q: ¿Hay que quitar los productos agotados? A: No si el artículo va a volver. Conserve la página, marque la disponibilidad con exactitud tanto en la página visible como en los datos estructurados y ofrezca alternativas. Borrarla tira enlaces e historial de posicionamiento que ha pagado. Redirija con 301 solo cuando el producto esté realmente descatalogado, y entonces al equivalente más cercano y no a la portada. Q: ¿Cómo gestiono productos en varias categorías? A: Dé a cada producto una única URL canónica que no incluya la ruta de categoría: /productos/bota-montana-x en vez de /botas/montana/bota-montana-x. Enlácela desde cada categoría relevante. Las URLs de producto basadas en categoría crean duplicados y se rompen en cuanto reorganiza el catálogo. Q: ¿Necesito descripciones propias para cada producto? A: Para los productos que quiera posicionar, sí. El texto del fabricante aparece en cada competidor que vende el mismo artículo, así que no hay nada que distinga su página. Si reescribir 4.000 productos es irreal, empiece por los que de verdad generan ingresos y deje que el resto se apoye en las páginas de categoría. Q: ¿Deben indexarse alguna vez las páginas de filtro? A: Un número pequeño, elegido a propósito: filtros únicos que respondan a demanda real de búsqueda y devuelvan un número decente de productos, como una marca dentro de una categoría. Dé a esas páginas su propio título y descripción. Todo lo demás —combinaciones, ordenaciones, deslizadores de precio— debería ser noindex, follow. ## Integración de pasarelas de pago: qué hay que hacer bien https://websitedevelopment.biz/es/guides/integracion-pasarela-de-pago Actualizado el 2026-08-07 · Comercio electrónico La integración de pagos parece sencilla en un tutorial y es implacable en producción, porque cada caso de fallo implica o bien una clienta que pagó y no recibió nada, o bien una clienta que recibió algo y no pagó. Esta guía cubre cómo funciona el flujo, la decisión de diseño que evita casi todos los problemas y los casos que conviene probar a propósito antes de lanzar. ### Cómo funciona realmente el flujo Sea cual sea el proveedor, la forma es la misma: su servidor crea una intención de cobro, la clienta se autentica con el proveedor de pago y el proveedor le comunica el resultado, dos veces y por dos vías distintas. - Su servidor crea una intención de pago con importe, moneda y una referencia a su pedido. - La clienta introduce los datos de la tarjeta en un campo o una página alojados, de forma que los datos nunca tocan su servidor. - Puede requerirse autenticación reforzada, lo que añade un paso que la clienta debe completar. - El proveedor devuelve a la clienta a su sitio con un resultado. - Por separado, el proveedor envía un webhook de servidor a servidor con el resultado autoritativo. - Su sistema actualiza el pedido a partir del webhook, no de la redirección. - La preparación del envío se dispara solo después de confirmar el pago. Los pasos 4 y 5 son todo el diseño. La redirección es una pista de lo que pasó; el webhook es el hecho. ### Por qué los webhooks deben ser la fuente de verdad El navegador de la clienta es un narrador poco fiable. Puede cerrarse durante la redirección, perder la conexión o ser manipulado. Si el estado de su pedido depende de que la clienta vuelva a su página de éxito, tendrá pedidos pagados que nunca se registraron. - Actualice el estado del pedido solo desde webhooks verificados; trate la redirección puramente como un mensaje para la persona. - Verifique las firmas de los webhooks. Un endpoint sin autenticar que marca pedidos como pagados es exactamente tan malo como suena. - Haga idempotente el tratamiento de webhooks: los proveedores reintentan y llegarán duplicados. - Responda rápido y procese de forma asíncrona; los endpoints lentos se reintentan y acaban desactivándose. - Registre cada carga útil de webhook. Las disputas de pago se resuelven con registros. - Gestione eventos fuera de orden, porque pueden llegar así y llegarán. ### Los casos de fallo que conviene probar Todos estos ocurren en producción. Pruébelos a propósito, con las tarjetas de prueba del proveedor, antes de lanzar. | La clienta cierra la pestaña tras pagar | El webhook completa igualmente el pedido; se envía el correo de confirmación | | Tarjeta rechazada | Mensaje claro, cesta conservada, otro intento posible | | Autenticación reforzada fallida | Pedido no confirmado; se le dice a la clienta qué hacer después | | Webhook duplicado | Pedido actualizado una vez, no dos; sin segundo envío | | El webhook llega antes que la redirección | La página de éxito refleja el pedido ya completado | | Devolución parcial | Los totales del pedido y cualquier exportación contable siguen siendo coherentes | | Stock agotado entre pago y envío | Proceso definido: devolución, pendiente o sustituto | | Redondeo de moneda | El importe cobrado coincide exactamente con el total mostrado | ### Alcance, cumplimiento y dinero Unas pocas decisiones determinan cuánta carga regulatoria asume y cuánto de la transacción se queda. - Nunca almacene números de tarjeta. Use campos o páginas alojados para que los datos de tarjeta no lleguen a su servidor; así el alcance PCI se mantiene mínimo. - Entienda la estructura de comisiones. Porcentaje más cuota fija, más conversión de divisa, más comisiones por devolución de cargo. El porcentaje anunciado no es el coste. - Compruebe el calendario de liquidación. Los días hasta el abono afectan a la tesorería más que una pequeña diferencia de tarifa. - Confirme que la vía de devolución funciona de principio a fin antes de lanzar, incluidas las parciales. - Soporte los métodos locales que su mercado usa de verdad: la tarjeta no es el estándar en todas partes, y perder el método local dominante cuesta conversiones. - Tenga un segundo proveedor preparado si los pagos son críticos. Las caídas ocurren y detienen los ingresos por completo. Q: ¿Caja alojada o formulario incrustado? A: La caja alojada es más simple, mantiene el alcance PCI mínimo y la mantiene el proveedor: para casi todas las tiendas es la opción por defecto correcta. Los campos incrustados mantienen a la clienta en su dominio y dan más control sobre la experiencia, a cambio de más código y más responsabilidad. Ambos mantienen los datos de tarjeta fuera de su servidor, que es la parte que importa. Q: ¿Qué pasa si mi endpoint de webhook se cae? A: Los proveedores reintentan con espera creciente, normalmente durante horas o días, así que una caída corta se recupera sola. Una caída larga significa pedidos sin confirmar, así que monitorice el endpoint y avise ante fallos. Además construya un trabajo de conciliación que compare a diario las transacciones del proveedor con sus pedidos: recoge todo lo que se escapó a los reintentos. Q: ¿Debo gestionar la autenticación reforzada de cliente? A: Si vende a clientes en regiones que la exigen, sí, y los SDK modernos de los proveedores se encargan de casi todo el flujo. Lo que sí debe gestionar es el resultado: un pedido pendiente de autenticación no está pagado, y tratarlo como pagado significa enviar mercancía que nunca cobró. Q: ¿Cómo pruebo pagos de forma segura? A: Todo proveedor tiene un modo de prueba con tarjetas que provocan resultados concretos: rechazo, autenticación requerida, fraude. Recorra la lista completa, incluidos los casos incómodos de la tabla anterior. Después haga una transacción real pequeña en producción antes de lanzar y devuélvala, porque el modo de prueba no ejercita sus claves ni su URL de webhook reales. ## WooCommerce, Shopify y Magento: una comparación práctica https://websitedevelopment.biz/es/guides/woocommerce-vs-shopify-vs-magento Actualizado el 2026-08-07 · Comercio electrónico Estas tres cubren casi todos los proyectos de tienda, y encajan en situaciones genuinamente distintas. La elección va menos de funciones —las tres pueden vender productos— y más de quién mantiene la tienda y qué pasa cuando crecen los requisitos. Esta comparación va por modelo operativo en vez de por lista de funciones, porque eso es lo que determina si una plataforma acaba funcionando. ### Para quién es cada una Dicho claramente, antes del detalle. | Shopify | SaaS alojado | Equipos que quieren vender, no mantener infraestructura | | WooCommerce | Plugin de WordPress, autogestionado | Sitios de contenido con catálogo modesto y conocimientos de WordPress | | Magento / Adobe Commerce | Empresa autogestionada | Catálogos complejos, reglas B2B, capacidad interna o de agencia | ### Diferencias prácticas Las comparaciones que cambian la decisión, en vez de las que aparecen en las páginas de marketing. | Esfuerzo de puesta en marcha | Bajo | Medio | Alto | | Quién parchea la seguridad | El proveedor | Usted | Usted | | Personalización de la caja | Limitada por diseño | Total | Total | | Catálogo a escala | Bueno | Se degrada sin trabajo | Construido para ello | | Reglas de precios B2B | Complemento | Plugin, de calidad variable | Nativo | | Multitienda / multimercado | Coste adicional | Incómodo | Nativo | | Coste de funcionamiento | Suscripción más comisiones más apps | Alojamiento más plugins más tiempo de desarrollo | Alojamiento y desarrollo sustanciales | | Perfil necesario | Operador | Desarrollador de WordPress | Desarrollador especializado | ### Dónde se rompe cada una Cada plataforma tiene un modo de fallo que aparece tras el lanzamiento y no durante la evaluación. Estos son los más frecuentes. - Shopify: reglas de caja que la plataforma no permite y suscripciones de apps que acaban superando la cuota de la plataforma. Además, comisiones por transacción si no usa su propio producto de pago. - WooCommerce: rendimiento de las páginas de listado según crece el catálogo, conflictos entre plugins tras actualizar y exposición de seguridad cuando nadie se ocupa de parchear. - Magento: el coste total de propiedad. Es potente y necesita infraestructura y experiencia de verdad; las tiendas Magento con pocos recursos van lentas y se retrasan en actualizaciones. - Las tres: la navegación facetada generando miles de URLs indexables si no se configura a propósito. El error caro más común es elegir Magento para un catálogo que WooCommerce manejaría, o elegir WooCommerce para uno que necesita Magento. Ambos errores afloran alrededor del primer año. ### Costes de salida Conviene saberlo antes de comprometerse, porque decide si la elección es reversible. | Shopify | Exportación CSV, sencilla | Exportación sin contraseñas | Exportación, histórico limitado | Los prefijos de URL fijos complican el mapeo | | WooCommerce | Acceso total a la base de datos | Acceso total | Acceso total | Totalmente bajo su control | | Magento | Acceso total a la base de datos | Acceso total | Acceso total | Totalmente bajo su control | Las plataformas autogestionadas son más fáciles de abandonar porque usted tiene la base de datos. Es una ventaja real del código abierto y rara vez se pondera al elegir. Q: ¿Cuál es la más barata? A: Para una tienda pequeña, Shopify suele ser la más barata en total una vez cuenta alojamiento, parcheo y tiempo de desarrollo: la suscripción se ve y los costes alternativos no. WooCommerce es la más barata si ya usa WordPress y tiene a alguien competente manteniéndolo. Magento no es la opción barata en ningún escenario. Q: ¿WooCommerce sirve para catálogos grandes? A: Puede manejar miles de productos con alojamiento, caché y trabajo de consultas adecuados, pero necesita ese trabajo: el rendimiento en páginas de listado y filtros se degrada antes de que el número de productos suene impresionante. Si el catálogo es grande y complejo desde el primer día, merece la pena compararlo con plataformas construidas para esa forma. Q: ¿Necesito Magento para B2B? A: No necesariamente, pero los requisitos B2B —precios por cliente, presupuestos, órdenes de compra, jerarquías de cuenta— son nativos ahí y complementos en otras. Si tiene varios de esos requisitos, la comparación es justa. Si tiene uno, un complemento sobre una plataforma más simple suele ser más barato de mantener. Q: ¿Puedo llevar contenido y comercio en la misma plataforma? A: WooCommerce lo hace de forma natural porque WordPress es primero un sistema de contenido. Las herramientas de contenido de Shopify son más flojas, así que las tiendas Shopify con mucho contenido suelen combinarlo con un CMS aparte. Si su captación es de contenido, pondere eso en serio: es una diferencia práctica mayor de lo que sugieren casi todas las comparativas de funciones. ## Plataformas de comercio electrónico comparadas: cómo elegir https://websitedevelopment.biz/es/guides/plataformas-ecommerce-comparadas Actualizado el 2026-08-07 · Comercio electrónico Las comparativas de plataformas caducan rápido porque las funciones cambian cada trimestre. Lo que no cambia es el conjunto de preguntas que deciden qué categoría de plataforma encaja, y las contrapartidas que asume cada categoría. Esta guía compara las categorías en vez de las marcas, y da las preguntas que estrechan la elección rápido. ### Las cuatro categorías Casi toda opción cae en una de estas, y la categoría decide más que la marca dentro de ella. | SaaS alojado | Solo contenido y operativa | Casi todas las tiendas pequeñas y medianas | | Código abierto autogestionado | Todo: alojamiento, actualizaciones, seguridad | Requisitos inusuales, capacidad interna | | Plugin de CMS (p. ej. un plugin de tienda) | Toda la pila, de forma ligera | Sitios de contenido con catálogo modesto | | Comercio headless | El frontend y la capa de integración | Varios canales, experiencias propias, equipos grandes | ### Las preguntas que de verdad estrechan la elección Respóndalas antes de mirar ninguna lista de funciones. Casi todas eliminan categorías enteras en vez de productos concretos. - ¿Qué complejidad tiene un solo producto? Variantes, opciones configurables y precios por cliente descartan las herramientas más simples. - ¿Cuántos mercados? Varios regímenes fiscales y monedas son donde las plataformas baratas se vuelven caras. - ¿Con qué debe integrarse? Un ERP o un sistema contable existente suele ser la restricción decisiva. - ¿Quién la opera día a día? Una plataforma que exige un desarrollador para cambios rutinarios no encaja en un negocio de dos personas. - ¿Cuál es el volumen realista de pedidos en dos años? Las comisiones por transacción escalan de forma distinta a las cuotas mensuales. - ¿Qué pasa si se va? Pregunte cómo exporta productos, clientes y pedidos antes de firmar nada. La pregunta de la salida es la que nadie hace y la que más duele después. Una plataforma con malas herramientas de exportación es una decisión que no podrá revisar barato. ### Coste total, no coste de licencia Las plataformas alojadas parecen caras en la línea de suscripción y a menudo salen más baratas en conjunto una vez se cuentan alojamiento, seguridad y mantenimiento. La autogestión parece gratis y no lo es. | Suscripción | Mensual, por tramos de volumen | Ninguna | | Comisión por transacción | A menudo un porcentaje además de las comisiones de pago | Solo comisiones de pago | | Alojamiento | Incluido | Suyo, y una tienda necesita recursos de verdad | | Seguridad y PCI | En gran medida cubierto | Suyo, incluido el alcance | | Actualizaciones | Automáticas | Suyas, y pueden romper personalizaciones | | Apps y extensiones | Mensual por app, se acumula rápido | Normalmente pago único o gratis, más su tiempo | | Tiempo de desarrollo | Menor para trabajo rutinario | Mayor, continuo | ### Dónde se rompe cada categoría Conocer el modo de fallo es más útil que conocer la lista de funciones, porque lo encontrará en el segundo año y no en la demostración. - SaaS alojado: un requisito de caja que la plataforma no permite, o suscripciones de apps que superan en silencio la cuota de la plataforma. - Autogestionado: nadie aplica las actualizaciones de seguridad, y la tienda se ve comprometida o se queda muy atrás. - Plugin de CMS: el crecimiento del catálogo degrada el rendimiento, y el sitio nunca se construyó para consultas de escala comercial. - Headless: el equipo de frontend se convierte en cuello de botella para cambios que marketing hacía solo. Casi todos estos son fallos operativos más que técnicos. Elija la plataforma que su organización pueda operar de verdad, no la más capaz. Q: ¿El código abierto sale más barato que una plataforma alojada? A: Rara vez, una vez cuenta alojamiento, parches de seguridad, tiempo de desarrollo y el coste de un incidente. Sale más barato cuando tiene capacidad interna que de otro modo estaría ociosa, o cuando tiene requisitos que una plataforma alojada rechaza. Comparar la línea de suscripción con cero es el error que lo hace parecer obvio. Q: ¿Puedo cambiar de plataforma después? A: Sí, y es un proyecto completo: normalmente entre el 30 y el 50 % del coste de una construcción nueva una vez se cuentan la migración de catálogo, el mapeo de URLs y rehacer las integraciones. Por eso la pregunta de exportación pertenece al proceso de selección. Los productos suelen exportar bien; con clientes e histórico de pedidos es donde se complica. Q: ¿Y el comercio headless? A: Es realmente útil cuando vende por varios canales o necesita un frontend que la plataforma no puede producir, y en el resto de casos es una complejidad extra considerable: suyos son el frontend, la capa de integración y su despliegue. Para una tienda de un solo canal con catálogo normal suele comprar una flexibilidad que nunca gastará. Q: ¿Qué plataforma es mejor para SEO? A: Hoy son bastante comparables: las diferencias están en cuánto control tiene sobre URLs, canónicas y metadatos, y en el rendimiento del frontend. Importa más si su implementación gestiona bien la navegación facetada, la paginación y la estabilidad de las URLs de producto, y eso es una decisión de construcción en cualquier plataforma. ## Desarrollo de tiendas online: la guía completa https://websitedevelopment.biz/es/guides/guia-desarrollo-tienda-online Actualizado el 2026-08-07 · Comercio electrónico Una tienda online es un sitio web con dinero, existencias y obligaciones legales colgando. Eso es lo que convierte el desarrollo de comercio electrónico en un proyecto distinto de un sitio de presentación: las partes que más cuestan no suelen ser las que ven los clientes. Esta guía cubre qué incluye realmente un proyecto de tienda, qué eleva el coste, el trabajo operativo que empieza al lanzar y los errores caros de deshacer. ### Qué incluye una tienda más allá del escaparate El catálogo y la caja son la parte visible. Debajo están los sistemas que deciden si el negocio puede operar de verdad, y ahí va la mayor parte del presupuesto en cualquier tienda que no sea la más pequeña. - Estructura del catálogo: categorías, variantes, atributos, packs, reglas de disponibilidad. - Precios: con o sin impuestos según el mercado, descuentos, grupos de clientes, moneda. - Pagos: al menos una pasarela, más devoluciones, devoluciones parciales y gestión de pagos fallidos. - Envíos: zonas, pesos, dimensiones, reglas de transportista, umbrales de envío gratis. - Impuestos: IVA o impuesto sobre ventas según destino, facturas con los campos que exija su jurisdicción. - Stock: disponibilidad, pedidos pendientes y reserva durante la compra para no vender de más. - Gestión de pedidos: dónde procesa el personal los pedidos, a menudo un sistema completamente aparte. - Correos: confirmación, envío, devolución, carrito abandonado y su contenido legal. - Devoluciones: la política y el flujo que la implementa. Pregunte pronto dónde procesará el personal los pedidos de verdad. Si es su ERP actual, la integración es una parte sustancial del proyecto y debe estar en la primera estimación. ### Qué eleva el coste El número de productos importa menos que su complejidad y que la cantidad de sistemas con los que la tienda debe hablar. | Catálogo | Productos simples, un precio | Variantes, opciones configurables, precios por cliente | | Mercados | Un país, una moneda | Varios regímenes fiscales, monedas, idiomas | | Integraciones | Ninguna más allá del pago | ERP, PIM, gestión de almacén, contabilidad, feeds de marketplace | | Migración | Tienda nueva, sin histórico | Catálogo, clientes, pedidos y URLs existentes | | Logística | Un almacén, envío plano | Varias ubicaciones, reglas de transportista, envío directo | | Cumplimiento | Venta estándar a consumidor | Restricción de edad, licencias, productos regulados | ### La migración es un proyecto aparte Cambiar de plataforma una tienda existente suele ser más difícil que construir una nueva, y la dificultad son los datos y las URLs, no el diseño. - Exporte y limpie el catálogo antes que nada. Los datos existentes siempre están peor de lo que se recuerda. - Decida qué no se mueve. Los productos descatalogados sin tráfico no necesitan migrarse. - Mapee cada URL antigua de producto y categoría a una nueva; redirija con 301 y espere que la lista sea larga. - Migre las cuentas de cliente sin contraseñas: fuerce un restablecimiento en vez de mover hashes entre sistemas. - Decida cuánto histórico de pedidos se mueve. A menudo la respuesta es «ninguno, el sistema antiguo queda en solo lectura un año». - Mantenga ambos sistemas en paralelo un periodo corto si el stock lo permite, y concilie a diario. - Vigile el tráfico de búsqueda por categoría durante seis semanas; una categoría que cae suele ser una redirección olvidada. Presupueste tanto tiempo para limpiar los datos del catálogo como para construir la tienda. En casi todas las migraciones es la tarea mayor y la que nadie había previsto. ### El trabajo que empieza al lanzar Una tienda es un sistema operativo para un negocio, no un proyecto que termina. Estos costes son continuos y con frecuencia faltan en el primer presupuesto. | Contenido de producto | Líneas nuevas, fotografía nueva, descripciones nuevas | | Exactitud del stock | Vender de más cuesta más que cualquier fallo de desarrollo | | Actualizaciones de pago y plataforma | Las pasarelas retiran APIs según su propio calendario | | Parches de seguridad | Las tiendas son objetivo por los datos de pago; los parches no son opcionales | | Fraude y devoluciones de cargo | Las reglas necesitan ajuste según cambia la mezcla de pedidos | | Cambios en las normas fiscales | Tipos y umbrales cambian por jurisdicción, a veces cada año | | Rendimiento | El crecimiento del catálogo degrada primero las páginas de listado | Q: ¿Cuánto cuesta construir una tienda online? A: Una tienda pequeña sobre plataforma alojada con un tema ligero puede empezar en torno a los 5.000 $. Una tienda mediana con diseño propio y una o dos integraciones suele estar entre 20.000 y 60.000 $. Los catálogos grandes con integración de ERP y varios mercados superan bastante esa cifra. La migración suele añadir entre un 30 y un 50 % sobre una construcción nueva equivalente. Q: ¿Plataforma alojada o autogestionada? A: Las plataformas alojadas se ocupan de la seguridad, el alcance PCI y el escalado por una cuota mensual y a menudo un porcentaje por transacción, a cambio de límites de personalización. La autogestión da control total y el mantenimiento y la carga de cumplimiento son suyos. Para casi todas las tiendas pequeñas y medianas, alojada es la opción de menor riesgo; el argumento para autogestionar crece con los requisitos inusuales y la facturación. Q: ¿Necesito un sistema de gestión de pedidos aparte? A: Por debajo de unas pocas decenas de pedidos al día suele bastar la administración de la plataforma. Por encima, o con varios canales de venta, un sistema dedicado se paga solo rápido. La pregunta a responder antes de construir es dónde vive la cifra de stock autoritativa, porque eso decide qué sistema informa a cuál. Q: ¿Cuál es el error más común al construir una tienda? A: Tratar impuestos y envíos como configuración en vez de como requisitos. Son reglas de negocio con casos límite —umbrales, zonas, cestas mixtas, bienes digitales— y descubrirlos en la semana ocho reescribe la caja. Póngalos por escrito durante el descubrimiento, con ejemplos de los casos incómodos. ## Estructura de URLs para SEO: las reglas que siguen importando https://websitedevelopment.biz/es/guides/estructura-de-urls-seo Actualizado el 2026-08-07 · SEO Las URLs son un factor de posicionamiento pequeño y un factor de usabilidad y mantenimiento grande. Su valor real es la estabilidad: una URL que nunca tiene que cambiar es una URL que conserva sus enlaces, sus posiciones y sus marcadores. Esta guía cubre las reglas que siguen importando, las que ya no, y cómo cambiar una URL cuando de verdad debe hacerlo. ### Las reglas que merece la pena seguir Son coherentes entre buscadores y, más importante, a lo largo de los años: tienen tanto que ver con el mantenimiento como con el posicionamiento. - Solo minúsculas. Algunos servidores tratan /Pagina y /pagina como URLs distintas, lo que crea duplicados por accidente. - Guiones entre palabras, no guiones bajos ni mayúsculas intercaladas. - Cortas y descriptivas. Si alguien lee la URL en voz alta, debería poder adivinar la página. - No hacen falta palabras vacías: /guias/planificacion-web gana a /guias/como-planificar-una-web-para-mi-empresa. - Sin extensiones de archivo en páginas de contenido. /sobre-nosotros, no /sobre-nosotros.php: oculta la implementación y sobrevive a una migración. - Una decisión canónica sobre la barra final, forzada con una redirección. - ASCII cuando sea práctico; las URLs no ASCII funcionan pero se codifican al copiarlas, lo que es feo y propenso a errores. La propiedad más valiosa es la estabilidad. Una URL ligeramente imperfecta que nunca cambia vale más que una optimizada que cambia dos veces. ### Lo que ya casi no importa Varias creencias veteranas sobre URLs tienen hoy un efecto limitado, y seguirlas puede incluso perjudicar. | Las URLs con coincidencia exacta posicionan mejor | Marginal en el mejor caso; acumular palabras parece spam | | Una estructura de carpetas profunda señala jerarquía | La profundidad de clics importa; la de ruta apenas | | Las fechas en las URLs ayudan a la frescura | Hacen que el contenido perenne parezca caducado | | Más corta es siempre mejor | Descriptiva gana a escueta; /p/4821 no ayuda a nadie | | Subdominio frente a subcarpeta es decisivo | Las subcarpetas son más fáciles de gestionar; ambas pueden funcionar | | Las cadenas de consulta no se pueden indexar | Sí se pueden, pero multiplican duplicados: prefiera rutas limpias | ### Patrones de URL multiidioma Para un sitio en varios idiomas, el patrón de URL es de lo más difícil de cambiar después, porque interactúa con hreflang, las canónicas y cada redirección que escribirá en su vida. | Subcarpeta | sitio.com/es/guias | El más simple; un dominio acumula toda la autoridad | | Subdominio | es.sitio.com/guias | Separación más limpia; más configuración, señales divididas | | Dominio de país | sitio.es/guias | Señal local más fuerte; un sitio aparte que gestionar | | Parámetro | sitio.com/guias?lang=es | Evítelo: señales débiles y riesgo de duplicados | Elija lo que elija, decida aparte si se traduce el propio slug. Traducir los slugs ayuda a la relevancia local; mantenerlos idénticos es más simple de mantener. Ambas son defendibles; cambiar de idea después no. ### Cambiar una URL sin perder tráfico A veces el cambio es realmente necesario. El procedimiento es mecánico, y saltarse cualquier paso es por donde se va el tráfico. - Confirme que merece la pena. Cambiar una URL siempre cuesta algo; una mejora incremental de redacción rara vez lo compensa. - Mapee antigua a nueva, una a una. Cada URL antigua recibe un destino concreto, no una página de categoría. - Implemente 301, no 302, y verifique que cada una devuelve un único salto. - Actualice los enlaces internos para que apunten directamente a la nueva URL. No dependa de sus propias redirecciones. - Actualice el sitemap y deje las redirecciones indefinidamente: los enlaces externos nunca se actualizan. - Vigile la cobertura de Search Console y su informe de páginas principales durante cuatro a seis semanas. - Cuente con una caída e investigue solo si sigue agravándose pasado un mes. Q: ¿Debo incluir palabras clave en las URLs? A: Incluya las palabras que describen la página, que normalmente son las palabras clave. Lo que no debe hacer es acumular variantes: /servicios-desarrollo-web-desarrollo-web-barato es peor que /servicios-desarrollo-web en todos los sentidos, incluido para las personas que lo ven en los resultados. Q: ¿Subdominio o subcarpeta para un blog? A: Subcarpeta, en casi todos los casos. sitio.com/blog es más fácil de gestionar, comparte las señales acumuladas del dominio y no necesita configuración técnica aparte. Los subdominios tienen sentido cuando la sección es realmente una aplicación distinta, tiene otro equipo o debe correr sobre otra infraestructura. Q: ¿Cuánto tiempo debo mantener las redirecciones antiguas? A: Indefinidamente. Cuestan casi nada y los enlaces externos a sus URLs antiguas nunca se actualizarán. Lo que sí debería hacer es reducir periódicamente las cadenas creadas por migraciones sucesivas, para que cada URL antigua apunte directamente al destino actual en un solo salto. Q: ¿Los parámetros de URL perjudican al SEO? A: No son dañinos en sí, pero multiplican rápido URLs casi duplicadas: parámetros de orden, filtro y seguimiento pueden generar miles de variantes de una página. Use rutas limpias para todo lo que quiera indexar, y canonicalice o ponga noindex en las variantes con parámetros. ## Desarrollo web multiidioma: estructura, URLs y flujo de trabajo https://websitedevelopment.biz/es/guides/desarrollo-web-multiidioma Actualizado el 2026-08-07 · CMS Añadir idiomas a un sitio rara vez es solo traducir. Cambia la estructura de URLs, añade un conjunto de etiquetas recíprocas que se rompen en silencio e introduce un flujo de contenido donde una página se convierte en doce que pueden separarse entre sí. Esta guía cubre las decisiones estructurales, los requisitos técnicos y el flujo de trabajo que evita que las traducciones caduquen. ### Decida primero el patrón de URL Es la decisión cara de revertir, porque toca cada URL, cada redirección y cada etiqueta hreflang del sitio. | Subcarpeta | sitio.com/es/guias | Casi todos los sitios: el más simple, un dominio acumula autoridad | | Subdominio | es.sitio.com/guias | Infraestructura separada o equipos separados | | Dominio de país | sitio.es/guias | Compromiso local fuerte, y un sitio aparte que gestionar | | Parámetro | sitio.com/guias?lang=es | Evítelo: señales débiles, riesgo de duplicados | Decida aparte si se traduce el slug. Los slugs traducidos ayudan a la relevancia local; los idénticos son más simples de mantener. Cualquiera es defendible; cambiar de idea después no. ### Los requisitos técnicos Cada uno de estos falla en silencio, y por eso tantos sitios multiidioma no tienen un hreflang funcionando pese a llevar las etiquetas. - hreflang recíproco. Cada página de un conjunto de idiomas lista a todas las demás, incluida ella misma. Una referencia inversa que falte descarta el grupo. - Códigos coherentes. El mismo código en el HTML y en el sitemap. Dos códigos para una página rompen el conjunto. - x-default apuntando al selector de idioma o a la versión por defecto. - Atributos lang y dir correctos en el elemento html de cada versión. - Canónica autorreferenciada por idioma; nunca canonicalice las traducciones al original. - Sin redirección automática por IP o idioma del navegador. Rompe el rastreo y anula una elección deliberada; ofrezca una sugerencia en su lugar. - Metadatos traducidos. Títulos y descripciones en el idioma de destino, no en el de origen. ### Un flujo de traducción que aguante El modo de fallo no es la primera traducción, es la quinta edición de la página en español que nunca llega a las otras once. - Modele las traducciones como versiones enlazadas de un mismo elemento de contenido, para que el sistema sepa que van juntas. - Registre qué traducciones están desactualizadas respecto al original y muéstrelo en la interfaz de edición. - Decida qué pasa cuando falta una traducción: recurrir al idioma por defecto o no publicar esa URL en absoluto. - Nunca publique una URL sin traducción: una página que se muestra a medias en otro idioma es peor que no existir. - Lleve una fecha de revisión por idioma, no por elemento de contenido. - Dé contexto a quien traduce: una captura o una vista previa gana a una hoja de cálculo de cadenas. - Decida quién es responsable de cada idioma. Los idiomas sin responsable caducan primero. La traducción automática como punto de partida está bien; publicarla sin revisar no. Una salida sin revisar se lee como no revisada, y es justo el tipo de contenido de bajo valor sobre el que los buscadores son cada vez más explícitos. ### Más allá del texto La traducción es la parte que todo el mundo presupuesta. Estas son las partes que se olvidan y causan errores visibles. | Fechas y números | El formato y los separadores difieren por región | | Moneda | Símbolo, posición y convenciones de redondeo | | Direcciones y teléfonos | Orden de campos y reglas de validación | | Nombres | El orden de nombre y apellidos no es universal | | Longitud del texto | El alemán y el finés se alargan; las maquetaciones deben ceder | | Dirección de lectura | El árabe y el hebreo necesitan propiedades CSS lógicas | | Imágenes con texto | Necesitan una versión por idioma, o nada de texto en la imagen | | Páginas legales | Los requisitos difieren por jurisdicción, no solo por idioma | Q: ¿Debo redirigir a los visitantes a su idioma automáticamente? A: No. La redirección automática por IP o idioma del navegador interfiere con el rastreo —un rastreador de un país puede no ver nunca las otras versiones— y anula elecciones deliberadas, lo que resulta irritante para quien lee en una segunda lengua. Muestre una sugerencia que se pueda descartar y deje decidir a la persona. Q: ¿Es aceptable la traducción automática? A: Como primer borrador sí, y ahorra dinero real. Publicada sin revisión humana produce contenido que se lee como generado por máquina, lo que afecta tanto a las personas como a la evaluación de calidad de búsqueda. El enfoque pragmático es traducción automática más una revisión nativa, sobre todo en páginas que venden o explican algo importante. Q: ¿Qué rompe hreflang más a menudo? A: Las etiquetas no recíprocas: la página A lista a la B, la B no lista a la A, y todo el grupo se ignora. En segundo lugar, códigos que no coinciden entre HTML y sitemap. Ambos se evitan generando hreflang desde una única fuente de verdad en vez de mantener dos listas. Q: ¿Tengo que traducir todo el sitio? A: No, y la traducción parcial es lo normal. Traduzca lo que tenga demanda en ese mercado y deje el resto solo en el idioma de origen. Lo que no debe hacer es publicar una URL vacía o traducida a medias: o la página existe correctamente en ese idioma o no existe en absoluto. ## Optimizar la velocidad de un sitio: un orden práctico de trabajo https://websitedevelopment.biz/es/guides/optimizar-velocidad-web Actualizado el 2026-08-07 · SEO El trabajo de velocidad tiene una forma de Pareto muy marcada: un puñado de arreglos explica casi toda la mejora en casi todos los sitios, y casi siempre son imágenes, respuesta del servidor y scripts de terceros. Esta guía cubre en qué orden trabajar, cómo medir si un cambio ayudó y las optimizaciones que normalmente no compensan el esfuerzo. ### Mida antes de cambiar nada Optimizar sin medir significa arreglar lo más fácil en vez de lo más lento. Dos mediciones y luego a trabajar. - Consiga datos de campo de visitantes reales: el informe de Core Web Vitals en Search Console, o su propia monitorización. - Ejecute una prueba de laboratorio en las tres plantillas más importantes, limitada a un móvil de gama media con 4G. - Anote las cifras antes de empezar. Sin una referencia no puede saber si un cambio ayudó. - Identifique el mayor recurso y la mayor petición bloqueante de cada plantilla. - Anote el Time to First Byte aparte: si supera los 800 ms, ningún trabajo de frontend le salvará. ### El orden que compensa Aproximadamente por mejora obtenida por hora de esfuerzo, para un sitio de contenido o presentación típico. | Optimizar y dimensionar bien las imágenes | Grande | Bajo | | Quitar scripts de terceros sin usar | Grande | Bajo; sobre todo es una tarea política | | Activar caché y un CDN | Grande | Bajo | | Arreglar CSS y JS que bloquean el renderizado | Medio a grande | Medio | | Reducir el paquete de JavaScript | Medio a grande | Medio a alto | | Arreglar consultas lentas de base de datos | Grande donde aplica | Medio | | Optimizar la carga de fuentes | Medio | Bajo | | Minificar y comprimir recursos de texto | Pequeño | Bajo; normalmente ya está activo | | Microoptimizar selectores CSS | Insignificante | No compensa | ### Imágenes: normalmente la mayor ganancia En casi todos los sitios las imágenes son la mayor parte del peso de página, y la mayoría se sirven varias veces más grandes de lo que se muestran. Es la mejora grande más barata que existe. - Sirva WebP o AVIF; ambos tienen soporte amplio y suelen ser entre un 25 y un 50 % más pequeños que JPEG con calidad equivalente. - Genere varios tamaños y use srcset con sizes para que los móviles descarguen archivos de tamaño móvil. - Nunca sirva una imagen de 2000 px en un hueco de 400 px: este error concreto es extremadamente común. - Cargue en diferido todo lo que esté bajo la línea de flotación, y nada por encima. - Automatícelo en la compilación o en el CMS. Las imágenes optimizadas a mano dejan de estarlo la primera vez que sube una otra persona. - Elimine los metadatos; el EXIF de cámara puede ocupar decenas de kilobytes por archivo. La automatización es el punto clave. Una pasada de optimización puntual se degrada en meses según se añade contenido, y nadie lo nota hasta que el peso de página se ha duplicado. ### Scripts de terceros y el servidor Son las dos áreas donde el problema suele ser organizativo más que técnico: nadie es dueño del gestor de etiquetas y nadie es dueño de la decisión de alojamiento. | Gestor de etiquetas con etiquetas desconocidas | Auditar cada etiqueta; borrar todo lo que nadie pueda justificar | | Widget de chat cargando en todas las páginas | Cargar al interactuar, o solo donde haga falta soporte | | Varias herramientas de analítica | Quedarse con una; cada una es un script completo y una conexión | | Script de test A/B bloqueando el renderizado | Moverlo al servidor, o aceptar un parpadeo y cargarlo async | | TTFB lento en alojamiento compartido | Añadir caché de página completa; subir de plan si persiste | | Consultas de base de datos sin cachear | Cachear las costosas; añadir índices para las frecuentes | | Sin CDN | Añadir uno: es el arreglo de latencia global más barato que existe | Los scripts de terceros son la fuente más fiable de ralentizaciones inexplicables, porque cambian sin avisarle y están fuera de su proceso de despliegue. Q: ¿Cuál es un buen tiempo de carga? A: Los objetivos útiles son los umbrales de Core Web Vitals más que una única cifra de carga: LCP por debajo de 2,5 segundos y Time to First Byte por debajo de 800 ms. El tiempo total de carga es una mala medida porque una página puede ser usable mucho antes de que termine cada recurso, e inutilizable mucho antes de eso en un dispositivo lento. Q: ¿Un sitio más rápido aumenta las conversiones? A: Por lo general sí, y el efecto es mayor donde las páginas están ahora lentas y los visitantes usan redes móviles. La ganancia de tres segundos a dos es mucho mayor que la de uno y medio a uno. Si su sitio ya es rápido, invierta el esfuerzo en contenido y claridad: el retorno es mejor. Q: ¿Los plugins de caché lo resuelven todo? A: Resuelven bien una cosa real —el trabajo repetido del servidor para la misma página— y pueden crear problemas nuevos, sobre todo con usuarios identificados, cestas y formularios. Además no hacen nada con imágenes sobredimensionadas ni con scripts de terceros, que suelen ser los problemas mayores. Útiles, no suficientes. Q: ¿Merece la pena el renderizado en servidor por velocidad? A: Si sus páginas hoy se renderizan solo en el navegador, sí: el renderizado en servidor o la generación estática eliminan un viaje completo antes de que aparezca el contenido, y de paso ayudan a la indexación. Si sus páginas ya son HTML servido, la pregunta no aplica: ya tiene el beneficio. ## Core Web Vitals: qué mueve de verdad las cifras https://websitedevelopment.biz/es/guides/core-web-vitals-para-desarrolladores Actualizado el 2026-08-07 · SEO Las Core Web Vitals son tres mediciones de campo de cómo se siente una página: cuánto tarda en aparecer el contenido principal, cuánto se mueve mientras carga y con qué rapidez responde a la interacción. Son una señal de posicionamiento y, más importante, se correlacionan con que la gente se quede. Esta guía cubre qué mide cada métrica, las causas concretas detrás de las malas puntuaciones y los arreglos que mueven los datos de campo y no solo los de laboratorio. ### Qué miden las tres métricas Cada una tiene un umbral para «bueno» y un pequeño conjunto de causas habituales. Tenga en cuenta que la cifra que cuenta para el posicionamiento son los datos de campo de visitantes reales, no una puntuación de laboratorio desde su portátil. | LCP | Menos de 2,5 s | Tiempo hasta que se dibuja el mayor elemento visible | Imagen principal sin optimizar, servidor lento, CSS que bloquea el renderizado | | CLS | Menos de 0,1 | Cuánto se mueve la maquetación al cargar | Imágenes sin dimensiones, banners insertados, fuentes web tardías | | INP | Menos de 200 ms | Capacidad de respuesta a la interacción | Tareas largas de JavaScript bloqueando el hilo principal | Las herramientas de laboratorio miden una carga en una máquina. Los datos de campo son el percentil 75 de visitas reales, que incluye móviles antiguos en redes malas: justo los visitantes con más probabilidad de irse. ### Arreglar el LCP El LCP es casi siempre una imagen o un titular bloqueado detrás de otra cosa. Vaya por orden; los dos primeros puntos arreglan casi todos los sitios. - Identifique el elemento LCP real en los datos de campo. Optimizar la imagen equivocada es el esfuerzo desperdiciado más común. - Nunca cargue en diferido la imagen del LCP. Dele fetchpriority="high" en su lugar. - Sírvala en formato moderno al tamaño en que se muestra, con srcset para pantallas más pequeñas. - Precargue la fuente que usa el texto del LCP y use font-display: swap para que el texto no sea invisible mientras espera. - Elimine del head el CSS y el JavaScript que bloquean el renderizado; incruste el CSS crítico si la página es lo bastante pequeña. - Reduzca el Time to First Byte con caché y un CDN: ningún trabajo de frontend compensa un servidor lento. - Recorte los scripts de terceros en la ruta crítica. Cada uno es una resolución DNS, una conexión y un archivo impredecible. ### Arreglar el CLS El desplazamiento de la maquetación es casi totalmente evitable y los arreglos son baratos. Además es la métrica que los visitantes notan de forma más visceral: es lo que hace que la gente pulse donde no quería. - Ponga los atributos width y height en cada imagen y vídeo para que el navegador reserve el espacio. - Reserve espacio para anuncios, incrustaciones e iframes con un contenedor de relación de aspecto fija. - Nunca inserte contenido por encima del existente después de cargar: los avisos de cookies van abajo o superpuestos. - Ajuste las métricas de la fuente de respaldo a la fuente web, o use size-adjust, para que el cambio no rehaga la página. - Evite animar propiedades de maquetación. Anime transform y opacity, que no provocan recálculo. - Dé a las secciones cargadas dinámicamente un min-height para que no crezcan desde cero. ### Arreglar el INP El INP sustituyó al First Input Delay y es más difícil, porque mide cada interacción de la visita y no solo la primera. Un INP malo es casi siempre demasiado JavaScript ejecutándose en el hilo principal. | Paquete grande analizado al cargar | Dividir el código; cargar solo lo que la página necesita | | Tareas largas de más de 50 ms | Trocear el trabajo y ceder el hilo principal | | Manejadores de eventos costosos | Aplicar debounce y sacar el trabajo pesado de la ruta de interacción | | Etiquetas de terceros pesadas | Cargar tras la interacción, o quitar: audite qué aporta cada una | | DOM grande (más de 10.000 nodos) | Virtualizar listas largas; simplificar el marcado muy anidado | | Sacudida de maquetación en manejadores | Agrupar lecturas y escrituras en vez de alternarlas | En sitios de contenido, el arreglo de INP de mayor valor suele ser borrar JavaScript en vez de optimizarlo. Pregunte qué aporta cada script; los gestores de etiquetas acumulan scripts que nadie recuerda haber añadido. Q: ¿Cuánto afectan las Core Web Vitals al posicionamiento? A: Son una señal real pero moderada, y actúan como desempate más que como sustituto de la relevancia. Una página rápida sobre el tema equivocado no supera a una más lenta que responde a la consulta. El argumento más fuerte para arreglarlas es conductual: las páginas lentas y que saltan pierden visitantes antes de que el posicionamiento entre en juego. Q: ¿Por qué mi puntuación de Lighthouse es buena y mis datos de campo malos? A: Porque Lighthouse simula una carga en su máquina con su conexión, y los datos de campo son el percentil 75 de visitas reales, incluidos móviles de hace tres años en redes móviles congestionadas. Cuando ambos se contradicen, los que cuentan son los de campo. Use las herramientas de laboratorio para diagnosticar, no para puntuar. Q: ¿Tengo que arreglar las tres métricas? A: Arregle las que estén fallando, en el orden de lo que experimentan sus visitantes. El CLS suele ser el más barato de arreglar y el más molesto para el usuario, así que es un buen punto de partida. El LCP tiene el mayor efecto sobre si la gente espera. El INP importa más en sitios interactivos y menos en artículos estáticos. Q: ¿Cuánto tardan en verse las mejoras? A: Los datos de campo son una ventana móvil de 28 días, así que un movimiento apreciable tarda unas cuatro semanas desde que un arreglo llega a todos los visitantes. No juzgue un cambio a los tres días. Sí compruebe las métricas de laboratorio de inmediato para confirmar que el arreglo hizo lo que esperaba. ## Migración de CMS: cómo mudarse sin perder tráfico https://websitedevelopment.biz/es/guides/guia-migracion-cms Actualizado el 2026-08-07 · CMS Una migración de CMS mueve contenido de un sistema a otro. El riesgo no es técnico —exportar e importar son problemas resueltos—, sino que por el camino cambian la estructura, las URLs y los metadatos, y los buscadores notan las tres cosas. Esta guía cubre la secuencia que mantiene el tráfico intacto, la auditoría que debería ir primero y qué vigilar después. ### Audite antes de mover nada Migrarlo todo es lo que se hace por defecto y suele ser la elección equivocada. Casi todos los sitios arrastran una cola considerable de páginas sin tráfico, sin enlaces y sin propósito, y moverlas importa el problema al sistema nuevo. - Rastree el sitio actual para obtener todas las URLs que existen de verdad. - Saque doce meses de tráfico por URL, más los enlaces entrantes. - Clasifique cada página: migrar tal cual, reescribir, fusionar con otra o descartar. - Todo lo que tenga tráfico o enlaces debe tener destino. El resto puede irse. - Anote qué páginas llevan datos estructurados, campos propios o plantillas inusuales. - Exporte los metadatos —títulos y descripciones— aparte. Es el activo que más se pierde en una migración. Fusionar páginas pobres en otras más fuertes durante una migración es uno de los pocos resultados de SEO fiablemente positivos de todo el ejercicio. Redirija las fusionadas a la que sobrevive. ### Modele el contenido antes de importarlo La tentación es recrear la estructura antigua tal cual. Eso importa los compromisos antiguos. Modele el contenido como debería ser y luego mapee los datos viejos sobre él. | Tipos de contenido | Qué se diferencia de verdad: página, artículo, producto, persona, evento | | Campos | Campos estructurados en vez de un bloque de HTML siempre que sea viable | | Taxonomías | Qué categorías y etiquetas sobreviven; casi todos los sitios tienen demasiadas | | Medios | Dónde viven los archivos y si cambian las rutas | | Autoría y fechas | Conservar las fechas reales de publicación; no reiniciarlas todas a hoy | | Metadatos | Títulos, descripciones y canónicas mapeados de forma explícita | | Mapa de redirecciones | URL antigua a URL nueva, una a una, construido sobre la marcha | Reiniciar las fechas de publicación al importar es un accidente habitual y destruye de golpe la señal de frescura de todo su archivo. ### Conserve las URLs y redirija lo que no pueda El factor que más determina si una migración cuesta tráfico. - Conserve la estructura de URLs existente salvo que esté realmente rota. «El CMS nuevo prefiere otro patrón» no es motivo suficiente. - Donde las URLs deban cambiar, mapee una a una; nunca a una página de categoría ni a la portada. - Use redirecciones 301 y verifique que cada una es un único salto. - Redirija también los archivos de medios. Las imágenes acumulan enlaces y aparecen en la búsqueda de imágenes. - Conserve las redirecciones indefinidamente; los enlaces externos nunca se actualizan. - Pruebe el mapa de redirecciones en preproducción con la lista completa antes de lanzar, no con una muestra. ### El lanzamiento y las seis semanas siguientes La migración no termina al cambiar. Casi todos los problemas se hacen visibles el mes siguiente. - Lance cuando pueda vigilarlo. Ni viernes ni antes de un festivo. - Verifique de inmediato robots.txt, meta robots, canónicas y sitemap en producción. - Pase la lista completa de redirecciones contra producción y busque 404 y cadenas. - Envíe el sitemap nuevo en Search Console y vigile la cobertura a diario durante una semana. - Compare las páginas principales con el periodo anterior; una página que cae con fuerza suele tener una causa concreta. - Vigile los registros del servidor por 404 de rastreadores: encuentran URLs olvidadas antes que la analítica. - Cuente con fluctuación de dos a seis semanas; investigue una caída que siga agravándose pasado un mes. - Mantenga el sistema antiguo en solo lectura un tiempo, para poder comprobar qué contenía antes una página. Q: ¿Perderé tráfico de búsqueda al migrar? A: Cuente con una caída de unas semanas incluso haciéndolo todo bien: los buscadores tienen que volver a rastrear y reevaluar. Con redirecciones limpias y contenido conservado, el tráfico normalmente vuelve al nivel anterior en dos a seis semanas. Una pérdida permanente casi siempre se remonta a redirecciones olvidadas, contenido cambiado o páginas descartadas en silencio. Q: ¿Debo rediseñar al mismo tiempo? A: Es tentador y complica mucho el diagnóstico: cuando el tráfico se mueve, no puede saber si fue la migración o el diseño. Si puede separarlos, migre primero con las plantillas actuales, confirme la estabilidad y luego rediseñe. Si tienen que ir juntos, sea aún más riguroso conservando URLs y contenido. Q: ¿Cómo migro contenido que no mapea limpio? A: Siempre hay contenido que se resiste a la automatización: maquetaciones propias, widgets incrustados, tablas hechas a mano. Identifíquelo durante la auditoría y presupueste tiempo manual. Intentar automatizar el último 5 % suele costar más que hacerlo a mano, y da peores resultados. Q: ¿Debo mantener el CMS antiguo funcionando? A: Manténgalo accesible pero no público unos meses: en solo lectura, bloqueado a los buscadores, en una dirección interna. Es valiosísimo para comprobar qué decía antes una página cuando algo parece mal. Después dele de baja como es debido: una instalación pública abandonada es un riesgo de seguridad. ## Checklist de SEO técnico para equipos de desarrollo web https://websitedevelopment.biz/es/guides/checklist-seo-tecnico Actualizado el 2026-08-07 · SEO El SEO técnico es la parte del trabajo de búsqueda que vive en el código y no en un calendario editorial. Es en gran medida una checklist, y casi todo en ella es verificable en vez de opinable. Esta guía es esa checklist, agrupada por el problema que evita cada punto, con los errores lo bastante comunes como para nombrarlos. ### Control de indexación El objetivo aquí es que estén indexadas exactamente las páginas que quiere y nada más: ni copias de preproducción, ni permutaciones de filtros, ni duplicados para imprimir. - Un único nombre de host canónico; cualquier otra variante redirige con 301, incluidos HTTP y el gemelo con o sin www. - Canónica autorreferenciada en cada página indexable. - noindex, follow en páginas pobres o duplicadas: resultados de búsqueda interna, combinaciones de filtros, páginas de agradecimiento. - Nunca bloquee en robots.txt una página que lleve un noindex: la etiqueta no podrá leerse nunca, así que la URL se queda en el índice. - Preproducción bloqueada con autenticación HTTP, no solo con robots.txt. - Tratamiento de parámetros decidido: qué cadenas de consulta crean una página distinta y cuáles no. noindex y un bloqueo en robots.txt hacen cosas opuestas y se anulan. Si quiere que una página desaparezca, permita el rastreo para que el noindex se pueda ver. ### Redirecciones y códigos de estado Las redirecciones son donde los relanzamientos pierden tráfico en silencio. Los fallos son mecánicos y fáciles de probar antes de lanzar. | Página movida de forma permanente | 301 a la página equivalente | 302, o redirigir a la portada | | Página eliminada sin equivalente | 410 o 404 | Soft 404: una página de «no encontrado» que devuelve 200 | | No disponible temporalmente | 503 con Retry-After | Devolver 200 con un mensaje de error | | Variantes con y sin barra final | Una forma canónica, la otra con 301 | Ambas sirviendo el mismo contenido con 200 | | Dominio antiguo | 301 mapeado página a página | Todo a la portada nueva | | Cadenas de redirección | Reducir a un solo salto | A → B → C → D, perdiendo señal en cada paso | ### Paginación, facetas y duplicación Las páginas de listado generan los mayores problemas de índice, porque un puñado de filtros puede producir miles de combinaciones de URL que parecen casi duplicados. - Páginas paginadas: enlaces rastreables reales, cada página autocanónica; no canonicalice la página 2 a la 1. - Combinaciones de filtros: noindex, follow por defecto; indexe solo las pocas que respondan a demanda real de búsqueda. - Órdenes de clasificación: nunca cree una URL indexable nueva. Mismo contenido, distinta secuencia. - Identificadores de sesión y parámetros de seguimiento: elimínelos o canonicalice a la URL limpia. - Duplicados para imprimir o tipo AMP: canónica a la versión principal. - Productos en varias categorías: una única URL canónica, enlazada desde todas. La navegación facetada dejada abierta es la causa más común de inflación del índice, y se limpia despacio. Es mucho más barato prevenirla al construir que deshacerla después. ### Datos estructurados y configuración internacional Dos áreas donde un error mecánico desactiva en silencio toda la funcionalidad. | Marcado Article | Solo en artículos reales, con fechas verdaderas | Fechas de frescura inventadas hacen que se ignore la funcionalidad | | Marcado Product | El precio y la disponibilidad deben coincidir con la página | La discrepancia provoca una acción manual | | Marcado FAQ | Solo para preguntas visibles en la página | El contenido oculto es una infracción de directrices | | Migas de pan | Deben coincidir con el rastro visible | Las rutas divergentes simplemente se ignoran | | hreflang | Recíproco en cada página del conjunto | Las etiquetas unidireccionales hacen que se descarte todo el grupo | | Códigos hreflang | El mismo código en el HTML y en el sitemap | Dos códigos distintos para una página rompen el grupo | | x-default | Apunta al selector de idioma o a la versión por defecto | Si falta, se pierde el comportamiento de respaldo | Q: ¿Cómo encuentro problemas de SEO técnico en un sitio existente? A: Rastréelo con un rastreador de escritorio y compare el resultado con su sitemap y con la cobertura de Search Console. Donde las tres listas se contradicen están los problemas: URLs en el rastreo pero no en el sitemap, URLs indexadas pero no en el rastreo, y páginas excluidas por motivos que usted no pretendía. Q: ¿Importan de verdad las cadenas de redirección? A: Sí, por dos motivos. Cada salto añade latencia para las personas, y los rastreadores dejan de seguirlas tras unos pocos. Después de un par de migraciones es habitual encontrar cadenas de cuatro o cinco niveles que nadie planeó. Redúzcalas para que cada URL antigua apunte directamente al destino final en un solo salto. Q: ¿Debo poner noindex en las páginas de etiquetas y categorías? A: Solo si son realmente pobres. Una página de categoría con una descripción de verdad, una lista curada y enlaces internos es una página de aterrizaje legítima y a menudo potente. Una página de etiqueta con dos entradas y sin texto es inflación del índice. Juzgue cada plantilla por si responde a una consulta que alguien hace de verdad. Q: ¿Qué rompe hreflang más a menudo? A: Las etiquetas no recíprocas. Si la página en inglés lista la alternativa en español pero la española no lista la inglesa, el grupo se descarta. El segundo fallo más común es declarar un código en el HTML y otro distinto en el sitemap para la misma página. Genere ambos desde la misma fuente para que no puedan divergir. ## WordPress, Webflow o desarrollo a medida https://websitedevelopment.biz/es/guides/wordpress-vs-webflow-vs-a-medida Actualizado el 2026-08-07 · CMS Para una web de empresa, casi todas las decisiones se reducen a estas tres. No son competidoras en un sentido simple: encajan con equipos distintos, presupuestos distintos y distinta disposición a asumir mantenimiento. Esta guía las compara por modelo operativo, coste a tres años y dificultad de salida, que son los factores que de verdad deciden si la elección acaba funcionando. ### Las tres en una tabla El resumen, antes del detalle. | Modelo | Código abierto autogestionado | Creador visual alojado | Su código, su alojamiento | | Edición | Buena, familiar para muchos | Control visual excelente | Tan buena como la construya | | Quién lo mantiene | Usted | El proveedor | Usted | | Extensibilidad | Ecosistema de plugins enorme | Limitada, mejorando | Ilimitada | | Rendimiento | Depende mucho de la construcción | Generalmente bueno | Tan bueno como pague | | Coste de funcionamiento | Alojamiento más plugins más desarrollo | Suscripción por sitio | Alojamiento más desarrollo | | Salida | Acceso total a la base de datos | La exportación es limitada y con pérdidas | Es su código | ### Dónde es genuinamente fuerte cada una Elegir por la fortaleza que encaja con su situación es más fiable que elegir por la debilidad que teme. - WordPress: sitios de contenido, blogs, sitios que necesitan un plugin concreto, equipos con conocimientos de WordPress y todo aquello donde un ecosistema grande ahorra desarrollo propio. - Webflow: sitios de marketing centrados en el diseño donde el control visual importa y no hay quien mantenga infraestructura. También bueno para equipos que necesitan sacar páginas de aterrizaje rápido. - A medida: aplicaciones, integraciones inusuales, objetivos estrictos de rendimiento o accesibilidad, o un sitio que es en sí el producto. El desajuste más común es un equipo pequeño eligiendo desarrollo a medida para un sitio de presentación. No es un error técnico; es simplemente dinero que rendiría más invertido en contenido. ### Coste a tres años, con honestidad Forma aproximada más que cifras precisas, para una web de empresa mediana. | Construcción | Bajo a medio | Bajo a medio | Alto | | Alojamiento | Bajo a medio | Incluido en la suscripción | Bajo a medio | | Licencias y plugins | Continuo, sube con el tiempo | Incluido, por tramos de uso | Mínimo | | Mantenimiento | Medio, continuo | Bajo | Medio | | Tiempo de desarrollo para cambios | Bajo en contenido, medio en funciones | Bajo | Medio | | Coste de riesgo | Intrusión si no se parchea | Cambios de precio y política del proveedor | Dependencia de una persona clave | ### Dificultad de salida Lo difícil que sea marcharse debería formar parte de la decisión, porque determina si la elección es reversible. - A medida: la más fácil en principio, porque tiene el código, la base de datos y el alojamiento. El riesgo es la documentación y si alguien más puede trabajar con ello. - WordPress: sencillo. El contenido exporta limpio; el trabajo está en reconstruir lo que hacían los plugins. - Webflow: la más difícil. Puede exportar HTML y CSS estáticos, pero el contenido del CMS, los formularios y las interacciones no vienen con ello, así que salir es reconstruir. Haga la pregunta de la salida durante la selección, no durante una disputa. Es la pregunta más barata de hacer y la más cara de haberse saltado. Q: ¿Cuál es mejor para SEO? A: Las tres pueden ser excelentes y las tres pueden ser malas. Lo que importa es HTML renderizado en servidor, control sobre títulos y canónicas, URLs limpias, sitemaps, datos estructurados y velocidad. WordPress le da plugins para esto, Webflow lo trae incorporado con algunos límites, y a medida le da control total y responsabilidad total. La calidad de la construcción pesa más que la elección de plataforma. Q: ¿WordPress es inseguro? A: El núcleo de WordPress se mantiene activamente y es razonablemente seguro. Casi todas las intrusiones vienen de plugins desactualizados, temas abandonados y credenciales de administración débiles. Un WordPress parcheado con pocos plugins y doble factor va bien; un sitio con cuarenta plugins que nadie actualiza no, y eso es una decisión de mantenimiento y no una propiedad de la plataforma. Q: ¿Webflow aguanta un sitio grande? A: Maneja bien sitios de contenido moderados y tiene límites en el número de elementos del CMS y en la estructura de colecciones que conviene contrastar con su modelo de contenido real antes de comprometerse. Para un catálogo grande y complejo o mucha lógica propia suele ser la herramienta equivocada, no porque sea floja sino porque no apunta a eso. Q: ¿Cuándo compensa el desarrollo a medida? A: Cuando el sitio hace algo específico de su negocio contra lo que las herramientas estándar se resisten: un configurador, un flujo de reserva inusual, integración profunda con sus sistemas operativos, o requisitos estrictos de rendimiento y accesibilidad. El diseño distintivo por sí solo rara vez es motivo suficiente, porque un tema propio sobre un CMS lo consigue por mucho menos. ## SEO básico en desarrollo web: qué construir desde el principio https://websitedevelopment.biz/es/guides/seo-basico-desarrollo-web Actualizado el 2026-08-07 · SEO Buena parte del SEO no es marketing en absoluto: son decisiones tomadas durante el desarrollo que son baratas al construir y caras después. La estructura de URLs, la estrategia de renderizado, el enlazado interno y los metadatos editables caen todos en esa categoría. Esta guía cubre qué construir desde el principio, aproximadamente en orden de lo doloroso que resulta añadirlo después. ### Asegúrese de que el sitio se puede rastrear e indexar Todo lo demás es irrelevante si los buscadores no pueden alcanzar ni leer sus páginas. Aquí también se concentran los errores del día del lanzamiento. - El robots.txt de producción permite el rastreo. La copia de preproducción no debe desplegarse con él. - Ninguna etiqueta noindex despistada arrastrada desde preproducción. - Cada página tiene una URL canónica autorreferenciada y hay un único nombre de host canónico. - El contenido está en el HTML o se renderiza en el servidor. Si solo aparece tras ejecutar JavaScript, la indexación se vuelve más lenta y menos fiable. - Un sitemap XML que liste solo URLs indexables y canónicas, no variantes filtradas ni paginadas. - Cada página indexable tiene al menos un enlace interno. Las páginas huérfanas apenas se rastrean. - Códigos de estado coherentes: 200 para páginas reales, 404 para las que faltan, 301 para las movidas. El fallo de lanzamiento más común de esta lista es el robots.txt de preproducción llegando a producción. Compruébelo desde fuera de su red el día del lanzamiento. ### Estructura que los buscadores puedan leer Las decisiones estructurales son las dolorosas de cambiar después, porque cambiarlas implica redirecciones y perder señales acumuladas. | Patrón de URL | Corta, minúsculas, con guiones, estable | Alto: redirecciones y señales perdidas | | Jerarquía de encabezados | Un H1, sin saltarse niveles | Bajo | | Enlazado interno | Centros que enlazan a detalles y de vuelta | Medio | | Paginación | Enlaces rastreables, no solo JavaScript | Medio | | Navegación facetada | noindex en las combinaciones de filtros | Alto: la inflación del índice tarda en limpiarse | | Versiones de idioma | URLs con prefijo más hreflang recíproco | Muy alto | ### Metadatos que su equipo pueda editar de verdad Un fallo de construcción habitual es generar títulos y descripciones desde una plantilla sin forma de sobrescribirlos. Seis meses después marketing necesita cambiar el título de una página y la respuesta es un ticket de desarrollo. - Etiqueta title editable por página, con un valor generado por defecto que sea razonable. - Meta descripción editable, con un contador de caracteres visible en el CMS. - Título, descripción e imagen de Open Graph editables para los enlaces compartidos. - Datos estructurados en las plantillas que los admitan: Article, Product, FAQ, Breadcrumb, Organization. - Un interruptor de noindex por página para las páginas que deban existir pero no posicionar. - Canónica automática, con anulación manual para el caso raro que la necesite. Marque solo lo que de verdad es visible en la página. Datos estructurados que describen contenido que un visitante no puede ver son una infracción de las directrices, no un atajo. ### Velocidad y estabilidad como requisitos de construcción La experiencia de página es parte de la construcción, no un proyecto de optimización posterior. Añadir velocidad a un sitio terminado suele implicar deshacer decisiones en vez de añadir código. | Largest Contentful Paint | Por debajo de 2,5 s | Priorizar la imagen principal, evitar recursos que bloquean el renderizado | | Cumulative Layout Shift | Por debajo de 0,1 | width y height en las imágenes, espacio reservado para incrustaciones | | Interaction to Next Paint | Por debajo de 200 ms | Menos JavaScript y no bloquear el hilo principal | | Peso de página | Lo más bajo que permita el diseño | Formatos de imagen modernos, sin librerías sin usar | | Time to First Byte | Por debajo de 800 ms | Caché, un CDN y consultas de base de datos sensatas | Q: ¿El SEO debe estar en el encargo de desarrollo? A: Las partes técnicas sí: rastreabilidad, estructura de URLs, metadatos editables, datos estructurados, objetivos de rendimiento y el mapa de redirecciones. La estrategia de contenidos y la construcción de enlaces son trabajo aparte con otro perfil. Poner los requisitos técnicos en el encargo hace que se presupuesten en vez de descubrirse tras el lanzamiento, que es cuando cuestan varias veces más. Q: ¿Un framework de JavaScript perjudica el SEO? A: Puede, si las páginas solo se renderizan en el navegador. Los buscadores ejecutan JavaScript pero con retraso y no siempre por completo, así que el renderizado exclusivo en cliente hace la indexación más lenta y menos fiable. El renderizado en servidor o la generación estática eliminan el problema. Para un sitio de contenido, la respuesta más simple suele ser poner el contenido en el HTML. Q: ¿Cuánto tarda en llegar tráfico de búsqueda tras el lanzamiento? A: Para un dominio nuevo, normalmente semanas hasta la indexación y meses hasta posiciones relevantes: los sitios nuevos no posicionan rápido por buena que sea la calidad técnica. Para el relanzamiento de un sitio existente con redirecciones limpias, cuente con dos a seis semanas de fluctuación antes de asentarse cerca del nivel anterior. Q: ¿Necesito un plugin de SEO? A: En un CMS, un plugin es una forma cómoda de dar a la redacción control sobre títulos, descripciones, canónicas y sitemaps. No es una estrategia, y su salida por defecto no sustituye a alguien que decida de qué trata cada página. En un desarrollo a medida la misma funcionalidad suele escribirse directamente y resulta más ligera. ## CMS headless frente a CMS tradicional: ¿cuál encaja en su sitio? https://websitedevelopment.biz/es/guides/cms-headless-vs-tradicional Actualizado el 2026-08-07 · CMS Un CMS tradicional guarda el contenido y genera las páginas. Un CMS headless guarda el contenido y lo entrega por una API, dejándole a usted todo el renderizado. Esa única diferencia se propaga a todo: vista previa, coste, estructura de equipo y con qué rapidez puede alguien de marketing cambiar una página. Esta guía cubre qué gana, qué pierde y dónde está el término medio. ### La diferencia real Todo lo demás se deriva de dónde ocurre el renderizado. | Renderizado | El CMS produce el HTML | Su frontend lo hace | | Plantillas | Dentro del CMS | En su código | | Vista previa | Incorporada y fiel | Tiene que construirla | | Canales | Un sitio web | Web, app, quiosco, lo que pueda llamar a una API | | Libertad de frontend | Limitada por el CMS | Total | | Tiempo hasta la primera página | Rápido | Lento: nada se muestra hasta que lo construya | | Quién hace falta para un cambio de maquetación | A menudo quien edita | Quien desarrolla | ### Qué pierde al pasar a headless Las funciones que un CMS tradicional da gratis son las que se echan de menos, y normalmente se descubren después de tomar la decisión. - Vista previa. Quien edita espera ver la página antes de publicar. En headless es una función que usted construye y mantiene. - Composición de páginas. Organizar bloques en una página es un problema resuelto en los sistemas tradicionales y un desarrollo en los headless. - Menús y navegación. También algo que ahora modela y construye usted. - Formularios. Con la API no viene ningún creador de formularios. - Redirecciones y gestión de URLs. A su cargo. - Ecosistema de plugins. Campos de SEO, sitemaps, redirecciones: todo pasa a ser desarrollo propio. - Velocidad de los cambios pequeños. «Sube esa sección» deja de ser una tarea de edición. El patrón recurrente en los proyectos headless decepcionantes es un equipo de marketing que antes podía cambiar una página solo y ahora abre tickets. ### Cuándo headless es la decisión correcta Encaja con una forma concreta de problema, y fuera de esa forma es flexibilidad cara. | Contenido mostrado en un sitio y en una app móvil | Fuerte: este es el caso central | | Varios sitios compartiendo una fuente de contenido | Fuerte | | Requisitos de frontend que el CMS no puede cumplir | Fuerte | | Ya existe un equipo de frontend dedicado | Bueno | | Sitio de marketing con un equipo pequeño | Malo: pierde velocidad y gana tickets | | Sitio de contenido con cambios frecuentes de maquetación | Malo | | «Es el enfoque moderno» | No es un motivo | ### El término medio A casi todos los sitios les sirve mejor algo entre los dos extremos. - CMS tradicional con tema propio. Control total del frontend, y la vista previa y la composición siguen funcionando. - CMS tradicional usado como headless para una superficie. El sitio lo sigue renderizando el CMS; la app consume una API. - CMS headless con un generador de sitios estáticos. Quien edita tiene buena interfaz y el sitio es estático y rápido; la vista previa requiere trabajo. - CMS híbrido. Sistemas que ofrecen páginas renderizadas y una API, a menudo la respuesta pragmática. - Generador estático con editor basado en git. Coste y riesgo muy bajos para contenido que son sobre todo documentos. Un tema propio sobre un CMS tradicional le da casi toda la libertad de frontend por la que la gente se va a headless, sin renunciar a la vista previa, la composición y el ecosistema. Q: ¿Headless es mejor para el rendimiento? A: Puede serlo, porque usted controla exactamente qué se envía, pero la ganancia viene de la generación estática y de un frontend ligero, no de la API. Un CMS tradicional bien construido con caché adecuada y tema propio también es rápido. El rendimiento es consecuencia de cómo construye, no de dónde está guardado el contenido. Q: ¿Headless es mejor para el SEO? A: Neutral en el mejor caso, y peor si las páginas solo se renderizan en el navegador. Todo lo que necesita el SEO técnico —HTML renderizado en servidor, canónicas, sitemaps, datos estructurados, redirecciones— hay que implementarlo uno mismo en headless, mientras que los sistemas tradicionales tienen plugins maduros. Headless va bien para SEO con disciplina y decepciona sin ella. Q: ¿Puede quien edita previsualizar contenido en headless? A: Sí, pero lo construye usted: un modo de vista previa en el frontend que obtenga el contenido en borrador y lo muestre. Presupuéstelo de forma explícita. Los proyectos que se saltan la vista previa acaban con equipos de edición publicando en producción para ver cómo queda algo, que es justo lo que un CMS debería evitar. Q: ¿Cuánto cuesta headless frente a tradicional? A: La construcción inicial suele ser mayor, porque está construyendo el frontend más las funciones que un CMS tradicional incluía. Los costes de funcionamiento pueden ser menores, sobre todo con generación estática. La diferencia mayor a largo plazo es que más cambios rutinarios requieren tiempo de desarrollo, un coste continuo que no aparece en el presupuesto de construcción. ## ¿Necesita un sistema de diseño para su sitio web? https://websitedevelopment.biz/es/guides/sistema-de-diseno-para-webs Actualizado el 2026-08-07 · Diseño web Un sistema de diseño es un conjunto de componentes reutilizables y las reglas para usarlos. En un sitio grande con varias personas haciendo cambios elimina muchísima toma de decisiones duplicada. En un sitio de presentación de cinco páginas es un coste sin retorno. Esta guía cubre dónde está la línea, qué contiene de verdad un sistema mínimo útil y qué hacer cuando un sistema completo no se justifica. ### Cuándo se paga y cuándo no El valor viene de la repetición: la misma decisión tomada una vez en lugar de cuarenta, y de forma coherente. Si no hay repetición, tampoco hay valor. | Sitio de presentación de cinco páginas, un diseñador, cambios raros | No: una página de guía de estilo basta | | Un sitio, varias plantillas, cambios ocasionales de contenido | Ligero: tokens y una hoja de componentes | | Sitio más aplicación compartiendo marca | Sí: la superficie compartida es donde aparece la deriva | | Varios sitios en una organización | Sí: este es el caso más claro | | Pruebas A/B frecuentes y páginas de campaña | Sí: la velocidad de montaje es la recompensa | | Reconstrucción prevista dentro de un año | Todavía no: construya el sistema con la reconstrucción | ### El sistema mínimo útil Casi todo el beneficio viene de un núcleo pequeño. Esto se construye en días, no en meses, y basta para casi todos los sitios que necesitan uno. - Tokens: color, escala tipográfica, escala de espaciado, radios, sombras, puntos de ruptura, con nombre y no como números fijos. - Tipografía: niveles de encabezado y estilos de texto con su comportamiento adaptable. - Botones y enlaces: todos los estados: normal, hover, foco, activo, deshabilitado, cargando. - Controles de formulario: campo, selector, área de texto, casilla, opción, más estilos de error y de ayuda. - Tarjetas y listas: los dos o tres contenedores de contenido repetidos que su sitio usa de verdad. - Navegación: cabecera, pie, migas de pan, paginación. - Respuesta al usuario: estado vacío, estado de error, estado de carga, mensaje de éxito. Los estados son la parte que se salta y la que más importa. Un componente definido solo en su estado normal devuelve cada caso límite a quien lo esté implementando. ### El coste de mantenimiento que nadie presupuesta Un sistema de diseño es un producto con usuarios, y necesita un responsable. Sin él deriva: el sitio gana componentes que el sistema no tiene, el sistema conserva componentes que nadie usa, y al cabo de un año la gente trabaja rodeándolo en vez de con él. - Alguien lo posee y decide qué entra. Un sistema en manos de un comité deja de cambiar. - Una vía documentada para proponer un componente nuevo, para que la gente lo amplíe en vez de esquivarlo. - Versionado, para que un cambio no altere en silencio todas las páginas a la vez. - Una auditoría periódica de lo que hay en el sitio en producción y no en el sistema: esa brecha es la medida de salud. - Borrado. Los componentes sin uso son coste, no valor. ### Alternativas más ligeras Si no hay caso para un sistema completo, existen pasos más baratos que capturan gran parte del beneficio de coherencia. | Propiedades personalizadas CSS para color, tipografía y espaciado | Horas | Cualquier sitio: este es el suelo | | Una única página de guía de estilo viva dentro del propio sitio | Un día | Sitios pequeños con colaboradores ocasionales | | Biblioteca de componentes en el CMS o en la capa de plantillas | Días | Equipos de contenido que montan páginas | | Framework CSS establecido, con tematización ligera | Días | Herramientas internas y pantallas de administración | | Sistema de diseño completo y documentado | Semanas o meses | Varios productos o varios equipos | Una página de guía de estilo viva dentro del sitio real gana a un documento: usa el mismo CSS, así que no puede desviarse de la realidad sin romperse de forma visible. Q: ¿Puedo usar un sistema de diseño ya hecho? A: Sí, y para herramientas internas suele ser lo acertado: la marca importa poco y obtiene componentes accesibles y probados de inmediato. Para un sitio público de marketing el intercambio es que su sitio se parece a todos los que usan el mismo sistema, así que casi todas las organizaciones lo tematizan mucho, y ahí desaparece parte del ahorro en mantenimiento. Q: ¿Quién debe responsabilizarse del sistema de diseño? A: Una persona nombrada, con aportaciones de diseño y desarrollo. La responsabilidad compartida entre diseño e ingeniería suena colaborativa y en la práctica significa que nadie decide, así que el sistema deja de evolucionar y la gente lo rodea. Quien lo posee no tiene que construirlo todo; tiene que decir sí y no. Q: ¿Cuál es la diferencia entre guía de estilo y sistema de diseño? A: Una guía de estilo documenta la apariencia: colores, tipografías, uso del logotipo. Un sistema de diseño incluye eso más componentes funcionando, sus estados, las reglas para combinarlos y normalmente el código. Una guía de estilo le dice cómo se ven las cosas; un sistema de diseño le da las piezas y le dice cuándo usar cada una. Q: ¿Cómo evito que se quede obsoleto? A: Haga que sea el camino de menor resistencia y audite la brecha. Si usar el sistema es más lento que escribir CSS puntual, la gente escribirá CSS puntual. Liste periódicamente los componentes del sitio en producción que no están en el sistema: una lista que crece significa que el sistema no está sirviendo a quienes construyen páginas, y eso es un problema de diseño del propio sistema. ## Cómo ser desarrollador web: un camino realista https://websitedevelopment.biz/es/guides/como-ser-desarrollador-web Actualizado el 2026-08-07 · Contratar desarrolladores Ser desarrollador web consiste en aprender un conjunto concreto y finito de cosas y después demostrar que termina el trabajo. Aprender está bien documentado y es gratis; la parte difícil es construir pruebas de que alguien debería pagarle. Esta guía cubre un orden realista de aprendizaje, plazos honestos, qué necesita de verdad un portafolio y cómo se encuentran los primeros clientes. ### Qué aprender, en orden El orden importa más que el ritmo. Cada capa hace comprensible la siguiente, y saltarse pasos produce perfiles que copian soluciones pero no diagnostican problemas. - HTML, en serio. Semántica, formularios, accesibilidad. Casi todos los perfiles profesionales tienen huecos aquí y se nota en su trabajo. - CSS, en serio. Modelo de caja, flexbox, grid, propiedades personalizadas, maquetación adaptable. Aquí es donde alguien que empieza puede volverse útil más rápido. - Fundamentos de JavaScript. El lenguaje en sí y el DOM, antes que cualquier framework. - Control de versiones. Git, ramas, pull requests. No negociable para trabajar con nadie. - Cómo funciona la web. HTTP, códigos de estado, caché, DNS, TLS. Esto es lo que separa diagnosticar de adivinar. - Un lenguaje de backend y SQL. Cualquiera de los habituales; los conceptos se transfieren. - Un CMS o un framework, elegido según qué trabajo existe cerca de usted. - Despliegue. Poner un sitio en alojamiento real, con dominio y certificado. La profundidad en HTML y CSS está infravalorada y es vendible de inmediato. Quien sabe construir interfaces rápidas, accesibles y adaptables tiene más salida que quien conoce tres frameworks superficialmente. ### Cuánto tarda de verdad Con un estudio constante de 15 a 20 horas semanales. A tiempo completo esto se comprime, y nada comprime la última fila. | Fundamentos de HTML y CSS | 1–2 meses | Construir una página estática a partir de un diseño | | Maquetación adaptable y bases de JavaScript | 3–5 meses | Construir un sitio pequeño con interacción | | Primer proyecto real | 5–8 meses | Entregar algo para otra persona | | Perfil junior contratable | 8–14 meses | Contribuir a un código con supervisión | | Trabajar de forma independiente | 2–3 años | Llevar un proyecto pequeño de principio a fin | | Perfil sénior | Más de 5 años | Tomar decisiones de arquitectura y acertar a menudo | El paso que la gente subestima es «entregar algo para otra persona». Construir para uno mismo enseña sintaxis; construir para un cliente enseña alcance, comentarios, plazos y que los requisitos cambian. ### Qué debe mostrar un portafolio Tres o cuatro proyectos terminados, en producción y bien explicados ganan a veinte clones de tutorial. Lo que se juzga es si termina las cosas y si entiende lo que construyó. - URLs en producción, no capturas. Tiene que funcionar cuando alguien haga clic. - Un texto breve por proyecto: el problema, sus decisiones, qué haría distinto. - Al menos un proyecto real con una persona usuaria real, aunque no sea pagado: un negocio local, un club, una entidad sin ánimo de lucro. - Pruebas de calidad: rápido, accesible, funciona en móvil. La gente lo comprueba. - Su propio sitio, bien hecho. Es lo primero que cualquiera mira y lo más fácil de hacer bien. - Código en un repositorio público con commits legibles y un README que explique cómo ejecutarlo. ### Encontrar los primeros clientes Los dos o tres primeros son los difíciles. Después, casi todo el trabajo llega por recomendación, lo que significa que terminar bien importa más que el marketing. - Empiece por gente que ya conoce. Casi todo primer trabajo pagado salió así. - Elija un nicho en vez de ser generalista. «Webs para clínicas dentales» se vende mucho mejor que «webs». - Resuelva un problema caro y concreto —velocidad, una auditoría de accesibilidad, una migración— en vez de ofrecerlo todo. - Cobre desde el primer proyecto, aunque sea poco. El trabajo gratis se valora en consecuencia y atrae alcance ilimitado. - Ponga por escrito el alcance y las condiciones de pago antes de empezar, por pequeño que sea el encargo. - Termine como es debido: traspaso, documentación, una oferta de mantenimiento. Eso es lo que produce el segundo cliente. - Pida una recomendación cuando el cliente esté más contento, que es justo después del lanzamiento. Q: ¿Necesito una carrera de informática? A: No, y una buena parte de quienes trabajan en desarrollo web no la tiene. Un título ayuda en algunas organizaciones grandes y en puestos más cercanos a la informática que al desarrollo web. Para casi todo el trabajo web, las pruebas de proyectos terminados importan más que las credenciales, pero sí necesita los fundamentos que le habría dado una carrera, aprendidos de otra forma. Q: ¿Frontend o backend primero? A: Frontend, en casi todos los casos. Ve resultados de inmediato, lo que sostiene la motivación, y es el camino más corto para ser útil a alguien. Cuando sepa construir interfaces bien, los conceptos de backend son más fáciles de aprender porque ya entiende para qué son los datos. Q: ¿Es tarde para empezar? A: No, y quienes cambian de carrera suelen ir bien porque traen conocimiento de un sector que a otros les falta: contables que construyen para contables, docentes que construyen para centros educativos. El mercado de perfiles junior generalistas está muy competido; el de alguien que entiende un sector concreto y sabe construir, mucho menos. Q: ¿Debo aprender un framework pronto? A: Aprenda primero los fundamentos. Los frameworks cambian cada pocos años y son mucho más fáciles de coger cuando entiende qué están abstrayendo. Quien aprendió un framework sin el lenguaje de debajo suele ser eficaz dentro de sus patrones y quedarse atascado fuera de ellos, y ese techo llega rápido. ## ¿Qué es un CMS y de verdad necesita uno? https://websitedevelopment.biz/es/guides/que-es-un-cms Actualizado el 2026-08-07 · CMS Un gestor de contenidos permite que personas que no escriben código creen y modifiquen páginas. Esa es toda la propuesta de valor, y es real, pero no es gratis, porque un CMS es software que hay que alojar, actualizar y proteger mientras exista el sitio. Esta guía cubre qué le da realmente un CMS, cuándo compensa la carga y qué usar cuando no. ### Qué aporta un CMS Más allá de «editar páginas», estas son las capacidades que está comprando, y merece la pena listarlas porque casi todas las decisiones de CMS se toman sin comprobar cuáles necesita. - Editar sin desplegar. Cambiar texto y publicar de inmediato. - Contenido estructurado. Campos en vez de un bloque de HTML, para poder reutilizar y presentar de forma coherente. - Gestión de medios. Subir una vez, usar en cualquier sitio, con redimensionado automático. - Usuarios y permisos. Autoría, edición y aprobación con derechos distintos. - Flujo de trabajo. Borradores, vistas previas, programación, historial de versiones. - Búsqueda y navegación generadas automáticamente a partir del contenido. - Extensibilidad. Formularios, comercio y traducciones a través de un ecosistema. Si solo necesita el primer punto de esta lista y una persona hace cambios dos veces al año, un CMS es mucha maquinaria para un trabajo pequeño. ### La carga que nadie menciona al principio Un CMS es una aplicación en funcionamiento, lo que significa que tiene un perfil de coste continuo edite alguien el sitio o no. | Parches de seguridad | Los sistemas populares se sondean sin parar; las actualizaciones no son opcionales | | Mantenimiento de plugins | Cada extensión es otra actualización y otra posible brecha | | Alojamiento | Una aplicación con base de datos necesita más que archivos estáticos | | Trabajo de rendimiento | Las páginas dinámicas necesitan caché para ir rápido | | Actualizaciones de versión | Las versiones mayores pueden romper temas y personalizaciones | | Formación | Quien edita necesita saber usarlo sin romper maquetaciones | ### Cuándo lo necesita y cuándo no El factor decisivo es la frecuencia de cambio multiplicada por el número de personas que necesitan hacer cambios. | Equipo de marketing publicando cada semana | Sí: este es exactamente el caso para el que existe un CMS | | Sitio de cinco páginas modificado dos veces al año | No: un sitio estático es más barato y más seguro | | Documentación mantenida por el equipo de desarrollo | No: archivos en control de versiones funcionan mejor | | Tienda online | Sí, y una plataforma de comercio en vez de un CMS general | | Páginas de aterrizaje para campañas | Sí: la velocidad de publicación es todo el sentido | | Sitio con varios tipos de contenido y traducciones | Sí: la estructura es en lo que un CMS es bueno | ### Las alternativas Para sitios que cambian poco hay opciones con costes de funcionamiento mucho más bajos y casi sin superficie de ataque. - Generador de sitios estáticos. Contenido en archivos, compilado a HTML, desplegado en un CDN. Rápido, barato y casi nada que atacar, pero editar requiere un flujo técnico salvo que añada una capa de edición. - Generador estático más un editor basado en git. Edición no técnica sobre archivos, conservando la salida estática. - CMS headless más generación estática. Quien edita tiene una interfaz amable; el sitio público sigue siendo estático. - HTML escrito a mano. Perfectamente razonable para un sitio de presentación pequeño que de verdad nunca cambia. - Creador de sitios. La edición es el producto; la contrapartida es la portabilidad y el rendimiento. La vía estática elimina toda una categoría de riesgo: no hay base de datos que inyectar ni acceso de administración que forzar. Para un sitio que cambia cada mes, ese ahorro es significativo. Q: ¿WordPress es la opción por defecto? A: Es la más común, y ser común trae un ecosistema enorme, mucha gente que lo conoce y una cantidad proporcionalmente grande de atención automatizada por parte de atacantes. Encaja bien con sitios de contenido. No es automáticamente adecuado para aplicaciones, comercio complejo o sitios cuyo contenido son sobre todo datos estructurados en vez de páginas. Q: ¿Cuál es la diferencia entre un CMS y un creador de sitios? A: Un CMS gestiona contenido y normalmente deja la presentación a plantillas que controlan usted o su equipo. Un creador combina contenido y maquetación en una única herramienta visual. Los creadores son más rápidos para personas no técnicas y más difíciles de abandonar, porque las decisiones de maquetación viven dentro del producto en vez de en código que es suyo. Q: ¿Puedo añadir un CMS a un sitio estático existente? A: Sí, y es una vía de mejora habitual: o un CMS headless que suministre contenido a las plantillas actuales, o una capa de edición basada en git sobre los archivos existentes. Suele ser menos trabajo que una migración completa, porque las plantillas y las URLs se quedan donde están. Q: ¿Cuántos plugins son demasiados? A: No hay número fijo, pero cada plugin es una actualización que aplicar, un posible conflicto y una posible vulnerabilidad. Una disciplina útil es justificar cada uno frente a lo que aporta: si ahorra una hora al año y necesita atención trimestral, le está costando. Los sitios con cuarenta plugins casi siempre llevan varios que nadie sabe explicar. ## Preguntas que hacer a un desarrollador web antes de contratar https://websitedevelopment.biz/es/guides/preguntas-para-un-desarrollador-web Actualizado el 2026-08-07 · Contratar desarrolladores Casi todas las preguntas de una primera llamada van sobre tecnología, y la tecnología es la parte que menos importa para que el proyecto salga bien. Las preguntas que predicen el resultado van sobre proceso, propiedad y qué ocurre cuando algo se tuerce. Esta guía lista esas preguntas, agrupadas por lo que revelan, con una nota sobre cómo suena una buena respuesta. ### Sobre el trabajo en sí Establecen si han entendido su proyecto o están describiendo su oferta estándar. | ¿Qué preguntas tienen sobre nuestro negocio? | Cualquiera. El silencio aquí es la señal negativa más fuerte que existe | | Enséñeme un sitio en producción de nuestra escala | Una URL, no una imagen; idealmente no su pieza estrella | | ¿Qué harían distinto de nuestro sitio actual? | Observaciones concretas, es decir que lo han mirado | | ¿Cuál es la parte más arriesgada de este proyecto? | Una respuesta honesta: normalmente contenido o integraciones | | ¿Qué no incluye este presupuesto? | Una lista concreta ofrecida de buen grado | | ¿Cuánto tardará y qué lo determina? | Un calendario con dependencias, no una cifra suelta | ### Sobre el proceso Separan a quien tiene una forma de trabajar repetible de quien improvisa. - ¿Dónde se guarda el código y tendremos acceso desde el primer día? - ¿Cómo llega un cambio de su máquina al sitio en producción? - ¿Dónde revisamos el trabajo antes de que salga en línea? - ¿Cada cuánto veremos avances y en qué forma? - ¿Quién exactamente hará el trabajo y qué pasa si no está disponible? - ¿Cómo prueban: navegadores, dispositivos, accesibilidad, rendimiento? - ¿Qué necesitan de nosotros y para cuándo? La pregunta del despliegue es la más reveladora de todas. Una respuesta que implique arrastrar archivos a un cliente FTP le dice que no hay control de versiones, ni preproducción, ni forma de revertir. ### Sobre lo que pasa después El periodo por el que nadie pregunta durante la presentación y que a todo el mundo le importa seis meses después. - ¿De quién son el código, el dominio y las cuentas de alojamiento tras el lanzamiento? - ¿Qué soporte se incluye tras el lanzamiento, durante cuánto tiempo y qué cuenta como defecto? - ¿Cuánto cuesta después un cambio pequeño y cuál es el plazo? - ¿Ofrecen mantenimiento, qué incluye y recibimos un informe? - Si dejamos de trabajar juntos, ¿qué recibimos y con qué rapidez? - ¿Puede otra persona retomar esto? ¿Qué documentación existe? - ¿De qué servicios de terceros dependerá el sitio y quién los paga? ### Respuestas que deberían terminar la conversación Poco frecuentes, pero conviene reconocerlas de inmediato. | «Garantizamos posiciones en la primera página» | Nadie puede; es ignorancia o deshonestidad | | «El dominio lo guardamos en nuestra cuenta» | Le convierte en rehén | | «No necesita preproducción, tenemos cuidado» | Todo el mundo tiene cuidado; eso no es un proceso | | «En sitios pequeños no usamos control de versiones» | Sin historial, sin poder revertir, sin una segunda persona | | «El precio solo vale si firma hoy» | Las tácticas de presión predicen la relación de trabajo | | «El SEO va incluido», sin detalle | O no significa nada o se está insinuando un servicio aparte | | «Ya iremos viendo los detalles sobre la marcha» | Con precio cerrado, eso se convierte en su problema | Q: ¿Cuál es la pregunta más útil? A: «¿Cómo llega un cambio de su máquina al sitio en producción?» Cualquier profesional competente la responde en una frase, y la respuesta revela si existen control de versiones, preproducción, revisión y reversión. Todo lo demás de la lista de proceso tiende a deducirse de ahí en una dirección o en otra. Q: ¿Debo preguntar por tecnologías concretas? A: Solo donde tenga una restricción real: un sistema existente, una plataforma que su equipo ya usa. Por lo demás la tecnología es su decisión, y preguntar por ella invita a una respuesta diseñada para impresionar. Pregunte por los resultados que produce: cuánto de rápido, cuánto de mantenible, quién más podría trabajar con ello. Q: ¿Cómo compruebo bien una referencia? A: Pregunte por un problema en vez de por la satisfacción: «¿qué salió mal y cómo lo gestionaron?». Todo proyecto tiene algo. Una referencia que no puede nombrar nada o tuvo un proyecto trivial o no está siendo del todo franca. Pregunte también si volverían a contarles para un proyecto mayor, que es una pregunta más afilada que si quedaron contentos. Q: ¿Es de mala educación preguntar por propiedad y terminación? A: No, y un proveedor profesional lo espera. Ambas partes ganan sabiendo dónde están, y las respuestas son cortas. La incomodidad ante estas preguntas es en sí información: normalmente significa que el acuerdo estándar le favorece menos de lo que debería. ## Accesibilidad web: qué arreglar primero https://websitedevelopment.biz/es/guides/guia-accesibilidad-web Actualizado el 2026-08-07 · Diseño web El trabajo de accesibilidad tiene una lista larga y un conjunto corto de cosas que explican casi todas las barreras reales. Empezar por la lista corta pone usuarios reales en su sitio rápido; empezar por una auditoría completa suele producir un documento que nadie ejecuta. Esta guía cubre qué arreglar primero, cómo probarlo usted mismo en una tarde y por qué los widgets de superposición no son el atajo que venden. ### Los arreglos de mayor efecto Son las barreras que impiden completar tareas por completo, en vez de hacerlas un poco más difíciles. Arréglelas antes que nada de una lista más larga. - Acceso por teclado. Cada elemento interactivo alcanzable con Tab y operable con Intro o Espacio, en un orden sensato y con un anillo de foco visible. Si el sitio solo se puede usar con ratón, nada más de esta lista importa. - Alternativas textuales. Texto alternativo con sentido en las imágenes que aportan información; alt vacío en las decorativas. Un alt ausente no es lo mismo que uno vacío. - Etiquetas de formulario. Un