¿De quién es tu web? Dominio, hosting y código explicados

¿A nombre de quién está registrado el dominio?

Cuando un cliente me pregunta "¿de quién es mi dominio y mi web?", lo primero que reviso es el registro WHOIS. Es el registro público que muestra quién figura como titular del nombre de dominio, quién gestiona la zona DNS y qué fechas están asociadas al contrato. Saber quién aparece allí evita sorpresas cuando cambias de agencia o decides migrar a otro servidor.

Para consultar el WHOIS basta con entrar en cualquier buscador de dominios (por ejemplo, who.is o la herramienta de tu registrador) y escribir el nombre del dominio. Los datos que tienes que observar son:

• Registrant Name: la persona o empresa que figura como propietaria.
• Administrative Contact: quien gestiona los asuntos administrativos.
• Technical Contact: quien recibe los avisos técnicos.
• Creation Date y Expiration Date: fechas de alta y vencimiento.
• Registrar: la compañía que emitió el registro.

Ejemplo con www.ejemplo.com:

Domain Name: ejemplo.com
Registry Domain ID: 123456789_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.example-registrar.com
Registrar URL: https://www.example-registrar.com
Updated Date: 2024-03-10T12:00:00Z
Creation Date: 2018-04-15T09:30:00Z
Registry Expiry Date: 2025-04-15T09:30:00Z
Registrant Name: Juan Pérez
Registrant Organization: Restaurante La Bodeguilla
Registrant Email: juan.perez@labodeguilla.com
Admin Email: admin@labodeguilla.com
Tech Email: tech@labodeguilla.com

En el caso de un restaurante del Eixample que me contactó para rediseñar su web, descubrimos que el dominio estaba registrado a nombre del antiguo socio del local, no al propietario actual. Al mostrarle el WHOIS, quedó claro que necesitaba transferir la titularidad antes de que pudiéramos avanzar con el proyecto. Sin esa claridad, cualquier cambio de hosting o de código habría quedado a merced de quien no tenía autoridad para autorizarlo. Si te encuentras en una situación similar, revisa el WHOIS, verifica que el nombre del registrante coincida con tu negocio y, si no, solicita la transferencia antes de seguir. ¿Necesitas ayuda para gestionar esa transición? Puedes contar con nuestro diseño web Barcelona para acompañarte en todo el proceso.

¿Quién aloja tu web? Identificando el hosting

¿Quién aloja tu web? Identificando el hosting

Cuando me llamas porque no sabes quién mantiene tu sitio, lo primero que hago es aclarar que el hosting no siempre está al mismo nombre que el dominio. A veces el proveedor de dominio también ofrece el servidor, pero en la mayoría de los casos son dos entidades distintas. Identificar al host te permite controlar facturas, migraciones y, sobre todo, evitar sorpresas cuando el contrato termina.

Para averiguarlo utilizo herramientas de DNS. Con el comando nslookup o dig puedes obtener la dirección IP asociada al nombre de tu web. Por ejemplo, al ejecutar dig www.tusitio.com obtengo una línea que muestra ANSWER SECTION con la IP 185.12.34.56. Esa dirección es el punto de partida para descubrir quién la posee. Con una búsqueda WHOIS inversa o servicios como IPinfo.io puedes introducir la IP y te devuelven el rango de red y el nombre del proveedor, en este caso XHosting.

• Abre la consola (Windows cmd, Terminal macOS/Linux).
• Ejecuta nslookup o dig seguido del dominio.
• Anota la dirección IP que aparece en la respuesta.
• Introduce la IP en un servicio de búsqueda WHOIS inversa.
• Lee el nombre del operador (XHosting, SiteGround, etc.) y el rango de red.

El ping complementa la información porque muestra la latencia y confirma que la IP responde. Con ping www.tusitio.com obtienes cuatro paquetes y el tiempo medio de respuesta; si los paquetes llegan desde la misma IP que viste en DNS, sabes que no hay redirección oculta, y entonces el proceso de identificación requiere mirar los registros CNAME también.

Te pongo un caso real: el restaurante “La Bodega del Eixample” me contactó porque el contrato de hosting había expirado sin que lo supieran. Con los pasos anteriores descubrí que su web apuntaba a 185.12.34.56, cuyo WHOIS indicaba a XHosting. Al hacer ping confirmé la respuesta desde esa IP y, con esa información, les facilité un presupuesto de migración a un servidor propio bajo su nombre. Así, el dueño recuperó el control total y evitó que el proveedor anterior siguiera facturando.

Propiedad del código fuente: ¿Dónde está tu sitio?

Cuando entrego un proyecto siempre reviso que tú tengas acceso al código fuente. El código es lo que realmente controla tu web: sin él no puedes modificar diseños, corregir errores ni migrar a otro hosting. En la práctica, el repositorio suele estar en plataformas como GitHub, GitLab o Bitbucket, o los archivos pueden estar guardados directamente en el servidor mediante FTP. Si el repositorio está bajo una cuenta ajena, pierdes la capacidad de actualizar sin depender de terceros.

Para localizar el repositorio y asegurarte de que tienes los permisos correctos, sigue estos pasos:

1. Accede al panel de control del proyecto o al correo de bienvenida y busca la URL del repositorio.
2. Abre el archivo .git/config o el README y verifica que la dirección apunte a GitHub bajo la cuenta miempresa.
3. En GitHub, comprueba que tu usuario está añadido como colaborador; de no ser así, solicita al propietario que te otorgue acceso.
4. Clona el repositorio en tu máquina local para confirmar que puedes descargar el código sin errores.
5. Revisa las cabeceras HTTP de tu sitio (por ejemplo con la herramienta curl -I) para identificar la ruta donde están los archivos en el servidor.
6. Si el acceso al servidor se gestiona mediante FTP o SFTP, verifica que el usuario y la contraseña coincidan con los que tienes anotados.

Un caso real: el restaurante "La Tapa" en el Eixample necesitaba una web donde publicar su menú y reservas. El proyecto estaba alojado en GitHub bajo la cuenta miempresa. Al revisar el .git/config descubrí que la URL apuntaba a https://github.com/miempresa/lata. Creé un nuevo usuario de GitHub para el propietario del restaurante, lo añadí como colaborador y le mostré cómo clonar el repositorio y hacer cambios en el menú sin esperar al desarrollador anterior. Con el acceso al código en sus manos, pudieron actualizar el contenido en cuestión de minutos.

Si ahora no sabes si tu código está en tus manos, repasa los pasos anteriores y, si algo falla, ponte en contacto conmigo. Puedo ayudarte a migrar el repositorio a una cuenta que controles y a configurar el acceso en tu hosting. Descubre más sobre cómo proteger tu presencia online en nuestra sección de diseño web.

¿Por qué la titularidad importa?

Cuando me llaman porque su web ya no responde, lo primero que reviso es a quién está registrado el dominio y quién controla el hosting. La titularidad es la llave que te permite renovar, mover o cerrar el proyecto sin depender de decisiones ajenas. Si el dominio está a nombre de un tercero, cualquier cambio en sus políticas, una cuenta bloqueada o un error de facturación pueden dejarte sin acceso de forma inesperada. Además, Google asocia la autoridad del sitio a la continuidad del dominio; una interrupción prolongada perjudica el SEO.

Los principales riesgos que he visto repetirse son:

• Pérdida total del dominio cuando el titular olvida renovarlo.
• Bloqueo del hosting por facturas impagadas o por políticas del proveedor.
• Incertidumbre legal si el dominio se usa para datos de clientes o para facturación.
• Dificultad para migrar el sitio cuando el código está alojado en un repositorio al que no tienes acceso.

Hace dos años trabajé con una tienda de ropa en el Eixample que había dejado el dominio a nombre de su agencia de marketing. Cuando la agencia cerró, la fecha de renovación quedó en el olvido y el dominio expiró. En menos de 48 horas perdieron el acceso a la web, al correo corporativo y a las métricas de Google Analytics. Los clientes que buscaban la tienda recibieron un mensaje de error, lo que provocó una caída abrupta del tráfico y una pérdida de confianza que tardó meses en recuperar, aun después de volver a registrar el dominio.

Si hoy me contactas a ti, que tienes un restaurante en el Eixample, mi primer paso será comprobar que el dominio está a tu nombre y que el hosting está bajo tu control. Te explicaré qué documentos necesitas para transferir la titularidad y cómo configurar recordatorios de renovación. También revisaré que el código fuente esté guardado en un repositorio propio, de modo que, si cambias de proveedor, puedas mover la web sin sobresaltos. Así evitas sorpresas y mantienes la visibilidad online.

Cuando el dominio está a nombre del proveedor anterior

Cuando el dominio está a nombre del proveedor anterior

Me encuentro mucho con esta situación: una pyme o un autónomo que llega a mi estudio de diseño web en Barcelona y descubre que su dominio web no está a su nombre. Lo registró el informático de turno, el anterior diseñador o una agencia, y ahora tú no tienes el control. Esto es un problema, y gordo, porque tu dominio es la identidad digital de tu negocio. Si no lo controlas, dependes de un tercero para renovaciones, cambios o transferencias, y eso es una losa.

El primer paso es contactar a ese proveedor anterior. Debes solicitarles la transferencia del dominio o, en su defecto, un cambio de titularidad. La vía más sencilla es la transferencia, que implica un código de autorización (AUTH CODE o EPP KEY) que te permitirá mover el dominio a un registrador de tu elección. Si se niegan o no responden, la cosa se complica. Entonces, toca un cambio de titularidad oficial, que es más lento y requiere documentación. En España, los proveedores están obligados a facilitar estas gestiones, pero no siempre lo hacen con la agilidad que uno espera. He visto casos donde, por ejemplo, un restaurante del Eixample perdía acceso a su dominio justo cuando más lo necesitaba, por una renovación impagada de un tercero.

Para solicitar la transferencia o el cambio de titularidad, necesitarás lo siguiente:

• Datos de contacto del titular actual: Necesarios para que el registrador verifique la identidad.
• Documentación que acredite tu derecho sobre el dominio: Esto puede ser un contrato de servicio, facturas o cualquier prueba que demuestre que tú eres el legítimo propietario o usuario del dominio.
• Acceso al correo electrónico asociado al dominio: Imprescindible para confirmar la mayoría de las transferencias. Si no lo tienes, será un obstáculo a solucionar.
• El AUTH CODE: Si el proveedor te lo facilita, la transferencia es cuestión de días.

Los plazos varían. Una transferencia con AUTH CODE suele completarse en unos 5-7 días. Un cambio de titularidad sin AUTH CODE, o en caso de disputa, puede alargarse semanas o incluso meses, con idas y venidas de correos y documentos. En WebsBarcelona siempre recomendamos que el dominio esté a nombre del cliente desde el día uno. Es tuya, no de nadie más, y esta autonomía es crucial para evitar futuros quebraderos de cabeza y asegurar la continuidad de tu presencia online.

Recuperar el control del hosting

Cuando me llamas porque el hosting sigue bajo la cuenta del anterior proveedor, lo primero que hago es comprobar quién tiene acceso al panel de control. Normalmente el cliente sólo tiene la información que le dio el anterior webmaster, y sin el usuario administrador no puede tocar la configuración ni renovar el servicio. En esa fase reviso si el correo de recuperación está actualizado y, si no, solicito al soporte del hosting que me lo restablezca mediante la verificación de identidad. Sólo con el acceso al panel puedo iniciar el proceso de recuperación.

Una vez dentro del panel, sigo estos pasos para volver a ser el propietario administrativo:

• Actualizar el correo de contacto y la pregunta de seguridad.
• Crear un nuevo usuario con privilegios de root o super‑admin.
• Asignar ese usuario como propietario de la cuenta y eliminar el antiguo.
• Resetear todas las contraseñas de bases de datos, FTP y panel.
• Exportar una copia completa del sitio (archivos y base de datos).
• Configurar un nuevo servidor y subir la copia.

Si decides dejar el hosting antiguo y pasar a un VPS, el proceso cambia ligeramente. Primero aprovisiono el VPS con el sistema operativo que prefieras (Ubuntu o CentOS) y configuro un firewall básico. Después instalo el stack LAMP/LEMP según la tecnología del sitio, creo los usuarios y bases de datos con los mismos nombres que tenías antes, y copio los archivos y la exportación de la base de datos. Una vez que la web responde en el nuevo servidor, actualizo los registros DNS del dominio apuntándolos al nuevo IP y pruebo que todo funciona antes de cancelar el servicio anterior.

Recientemente ayudé a una pizzería del Eixample que había cambiado de agencia y se quedó sin acceso al panel de su hosting compartido. Tras seguir los pasos anteriores, migramos su sitio a un VPS gestionado en nuestro propio data‑center. En menos de 48 horas la página volvió a estar online, el dueño recuperó el control total y ahora puede añadir menús, promociones y reservar mesas sin depender de terceros. Si te encuentras en una situación similar, lo mejor es actuar rápido, asegurar copias de seguridad y, si no tienes claro el proceso, pedirme una auditoría gratuita para definir los siguientes pasos.

Transferir el código y los repositorios

Transferir el código y los repositorios

Cuando un cliente llega con su web alojada y el código guardado en un repositorio SVN que pertenece al proveedor anterior, lo primero que observo es la falta de acceso directo. Sin credenciales ni permisos, cualquier intento de mantenimiento o ampliación se vuelve una pesadilla. Lo que hago es pedir al cliente que me facilite los datos del servidor SVN y, si es posible, una exportación del historial. Con esa información ya puedo empezar a trasladar el código a un entorno que él controle.

El proceso básico consiste en clonar el repositorio, crear un nuevo repo Git y actualizar todas las referencias que apuntan al antiguo SVN. Primero, ejecuto svn checkout para obtener una copia local del proyecto tal como está en producción. Después, inicializo un repositorio Git vacío, añado los archivos y realizo el primer commit. Con git svn puedo importar el historial de cambios, aunque si el cliente no necesita conservar cada revisión, basta con un commit inicial.

1. Obtener acceso al SVN (usuario, contraseña, URL).
2. Ejecutar svn checkout y guardar la copia en una carpeta segura.
3. Crear un repositorio Git (git init).
4. Añadir los archivos (git add .) y hacer el primer commit.
5. Si se desea historial, usar git svn clone o git svn fetch.
6. Configurar el nuevo remoto (git remote add origin …) y subirlo a un servicio que el cliente controle (GitHub, GitLab, Bitbucket).
7. Actualizar los scripts de despliegue, CI/CD y cualquier referencia a la URL del SVN.
8. Eliminar las credenciales antiguas y documentar los nuevos accesos.

Una vez el repo está en Git, reviso los archivos de configuración (por ejemplo, .htaccess o composer.json) para sustituir rutas que apunten al servidor SVN. También actualizo los hooks de despliegue que, en muchos casos, están codificados para usar svn export. Cambiar esos scripts a git pull o a una pipeline de CI garantiza que el cliente pueda lanzar actualizaciones sin depender de terceros.

Imagina que la pizzería “La Trattoria”, situada en el Eixample, tiene su menú online y reservas gestionadas a través de un sitio creado en 2019. El anterior desarrollador dejó el código en un SVN propio y el hosting en un servidor compartido. Tras migrar a Git y subir el repo a su cuenta de GitHub, el propietario pudo conectar el sitio a nuestro servicio de diseño web y, con un pipeline sencillo, publicar cambios cada vez que actualiza el menú. Ahora el control está en sus manos y cualquier nueva funcionalidad se implementa sin esperas ni dependencias externas.

Checklist de verificación de titularidad

Antes de confiar en que tu web está bajo tu control, revisa una lista de puntos que te garantizan la titularidad completa. Cada elemento te ayuda a detectar si el dominio, el hosting o el código siguen bajo el nombre de otro proveedor o de un antiguo colaborador.

Lista de verificación:

• WHOIS actualizado: Comprueba en la base WHOIS que el registrante del dominio coincida con tu nombre o con la razón social de tu empresa; si aparecen datos de un tercero, solicita la transferencia.
• Acceso al panel de control del hosting: Entra al panel (cPanel, Plesk, etc.) y verifica que el usuario administrador sea tuyo; sin acceso directo, el sitio podría cerrarse sin aviso.
• Repositorio del código fuente: Localiza el repositorio (Git, SVN) y asegura que la URL remota apunte a una cuenta que controles; de lo contrario, los cambios futuros pueden quedar bloqueados.
• Certificados SSL: Revisa que el certificado SSL esté emitido a tu dominio y que el titular sea tu empresa; un certificado bajo otro nombre puede generar advertencias de seguridad.
• Información de facturación: Confirma que los datos de facturación del dominio, del hosting y de los servicios asociados estén a tu nombre; una discrepancia indica que el control está en manos de otro.

Una vez tengas la lista a mano, ve marcando cada punto. Si detectas alguna irregularidad, actúa de inmediato: solicita al registrador que actualice los datos WHOIS, pide al proveedor de hosting que te transfiera la cuenta o migra el código a un repositorio propio. No dejes que una pieza quede fuera del control, porque cualquier interrupción en uno de esos eslabones puede paralizar tu negocio sin que lo notes.

Por ejemplo, el restaurante “Casa del Sol” en el Eixample, Barcelona, tenía el dominio registrado a nombre del diseñador que había creado su web hace tres años. Al cambiar de agencia, el propietario descubrió que el WHOIS mostraba todavía el nombre del diseñador y que el acceso al hosting estaba bajo una cuenta compartida. Tras seguir la checklist, actualizó el WHOIS, recuperó el panel de control y migró el repositorio a su propio GitHub, garantizando que la web sigue funcionando aunque cambie de proveedor.

Próximos pasos y cuándo contactar a un profesional

Si al revisar la titularidad del dominio, el hosting o el código fuente detectas que algo no está claro, es momento de llamarme. Cuando el proveedor anterior desaparece, el acceso al panel de control está bloqueado o el código está disperso en varios repositorios, intentar arreglarlo por tu cuenta suele alargar los plazos y generar errores que afectan al SEO y a la disponibilidad del sitio. Yo, con ocho años de experiencia y más de 200 proyectos, sé identificar rápidamente el punto crítico y plantear la solución más segura. Además, si el dominio está registrado a nombre de una empresa que ya no existe o está bajo un contrato de renovación automática, la intervención de un especialista evita que el sitio caiga sin previo aviso.

Para que pueda actuar sin perder tiempo, reúne la siguiente información:

• Nombre del titular del dominio tal y como aparece en el registro WHOIS.
• Facturas o correos que demuestren la relación con el actual proveedor de hosting.
• Accesos a cuentas de correo vinculadas al dominio y al panel de control del servidor.
• Copias de seguridad recientes del sitio y de la base de datos.
• Listado de terceros que tengan permisos de edición (agencias, freelancers).

Una vez que tienes esos documentos a mano, envíamelos por correo o a través del formulario de contacto. Indica brevemente cuál es el objetivo (recuperar el dominio, migrar el hosting o consolidar el código). Si puedes compartir capturas de pantalla del error o del panel de registro, el diagnóstico se reduce a minutos en lugar de horas. Mantén una línea de comunicación abierta y responde rápidamente a cualquier solicitud de información adicional; eso suele acortar el proceso de unos días a menos de 24 horas. Si el proyecto está alojado en un entorno de desarrollo propio, también envía la URL de acceso y los datos del gestor de versiones (Git, Bitbucket, etc.). Con esa visión completa, puedo planificar la migración sin interrumpir el tráfico.

Recientemente trabajé con un restaurante del Eixample que había cambiado de gestor y había perdido el acceso al panel de hosting. El propietario sólo disponía de la factura del dominio y de una copia parcial del sitio. Con los datos que me facilitó, logré validar la titularidad del dominio, solicitar la transferencia al nuevo hosting y reconstruir el código faltante a partir de los archivos locales. En menos de una semana el sitio volvió a estar online, sin perder reservas ni posicionamiento. El cliente también nos pidió que configuráramos una alerta de caducidad del dominio para evitar futuros sobresaltos; esa pequeña tarea se incluyó en la misma intervención.