Página 404 personalizada: configuración e implementación correctas

Cuando un usuario sigue un enlace roto, el servidor debe devolver el estado 404 Not Found. Pero en proyectos reales esta regla se incumple con bastante frecuencia: el CMS devuelve 200 OK, una redirección lleva a la página de inicio o la página «404» devuelve el código correcto, pero se ve como una pantalla en blanco. Cada una de estas situaciones es un problema distinto, tanto para el SEO como para el usuario.

Una página 404 bien configurada resuelve tres problemas a la vez: indica a Google que la URL no existe; mantiene al usuario en el sitio y le ayuda a encontrar la sección adecuada; y protege el presupuesto de rastreo frente a rastreos desperdiciados. Veamos cada aspecto en orden.

Qué es una página 404

404 Not Found es el código de respuesta HTTP que el servidor devuelve cuando el recurso solicitado no existe. El código indica que el servidor funciona bien y ha resuelto la ruta, pero el documento pedido no está. Así se distingue el 404 del 500 (error del servidor) y del 503 (servicio no disponible).

Una página 404 existe en dos niveles. El nivel HTTP es el código de respuesta en la cabecera que ve el rastreador del buscador. El nivel visual es el contenido HTML que ve el usuario. Ambos niveles importan por igual: un código HTTP incorrecto es un problema de SEO; un diseño pobre es un problema de UX.

La regla principal: devuelve siempre HTTP 404

La primera y más importante regla: una página de error debe devolver el estado HTTP 404 (o 410), nunca 200. Esto se llama «hard 404», en contraposición al «soft 404».

Puedes comprobar el estado HTTP de cualquier página directamente en el navegador: F12 → Network → recarga la página → localiza la primera solicitud → columna Status. O con curl en la terminal:

# Check HTTP status of a page
curl -s -o /dev/null -w "%{http_code}" https://example.com/non-existent-url
# Expected output: 404

# Check full response headers
curl -I https://example.com/non-existent-url

Soft 404 y 410: la diferencia

Además de la «hard 404», existen dos casos relacionados que en la práctica se confunden a menudo: el soft 404 y el estado 410. Entender la diferencia es importante para gestionar bien las páginas eliminadas.

Google también clasifica como soft 404 las redirecciones desde una URL 404 hacia la página de inicio u otra página sin relación. Desde el punto de vista del buscador: el usuario buscaba A, llegó a B y el contenido de B no responde a la consulta. Esto degrada la señal de calidad de la página de destino.

Qué debe contener una buena página 404

Un usuario que llega a una 404 ya está algo frustrado. La función de la página es suavizar esa frustración y darle un siguiente paso claro. Una página 404 eficaz sigue una estructura reconocible.

zoom_in

Lo que no debes hacer en una página 404 es redirigir automáticamente al usuario a la página de inicio mediante JavaScript (window.location.href = '/'). Google puede tomarlo como soft 404: el usuario esperaba A, recibió B y el contenido no es pertinente. Las redirecciones 301 desde URL 404 solo son adecuadas cuando existe una página de sustitución real.

Implementación: Next.js, Nginx, Apache

La configuración de una página 404 personalizada depende de tu stack. Veamos las tres opciones más habituales: Next.js App Router, Nginx y Apache.

Next.js App Router

En Next.js 13+ con App Router, la página 404 personalizada se crea con el archivo not-found.tsx dentro del directorio app/. Para i18n (por ejemplo, con next-intl), el archivo va en app/[locale]/.

// app/[locale]/not-found.tsx
import Link from 'next/link';

export default function NotFound() {
  return (
    <main style={{ textAlign: 'center', padding: '4rem 1rem' }}>
      <h1>404 — Page Not Found</h1>
      <p>The link may be outdated or the address was mistyped.</p>
      <Link href="/">Back to homepage</Link>
    </main>
  );
}

// Next.js automatically returns HTTP 404 for this file.

Para generar la 404 de forma programática (por ejemplo, en una ruta dinámica app/[locale]/blog/[slug]/page.tsx), usa la función notFound() de next/navigation. Al llamarla, el renderizado se interrumpe de inmediato, se devuelve HTTP 404 y se muestra not-found.tsx.

// app/[locale]/blog/[slug]/page.tsx
import { notFound } from 'next/navigation';
import { getArticleDoc } from '@/messages/blog-articles/registry';

export default async function ArticlePage({ params }: { params: { slug: string } }) {
  const article = getArticleDoc(params.slug);

  // If slug does not exist — return HTTP 404 and render not-found.tsx
  if (!article) {
    notFound();
  }

  return <ArticleRenderer article={article} />;
}

// Pages Router: pages/blog/[slug].tsx (legacy approach)
export async function getServerSideProps({ params }) {
  const article = getArticleDoc(params.slug);

  if (!article) {
    // Next.js will return HTTP 404 and show pages/404.tsx
    return { notFound: true };
  }

  return { props: { article } };
}

Nginx

En Nginx, la página 404 personalizada se configura con la directiva error_page dentro del bloque server. Asegúrate de que el archivo 404.html existe en la ruta indicada y de que servirlo no provoca una redirección interna que devuelva 200.

server {
    listen 80;
    server_name example.com;
    root /var/www/html;

    # Custom page for 404 errors
    error_page 404 /404.html;

    # The location for the file itself — returns 404, not 200
    location = /404.html {
        internal;
    }

    # Custom pages for other errors
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        internal;
    }
}

Apache / .htaccess

En Apache, la 404 personalizada se configura con ErrorDocument, ya sea en la configuración principal o en .htaccess.

# .htaccess in the site root

# Custom 404 page
ErrorDocument 404 /404.html

# You can also point to a PHP file
# ErrorDocument 404 /404.php

# Custom pages for other errors
ErrorDocument 403 /403.html
ErrorDocument 500 /500.html

# Enable mod_rewrite for SPA routing
<IfModule mod_rewrite.c>
    RewriteEngine On
    # For React/Vue SPA: all non-existent routes → index.html
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^ /index.html [L]
</IfModule>

PHP (WordPress y otros CMS)

En WordPress, la página 404 personalizada es el archivo 404.php del tema. WordPress devuelve HTTP 404 automáticamente para las URL inexistentes cuando los enlaces permanentes están bien configurados. Si el CMS devuelve 200 en lugar de 404, el problema suele estar en .htaccess o en la configuración del servidor.

<?php
// themes/your-theme/404.php
// WordPress automatically returns HTTP 404
get_header();
?>
<main class="error-404">
    <h1>Page Not Found</h1>
    <p>Try using search:</p>
    <?php get_search_form(); ?>
    <p>Or return to the <a href="<?php echo home_url(); ?>">homepage</a>.</p>
</main>
<?php
get_footer();

Localizar y corregir enlaces rotos

Una página 404 bien configurada es solo la mitad del trabajo. La otra mitad consiste en encontrar todos los enlaces que apuntan a páginas inexistentes y corregirlos. Los enlaces rotos son la causa principal de que aparezcan errores 404 en el índice.

# Find top-20 broken URLs in Nginx/Apache logs
grep ' 404 ' /var/log/nginx/access.log \
  | awk '{print $7}' \
  | sort \
  | uniq -c \
  | sort -rn \
  | head -20

# Example output:
# 143 /old-product-page
#  87 /blog/removed-article
#  34 /wp-login.php  (attack attempts — not critical)

Monitorizar los errores 404

Una auditoría puntual está bien. Pero las nuevas 404 aparecen constantemente: se renombran páginas, se eliminan productos y los sitios externos enlazan a URL inexistentes. Conviene montar una monitorización periódica.

En sitios grandes (más de 10 000 páginas) los logs del servidor son especialmente valiosos: cubren el 100 % de las solicitudes, incluidas las de bots, usuarios y scripts. Search Console solo muestra lo que Googlebot encontró al rastrear: es un subconjunto de la imagen completa.

Lista de comprobación de una página 404 correcta

Estado HTTP

• La página 404 devuelve el estado HTTP 404 (comprobado con curl o DevTools)
• Sin soft 404: la página de error no devuelve 200 OK
• Sin redirecciones por JavaScript desde URL inexistentes hacia la página de inicio
• 410 Gone para las páginas eliminadas en masa sin sustituto
• Redirecciones 301 solo para URL con una página de sustitución pertinente

Contenido de la página

• Mensaje de error claro, con lenguaje sencillo y sin jerga técnica
• Hay un cuadro de búsqueda o un enlace a la búsqueda del sitio
• Hay un enlace a la página de inicio
• Hay enlaces a 2–4 secciones o categorías populares
• La página sigue el estilo visual de la marca del sitio (cabecera, pie, tipografías)

Implementación

• Next.js: creado el archivo not-found.tsx; se llama a notFound() para los slug inexistentes
• Nginx: configurada la directiva error_page 404; el archivo 404.html está marcado como internal
• Apache: ErrorDocument 404 definido en .htaccess o en la configuración principal
• WordPress: existe 404.php en el tema activo
• SPA (React/Vue sin SSR): la etiqueta meta noindex se añade en el cliente en las páginas 404

Monitorización

• Google Search Console conectado y alertas por correo configuradas
• Rastreo periódico con Screaming Frog o equivalente (al menos una vez al mes)
• Logs del servidor accesibles y analizados en sitios con mucho tráfico
• Todos los enlaces internos que apuntan a URL 404 localizados y corregidos

Preguntas frecuentes

Respuestas a preguntas habituales sobre la configuración de páginas 404 que surgen en auditorías y en desarrollo.