Checklist de SEO técnico para sitios de restaurantes, la auditoría del operador.

Escribe “SEO técnico de restaurantes” en cualquier buscador y los primeros diez resultados están escritos por agencias de SEO, equipos de marketing de plataformas SaaS, o sitios de afiliados que necesitan que compres una herramienta. El consejo es genérico por diseño — tiene que calzar a la vez a un despacho de abogados, a un tablero SaaS y a una clínica dental. El sitio de un restaurante no es ninguno de esos. Las páginas son pocas, la carta carga el peso, el visitante está en un teléfono decidiendo dónde comer en veinte minutos. La auditoría de SEO técnico hecha a la medida de esa realidad operativa es la que sigue: ocho pasadas por el sitio, cada una con un veredicto de sí o no, y una autoauditoría de doce puntos al final que un operador puede correr, anotar, y llevar a una conversación de reconstrucción.

Qué es de verdad el “SEO técnico” (y por qué un restaurante lo necesita)

El SEO técnico es la capa que decide si Google puede leer tu sitio siquiera. Se sienta debajo de las palabras, la carta, las fotos — el trabajo de contenido — y hace una pregunta más simple: ¿puede el rastreador llegar a la página, renderizarla y entender qué es?

Para un restaurante la distinción importa porque el trabajo de contenido y el trabajo técnico suelen estar en manos de personas distintas. El chef-dueño escribe el texto de la carta, el gerente elige las fotos, el sitio web es lo que el constructor entregó. La capa técnica es invisible hasta que deja de serlo — hasta que la página de la carta no aparece para el propio nombre del restaurante, hasta que los nuevos horarios de almuerzo nunca llegan al AI Overview, hasta que la página de reservas carga lo bastante lento como para que el comensal cierre la pestaña. Ninguna de esas fallas es una falla de contenido. Son fallas técnicas con forma de fallas de contenido, que es lo que las hace difíciles de diagnosticar sin un checklist.

Las ocho pasadas de abajo son como el estudio camina un sitio antes de una conversación de reconstrucción. Cada una está hecha a la medida de una pregunta específica que hace el propio rastreador de Google. Si la auditoría pasa las ocho, el sitio no necesita una reconstrucción — necesita trabajo de contenido, que es una pieza de biblioteca aparte. Si la auditoría falla tres o más, la cotización de reconstrucción saldrá más barata que la factura de órdenes perdidas. Para el marco más amplio de SEO local en el que se sienta esto, lee SEO local para restaurantes; para el desglose específico de schema, marcado schema para restaurantes es la pieza acompañante.

La auditoría de velocidad: Core Web Vitals en un teléfono real

Los Core Web Vitals son las tres métricas públicas de experiencia de página de Google: LCP (qué tan rápido se dibuja la imagen principal), CLS (cuánto salta la página mientras carga) e INP (qué tan rápido responde la página a un toque). Las tres se miden en la auditoría móvil.

Los números que Google publica como umbrales “buenos”: LCP bajo 2.5 segundos, CLS bajo 0.1, INP bajo 200 milisegundos. Un sitio de restaurante que pasa las tres en un teléfono Android de gama media está en la banda verde; uno que no pasa ninguna de las tres es la mediana, no la excepción. Las dos métricas anteriores que vale la pena conocer — porque son las que mueven los arreglos de la auditoría — son el Time to First Byte (la velocidad de respuesta del host; sobre 600 milisegundos apunta a un host lento) y el First Contentful Paint (cuando algo aparece por primera vez; bajo 1.8 segundos es bueno).

La forma de correr la auditoría es en PageSpeed Insights: pega la URL, corre la auditoría móvil (no la de escritorio — el móvil es contra lo que Google rankea), y lee las tres métricas arriba de la página. La herramienta también lista los arreglos específicos ordenados por impacto, que es la parte que la mayoría de los operadores se salta. Los tres arreglos de arriba en una auditoría típica de restaurante son los mismos semana tras semana: la imagen del hero es demasiado grande y del formato equivocado, un salto de diseño viene del widget de reservas o del carrusel de prueba social que carga después de que la página renderiza, y un script de terceros — por lo general el de analítica o un widget de chat — está bloqueando la interacción. Cada arreglo es un solo cambio, no una reconstrucción. Para el tablero de verificación que confirma que la auditoría movió las métricas en el campo, mira cómo leer el Google Search Console de tu restaurante.

¿Tu sitio está listo para mobile-first? Las cinco revisiones que corre Google

La indexación mobile-first ha sido la regla por defecto de Google desde 2019: el rastreador lee la versión móvil de tu sitio y rankea con base en eso. Lo que la vista de escritorio hace bien ya no cuenta si la vista móvil no calza.

Las cinco revisiones que corre el propio rastreador de Google — en términos llanos, no en el lenguaje de la documentación — son las que deciden si la auditoría móvil pasa. Primero, la etiqueta meta viewport está en el <head>: la única línea <meta name="viewport" content="width=device-width, initial-scale=1"> les dice a los teléfonos que rendericen la página a ancho de teléfono en vez de hacer zoom a un diseño de escritorio. Segundo, el diseño responsive es la regla, no un sitio móvil aparte — la misma URL, el mismo contenido, el diseño se reacomoda según el ancho de pantalla. Tercero, el tamaño del texto del cuerpo es de al menos 16 píxeles — más chico que eso y iOS Safari hace zoom cada vez que un comensal toca el campo de reservas, rompiendo el diseño al salir. Cuarto, los tap targets — cada botón, cada enlace en una lista — son de al menos 44 por 44 píxeles con espacio entre vecinos; más chico que eso y los toques con dedo gordo mandan el almuerzo a la orden equivocada. Quinto, el contenido es el mismo que el de escritorio. Un sitio móvil aparte que muestra menos que el de escritorio falla la indexación mobile-first por principio, porque Google no puede rankear lo que el rastreador móvil no puede ver.

La revisión que atrapa a más restaurantes es la segunda. Los sitios construidos sobre una plantilla de constructor a menudo se ven pulidos en escritorio y desastrosos en teléfonos porque la plantilla fue diseñada a ancho de escritorio y se reacomodó mal — un menú de hamburguesa esconde los horarios, el botón de reservas se desborda de la pantalla, el PDF de la carta que abre bien en escritorio se vuelve una imagen ilegible y alejada en móvil. Ninguna de esas fallas aparece en la vista previa de escritorio sobre la que el operador construyó el sitio. Todas aparecen en el rastreador móvil de Google, y lo que el rastreador ve es lo que se rankea. El arreglo no siempre es una reconstrucción; a veces es un solo ajuste de CSS. La auditoría es lo que te dice cuál.

Rastreabilidad: qué hacen por ti robots, sitemaps y etiquetas canónicas

Tres archivos chicos deciden si el rastreador de Google puede leer tu sitio siquiera: robots.txt, el sitemap XML, y la etiqueta canónica en cada página. Cada uno es una línea de código que la mayoría de los operadores nunca ha abierto.

Un archivo robots.txt en tudominio.com/robots.txt les dice a los rastreadores qué partes del sitio pueden leer. La mayoría de los sitios de restaurantes necesita exactamente cinco líneas: User-agent: *, Allow: /, una línea en blanco, Sitemap: https://tudominio.com/sitemap.xml. El error más común es una línea Disallow: / sobrante de un entorno de staging, que le dice a cada rastreador que se salte el sitio entero — y que vuelve discutible toda la auditoría de SEO técnico hasta que esa única línea se borra. Abre el archivo en un navegador; si dice “Disallow: /” en su propia línea, la página es invisible para Google por tu propia instrucción, y el arreglo es una edición de una línea.

El sitemap XML en /sitemap.xml lista cada página que quieres indexada más la fecha en que cada una cambió por última vez. Mándalo una vez en Google Search Console (verifica la propiedad primero, pega la URL del sitemap en la pestaña de Sitemaps) y Google lo lee en cada rastreo posterior. Un sitio de restaurante con siete páginas igual se beneficia — las páginas nuevas, las actualizaciones de la carta y una página de eventos refrescada se descubren el mismo día en vez de esperar a que el rastreo orgánico las encuentre. La etiqueta canónica es el tercer archivo, incrustada en el <head> de cada página: <link rel="canonical" href="https://tudominio.com/esta-pagina/" />. Le dice a Google cuál es la URL canónica de la página aun si un parámetro de rastreo o un enlace de campaña mandó al visitante a un duplicado. En un sitio de restaurante donde el widget de reservas le agrega ?source=facebook a la URL, la etiqueta canónica es lo que evita que la página compita consigo misma en el índice.

Los tres archivos juntos son el contrato de rastreo e indexación. Equivócate en cualquiera de ellos y el resto de la auditoría no importa, porque Google no está leyendo las páginas que la auditoría está probando. La buena noticia es que los tres son auditables en cinco minutos — abre las URLs, lee los archivos, arregla los problemas obvios — y los que están rotos suelen estarlo de la misma forma: la línea Disallow del entorno de staging, el sitemap faltante, la canónica ausente. Ninguno de esos es una reconstrucción; los tres son un arreglo de una línea.

El head del HTML: título, descripción, Open Graph, schema — qué es obligatorio vs. opcional

El <head> de cada página es donde Google y los asistentes de IA recogen los metadatos. Cuatro bloques son obligatorios; cuatro más son opcionales. La auditoría es si los cuatro obligatorios están presentes y los cuatro opcionales están llenos donde tienen sentido.

Los cuatro bloques obligatorios en cada página: una etiqueta de título bajo 60 caracteres que nombre la página y el local (“Carta de cena — Tacombi Bethesda”, no “Carta”); una meta descripción bajo 155 caracteres escrita para el clic, no para el algoritmo; el enlace canónico de la sección de arriba; y la etiqueta meta viewport de la sección mobile-first. Si falta cualquiera de los cuatro, la página o no aparece en búsqueda para nada o aparece con un fragmento generado por Google que probablemente no es lo que tú habrías escrito.

Los cuatro bloques opcionales vienen después. Las etiquetas Open Graph (og:image, og:title, og:description) son lo que leen iMessage, WhatsApp, Slack, Facebook y los demás cuando un comensal comparte tu URL — sin ellas el enlace se previsualiza como una caja gris simple, que es la diferencia entre que un amigo-de-un-amigo reserve la mesa o ignore el mensaje. El schema JSON-LD de restaurante — específicamente el tipo Restaurant con las propiedades address, openingHours, menu y servesCuisine — es lo que alimenta los datos estructurados que Google usa para el panel lateral y la cita del AI Overview. Un favicon en cuatro tamaños comunes (16, 32, 192, 512 píxeles) es el ícono chico que aparece en la pestaña del navegador, el marcador, y el resultado de búsqueda de Google — un favicon faltante se lee como un sitio sin terminar de un vistazo. Y los datos estructurados de breadcrumb (BreadcrumbList en JSON-LD) le permiten a Google reemplazar la URL larga del resultado de búsqueda con un rastro limpio.

El schema es la palanca que compone. El HTML simple le dice a Google cómo se ve la página; el schema JSON-LD le dice a Google qué es la página. El restaurante cuya página de inicio está marcada como un Restaurant con la cocina, dirección, horarios y URL de carta correctos es el que se cita en el AI Overview que responde “restaurante italiano en Silver Spring abierto tarde” — porque el modelo puede leer el schema y responder la pregunta literalmente. El restaurante cuya página de inicio es HTML simple tiene que competir solo con la prosa, que es una pelea más dura. Para la caminata completa de schema — qué propiedades van en qué página, cuáles saltarse, y el flujo de la Prueba de Resultados Enriquecidos — mira marcado schema para restaurantes.

Internacionalización: cuándo (y cómo) importa hreflang para un restaurante de un solo local

hreflang es el atributo HTML que le dice a Google qué idioma sirve una página y cuál versión mostrarle a un visitante de búsqueda cuyo navegador está configurado en un idioma distinto. Es necesario solo cuando el mismo restaurante publica páginas en más de un idioma.

Para un restaurante de un solo local solo en inglés, la sección de hreflang es la fácil: sáltala. La etiqueta sirve para emparejar variantes de idioma, no para inventarlas. Para un restaurante bilingüe — un sitio inglés/español en DC, un sitio inglés/francés en Montreal, un sitio inglés/coreano en Annandale — la etiqueta es lo que le dice a Google que mande al buscador hispanohablante a la versión en español de la página de la carta en vez de a la versión en inglés. La forma de la etiqueta va en el <head> de ambas páginas, apuntándose una a la otra, más un x-default para los buscadores cuyo idioma Google no puede identificar: <link rel="alternate" hreflang="en" href="https://tudominio.com/menu/" />, <link rel="alternate" hreflang="es" href="https://tudominio.com/es/menu/" />, y <link rel="alternate" hreflang="x-default" href="https://tudominio.com/menu/" />. El error más común es una etiqueta de un solo lado — la página en inglés apunta a la española pero la española no apunta de regreso. Google lee eso como un par roto y le sirve la página equivocada a cerca de la mitad de los buscadores que de otro modo enrutaría correctamente.

El patrón a recordar para la auditoría: hreflang es la jugada correcta solo cuando el mismo contenido existe en dos idiomas en dos URLs. Un restaurante que traduce su página de inicio y no su página de carta no debería estampar hreflang en la página de inicio — el hreflang sin par manda a Google a buscar una traducción de la carta que no existe, y Google penaliza el par roto mostrando ninguna versión de forma confiable. La respuesta de la auditoría es sí solo cuando ambas páginas son reales, ambas páginas se apuntan una a la otra, y ambas páginas sirven la misma identidad de restaurante. Para la mayoría de los restaurantes angloparlantes de un solo local la sección es un salto limpio, que en sí vale la pena conocer — la auditoría aprueba con un no, no con una ausencia.

Higiene del pie de página: el año, el SSL, los tap targets, los enlaces legales

El pie de página es donde viven cuatro de las señales más chicas, y donde la mayoría de los sitios de restaurantes pierde confianza en el último píxel visible. La auditoría cubre cuatro cosas: el año del copyright, el certificado SSL, los tap targets de los enlaces de contacto, y los enlaces a las páginas legales.

Un año de copyright vencido — “© 2022 Pizzería de José” en un pie de página de 2026 — se le lee a un comensal de fuera de la ciudad como un negocio que pudo haber cerrado durante la pandemia y nunca reabrió. El arreglo es un fragmento de JavaScript de una línea que renderiza el año actual automáticamente: document.getElementById('year').textContent = new Date().getFullYear();. Empareja eso con una señal de última actualización en la página de la carta — un pequeño distintivo de “carta primavera 2026”, un bloque de especiales fechado — y la frescura se lee en segundos. El veredicto de la auditoría: aprueba si el año se renderiza de forma dinámica y la carta tiene al menos un marcador de frescura fechado; falla en caso contrario.

El certificado SSL es el ícono del candado junto a la URL. Un sitio que carga en http:// en vez de https:// muestra una advertencia de “No seguro” en cada navegador moderno, que es suficiente para rebotar una reserva que estaba a punto de convertir. Cada host que vale la pena usar entrega SSL gratis vía Let’s Encrypt; si el sitio no está en HTTPS, el arreglo es un certificado gratuito y una regla de redirección. La tercera revisión del pie de página son los tap targets en los enlaces de contacto — número de teléfono, dirección de correo, el enlace al mapa — que deberían ser de al menos 44 por 44 píxeles en un teléfono con espacio entre ellos. Un número de teléfono renderizado como texto gris chico sin un enlace tel: es un tap target que no funciona; el arreglo es envolverlo en <a href="tel:301-555-0100">. La cuarta es el bloque de enlaces legales — política de privacidad, términos, declaración de accesibilidad — que Google y los asistentes de IA leen como una señal de confianza de que el sitio se está manteniendo. Un pie de página sin bloque legal se lee como un sitio que se montó una vez y nunca se volvió a tocar.

Un pie de página fijo en móvil — una barra delgada fijada al borde inferior de cada página móvil con una o dos acciones clave (Llamar, Reservar, Ordenar) — es la quinta revisión opcional que se gana su lugar en un sitio de restaurante. El comensal que hace scroll hasta media carta quiere actuar con un solo toque del pulgar, no hacer scroll hasta arriba para encontrar el botón de reservas. Ninguna de estas cinco revisiones del pie de página es una reconstrucción. Las cinco son una tarde de ediciones en la plataforma que sea que corra el sitio. La última pieza chica que vale la pena nombrar junto a ellas es una dirección de correo profesional en el enlace de contacto — hola@tudominio.com se lee como un negocio real; una dirección de Gmail en el pie de página de un sitio por lo demás pulido se lee como un proyecto secundario, que es suficiente para perder una consulta de catering ante el siguiente resultado. Para el tratamiento de la página de carta que hace que todo esto importe, mira mejores prácticas de carta en línea para restaurantes.

La autoauditoría de 12 puntos (cierre)

Camina las doce revisiones en orden. Cada una tiene un veredicto de sí o no, codificado por color a la misma paleta verde azulado-advertencia-óxido que Google usa en su propio tablero de Core Web Vitals. Anota un veredicto por revisión; el artefacto es contra lo que una cotización de reconstrucción de seguimiento pondrá precio.

La auditoría toma cerca de una hora la primera vez y cerca de quince minutos en una re-auditoría una vez que las fallas obvias están arregladas. El orden es deliberado — revisiones de cimientos primero (TLS, viewport, robots), revisiones estructurales segundo (títulos, descripciones, jerarquía), revisiones medibles al final (Core Web Vitals). Una falla en los primeros cuatro bloquea la auditoría en el cimiento; una falla en los últimos tres es arreglable con una pasada de rendimiento enfocada.

Lee los veredictos como un grupo, no como doce calificaciones aisladas. Un sitio que pasa las primeras nueve y falla las últimas tres es un problema de una pasada rápida de CSS e imágenes, no una reconstrucción. Un sitio que falla las primeras tres es una reconstrucción porque el cimiento es la parte sobre la que se apila el resto. Un sitio cuya auditoría es mayormente advertencias es el patrón más común — arreglos chicos por todos lados, sin una sola catástrofe — y la jugada correcta ahí es agendar una tarde para caminar las advertencias una a una. Ninguna de las doce revisiones necesita una agencia. Las doce necesitan un veredicto escrito, de tu puño y letra, antes de que empiece cualquier conversación de reconstrucción.