Checklist para lanzar una web: las 7 más importantes a revisar

Vi una lista corta de cosas que hay que dejar resueltas antes de lanzar un producto digital y me di cuenta de que a mi propio sitio le faltaban varias. Así que la usé como checklist, la amplié con lo que fui encontrando y la dejé escrita acá. El sitio está hecho con Next.js 14 (App Router), así que los ejemplos son de ahí, pero la lista aplica a cualquier stack.

Resumen

1. La app y la web, cada una en su dominio

Si hay un producto con login, conviene que viva en app.tudominio.com y que la web pública esté en el dominio principal. Son dos cosas con ritmos distintos: la web se rediseña, se migra o se rompe sin que eso toque al producto. Además las cookies de sesión de la app quedan separadas de las del sitio público.

En mi caso no aplica: el sitio es de contenido y no tiene login. Si algún día hay una app, va en app.trubidata.com.

2. Los mails, en subdominios separados

La reputación de envío se mide por dominio. Si mandás todo desde el mismo, una newsletter marcada como spam puede arrastrar a los mails que el usuario necesita para entrar, como el de recuperar contraseña. La separación habitual es:

• mail.tudominio.com para los mails transaccionales.
• newsletter.tudominio.com para marketing.
• Un dominio aparte si hacés envío en frío, para que ese riesgo no toque al dominio principal.

Cada subdominio lleva sus propios SPF, DKIM y DMARC. Mi sitio hoy no manda mails (los botones de contacto abren WhatsApp), así que no aplica; si sumo una newsletter, va en su subdominio.

3. Sitemap y Search Console

El sitemap es la lista de páginas públicas que querés que Google indexe. En Next.js se genera con un archivo app/sitemap.ts:

import type { MetadataRoute } from 'next';
import { getWikiPosts } from '@/lib/wiki';

const BASE_URL = 'https://www.tudominio.com';

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const posts = await getWikiPosts('es');
  return [
    { url: `${BASE_URL}/es`, changeFrequency: 'weekly' },
    ...posts.map((post) => ({
      url: `${BASE_URL}/es/wiki/${post.slug}`,
      lastModified: new Date(post.date),
    })),
  ];
}

Dos cuidados: incluir solo páginas públicas (nada de borradores ni rutas internas) y no olvidarse de las URLs por idioma si el sitio es bilingüe. El mío termina con 54 URLs.

Después hay que verificar el dominio en Google Search Console. La opción más robusta es "propiedad de dominio" con un registro DNS TXT. Yo lo hice en Hostinger, donde tengo el DNS, y quedó verificado el 14/10/2026. Falta un paso: enviar sitemap.xml en Search Console, que hago cuando el sitio esté en producción.

4. robots.txt que apunte al sitemap

Es el primer archivo que piden los buscadores. En Next.js sale de app/robots.ts:

import type { MetadataRoute } from 'next';

export default function robots(): MetadataRoute.Robots {
  return {
    rules: { userAgent: '*', allow: '/' },
    sitemap: 'https://www.tudominio.com/sitemap.xml',
  };
}

La línea sitemap hace que el mapa no dependa de que alguien lo envíe a mano. Si hay rutas que no querés que se rastreen, se agregan en disallow.

5. Imagen Open Graph

Cuando alguien comparte tu link en WhatsApp, LinkedIn o X, la red busca una imagen en las etiquetas Open Graph. Si no la encuentra, el link sale como un cuadro gris o sin preview, y eso se nota en cuánta gente lo abre.

En Next.js alcanza con un archivo opengraph-image.tsx (o un opengraph-image.png estático) dentro del segmento de ruta. Se genera con ImageResponse, el tamaño recomendado es 1200x630, y conviene tener una distinta para el sitio, las guías y los cursos, además de title y description propios en generateMetadata. Después probás el link en el depurador de cada red, porque cachean agresivamente. En mi sitio hay una para la home, otra por guía y otra por curso.

6. Analítica de eventos

Contar visitas no alcanza. Lo útil es saber qué hace la gente: qué botón toca, qué video reproduce, hasta qué lección de un curso llega. Con eso se ve dónde se traba el recorrido.

En mi sitio uso Google Analytics 4 con @next/third-parties y un helper propio para eventos: cta_click, video_play, code_copy, course_start, lesson_view y course_complete. Solo corre en producción, para que mis pruebas locales no ensucien los datos. Me falta sumar Microsoft Clarity para tener mapas de calor, y va a ir detrás del mismo consentimiento del punto siguiente.

7. La analítica no carga hasta que el usuario acepta

Es el punto que más me hizo cambiar de idea. En España, usar cookies sin informar ni obtener consentimiento (art. 22.2 de la LSSI) es una infracción leve (art. 38.4.g) con multa de hasta 30.000 euros (art. 39); si hay reincidencia dentro de los 3 años pasa a grave, de 30.001 a 150.000 euros. Está en las resoluciones de la AEPD, el regulador español de protección de datos.

El caso que mejor lo ilustra es Vueling: la AEPD la multó con 30.000 euros porque su banner no ofrecía ninguna herramienta para rechazar o gestionar cookies (solo decía que configures el navegador) y tomaba "seguir navegando" como consentimiento. La multa quedó en 18.000 euros por reconocimiento y pago voluntario.

El criterio que la AEPD publica en su guía de cookies es claro en dos cosas: rechazar tiene que estar en la primera capa del banner, con el mismo nivel que aceptar, y no puede haber rastreo antes del consentimiento. No tengo cifras sobre cuántos expedientes se abren ni cómo se detectan; lo que sí sé es que las reclamaciones de usuarios los disparan.

En código, la idea es que el script de analítica no exista en la página hasta que haya un "sí". Un componente cliente guarda la decisión y recién ahí monta GA:

'use client';
import { useEffect, useState } from 'react';
import { GoogleAnalytics } from '@next/third-parties/google';

type Consent = 'accepted' | 'rejected' | null;

export function AnalyticsGate({ gaId }: { gaId: string }) {
  const [consent, setConsent] = useState<Consent>(null);

  useEffect(() => {
    const saved = localStorage.getItem('analytics-consent') as Consent;
    if (saved) setConsent(saved);
  }, []);

  const decide = (value: Exclude<Consent, null>) => {
    localStorage.setItem('analytics-consent', value);
    setConsent(value);
  };

  return (
    <>
      {consent === 'accepted' && <GoogleAnalytics gaId={gaId} />}
      {consent === null && (
        <div role="dialog" aria-label="Cookies">
          <p>Uso cookies de analítica para entender qué contenido sirve.</p>
          <button onClick={() => decide('accepted')}>Aceptar</button>
          <button onClick={() => decide('rejected')}>Rechazar</button>
        </div>
      )}
    </>
  );
}

Los dos botones tienen que pesar lo mismo visualmente. Es un esbozo de la idea, no un componente listo para pegar: falta, por ejemplo, un enlace a la política de cookies y una forma de cambiar la decisión después. En mi sitio el banner tiene Aceptar y Rechazar del mismo peso, la analítica no carga hasta aceptar y un link "Cookies" en el pie permite cambiar la decisión.

Otras cosas que sumé a la lista

• Apex a www con HTTPS válido: que https://tudominio.com redirija a www con un certificado que cubra los dos. A mí se me rompió por un registro DNS sobrante del hosting de dominios.
• Staging fuera del índice: los entornos de prueba no deberían indexarse.
• Título y descripción propios en cada página: sin títulos repetidos.
• Una página 404 propia: con salida al inicio, en vez de la genérica.
• Favicon y páginas legales: privacidad y términos enlazados en el pie.

Cómo lo uso

Dejé la lista en el repo del sitio como checklist reutilizable, con el estado de cada punto. Antes de publicar algo nuevo la recorro de arriba abajo; lleva diez minutos y evita descubrir los problemas después, con el sitio ya en producción.

Fuentes

• Reel original con la lista de 7 puntos (Instagram)
• Resolución de la AEPD sobre cookies (ejemplo de sanción)
• Guía sobre el uso de las cookies, AEPD
• La AEPD impone a Vueling una multa de 30.000 euros, Bird & Bird
• La AEPD multa a Vueling con 30.000 euros por obligar a aceptar cookies, Genbeta