Una landing local merece existir cuando representa una ubicación, mercado o combinación servicio + zona con utilidad propia para el usuario. No basta con cambiar el nombre de la ciudad. La página debe resolver preguntas locales reales, explicar qué se ofrece allí, aportar prueba, contexto operativo, señales de confianza y una ruta de conversión coherente. Para negocios con ubicaciones físicas, cada sede debería tener una página identificable y conectada con su GBP. Para service-area businesses, las city pages pueden competir en orgánico, pero no convierten una ciudad sin dirección real en una ubicación de Maps.
Si nunca hiciste una landing local, piensa en una página que tendría sentido aunque Google no existiera
Una buena página local ayuda a una persona de una ciudad concreta a entender si realmente atiendes allí, qué servicio puede contratar, cómo funciona, cuánto tarda, qué prueba tienes en esa zona y cuál es el siguiente paso. Si la página sólo existe para insertar el nombre de la ciudad diez veces, probablemente no tienes una landing: tienes una puerta de entrada artificial.
Una empresa de climatización que trabaja en Innsbruck y Hall puede tener páginas distintas si explica cobertura, tiempos, servicios, casos, acceso, barrios y condiciones reales de cada zona. Duplicar el mismo texto y cambiar 'Innsbruck' por 'Hall' no crea valor local.
- Location page
- Página dedicada a una ubicación física real de una empresa, normalmente conectada con su dirección, horarios y Google Business Profile.
- City page
- Página orientada a una ciudad o zona donde la empresa presta servicios, aunque no necesariamente tenga una sede física allí.
- Doorway page
- Página creada principalmente para capturar consultas muy parecidas y conducir al usuario hacia el mismo destino sin aportar valor propio suficiente.
- Local intent
- Búsqueda en la que la ubicación forma parte de lo que la persona necesita, de forma explícita o implícita.
- Internal linking
- Enlaces entre páginas del propio sitio que ayudan a usuarios y buscadores a entender relaciones y prioridades.
Google considera doorway abuse crear páginas de regiones o ciudades muy parecidas que sólo canalizan al mismo destino.
La política no prohíbe las páginas locales. Prohíbe crear múltiples páginas sustancialmente similares para cubrir consultas parecidas sin ofrecer una experiencia propia y útil. Google también recomienda describir cada ubicación real como una entidad LocalBusiness cuando corresponde.
Las páginas locales fuertes suelen ganar porque conectan servicio, geografía, prueba y arquitectura; no por repetir ciudad + keyword.
En mercados locales competitivos vemos mejores resultados cuando una página tiene una función clara, enlaces internos relevantes, contenido específico de la zona, prueba real y una relación lógica con páginas de servicio y ubicación. El nombre de la ciudad ayuda a contextualizar; no sustituye la sustancia.
La prueba más útil: ¿seguiría publicando esta página si mañana Google dejara de posicionar city pages?
Si la respuesta es sí porque ayuda a vender, explicar cobertura, mostrar equipo, resolver logística o demostrar experiencia local, probablemente hay una buena razón para que exista. Si la respuesta es no, la página depende demasiado del buscador.
- Una ciudad no merece URL sólo porque tenga volumen de búsqueda.
- Location page y city page no son lo mismo: una representa una sede real; la otra puede representar cobertura comercial.
- Para un negocio con varias sedes, cada ubicación real debería poder identificarse claramente en la web y conectarse con su GBP.
- Para un SAB, una city page puede competir en orgánico, pero no crea proximidad ni una dirección nueva en Maps.
- Cambiar únicamente el nombre de la ciudad entre páginas es una señal clara de arquitectura pobre y riesgo de doorway content.
- Contenido local útil incluye oferta real, logística, equipo, casos, testimonios, preguntas, restricciones y contexto de la zona cuando existen.
- Una página local necesita enlaces internos desde sitios lógicos del sitio, no sólo una lista escondida en el footer.
- Service pages y location pages deben tener roles diferentes para evitar canibalización.
- LocalBusiness schema describe una ubicación; no convierte una city page en una sede real.
- El éxito se mide con impresiones, queries, leads, llamadas, reservas y cobertura local, no con cuántas páginas conseguimos indexar.
Primero: city page y location page no son la misma cosa
Una location page representa una ubicación real: una clínica, tienda, oficina o sucursal donde existe una entidad física que el usuario puede identificar. Normalmente tiene dirección, horario, teléfono, equipo, instrucciones de acceso y un Google Business Profile asociado cuando es elegible.
Una city page representa un mercado o área de servicio. Puede ser completamente legítima si una empresa atiende esa zona y la página ayuda a esa audiencia, pero no debería fingir una presencia física que no existe.
Esta diferencia parece básica y, sin embargo, explica muchos problemas. Cuando una empresa trata 30 city pages como si fueran 30 locations, termina inventando direcciones, clonando contenido o confundiendo al usuario. Cuando trata todas sus sedes reales como una sola home, desperdicia contexto local y dificulta que cada ubicación tenga una representación web clara.
Representa una sede real
- Dirección real
- Horario
- Equipo
- Acceso
- GBP de la sede
Representa cobertura
- Servicio en la zona
- Logística
- Casos locales
- Contexto geográfico
- Conversión sin dirección ficticia
Cuándo una ciudad o ubicación merece URL propia
No empezaría con un Excel de ciudades. Empezaría con una matriz de demanda y utilidad. ¿Existe demanda diferenciada? ¿La empresa realmente opera allí? ¿Hay información que cambia? ¿El usuario toma una decisión distinta por ubicación? ¿Podemos mantener la página? ¿Existe una forma clara de llegar a ella desde la arquitectura?
Una ubicación física casi siempre justifica una página propia cuando tiene datos y operación diferenciados. Una city page necesita un argumento más fuerte: cobertura real + intención suficiente + capacidad de producir contenido y prueba propios.
- Hay sede física, equipo u horario propio.
- Existe demanda local medible y comercialmente relevante.
- El servicio, precio, disponibilidad o proceso cambia por zona.
- Hay casos, testimonios, proyectos, fotos o experiencia real en esa área.
- La página puede integrarse en navegación o arquitectura sin quedar como isla SEO.
- Existe capacidad para actualizarla cuando cambia la operación.
El doorway test: cinco preguntas antes de publicar otra ciudad
Google define doorway abuse alrededor de páginas creadas para consultas específicas y similares que llevan al usuario a una parte más útil del sitio. La forma práctica de evitarlo no es contar palabras únicas: es comprobar si cada URL tiene una función real.
Una página puede tener 800 palabras distintas y seguir siendo doorway si todo ese texto existe sólo para intercalar nombres de barrios. Y una página más corta puede ser perfectamente válida si concentra información local que no existe en ninguna otra URL.
- ¿La página responde algo que no responde otra URL?
- ¿El usuario puede completar una acción útil desde aquí?
- ¿Hay información local verificable y no generada por plantilla?
- ¿La página está integrada en una jerarquía navegable?
- ¿Seguiría teniendo sentido sin el objetivo de rankear por ciudad + servicio?
Arquitectura: decide si tu sitio se organiza por servicio, ubicación o ambos
El patrón correcto depende del negocio. Una cadena de clínicas puede necesitar /ubicaciones/innsbruck/ y dentro explicar servicios disponibles. Una empresa de servicios con cobertura regional puede tener páginas principales por servicio y algunas city pages donde la demanda y el contenido local lo justifican.
El error aparece cuando se cruzan todas las combinaciones sin criterio: servicio × ciudad × barrio × variante. Eso crea cientos de URLs, canibalización y mantenimiento imposible.
Qué servicios o productos existen.
Dónde existe sede, cobertura o demanda real.
Qué necesita resolver la persona.
Qué página será responsable de esa necesidad.
Cómo llegará el usuario y cómo se relaciona con el resto.
Service page vs location page: evita que dos URLs hagan el mismo trabajo
Una service page debería explicar profundamente un servicio. Una location page debería explicar cómo ese negocio opera en una ubicación. Pueden compartir información, pero no deberían competir por exactamente la misma función.
En una clínica multi-location, la página de fisioterapia puede cubrir tratamiento, metodología, indicaciones y FAQs. La página de Innsbruck puede explicar qué servicios están disponibles allí, quién atiende, horarios, acceso y prueba local, enlazando a fisioterapia para el detalle clínico.
Ese reparto reduce duplicación y crea una red de enlaces lógica: ubicación → servicio y servicio → ubicaciones relevantes.
Qué hace realmente local a una landing page
No necesito un párrafo de historia de la ciudad ni explicar cuántos habitantes tiene. Eso suele ser relleno. Quiero información que cambie la decisión del cliente porque está en esa zona.
Lo local puede ser operativo, comercial, visual o probatorio: tiempos de desplazamiento, cobertura, aparcamiento, transporte, equipo, proyectos, testimonios, restricciones, eventos, partners, fotografías, disponibilidad o particularidades del servicio.
- Dirección, horario y contacto cuando existe ubicación física.
- Zonas y barrios realmente atendidos.
- Servicios disponibles específicamente allí.
- Equipo o profesionales de esa sede.
- Casos, proyectos o ejemplos de la zona.
- Fotos propias del local, equipo o trabajo realizado.
- Testimonios vinculados de forma legítima con esa ubicación o servicio.
- Cómo llegar, parking, transporte o instrucciones útiles.
- FAQs que cambian por mercado, clima, regulación o logística.
Title, H1 y copy: usa geografía donde ayuda, no como estampita
Si la página trata sobre fisioterapia en Innsbruck, es perfectamente natural que title y H1 lo expresen. El problema no es usar ciudad + servicio. El problema es creer que repetirlo en cada heading compensa una página débil.
Title y H1 deben describir la página. El resto del contenido debe demostrar que esa descripción es cierta. Prefiero una mención geográfica precisa en puntos importantes y un texto natural a una densidad de keyword artificial.
Internal linking: una landing local importante no debería vivir escondida en el footer
Google descubre páginas a través de enlaces y los usuarios entienden jerarquías por navegación. Si una location page representa una sede importante, debería recibir enlaces desde lugares que tengan sentido: buscador de ubicaciones, navegación, páginas de servicio, contenidos locales y páginas corporativas.
Para city pages de un SAB sería todavía más selectivo. No pondría una lista de 80 ciudades en el footer sólo para distribuir enlaces. Crearía hubs regionales cuando aportan navegación y enlazaría desde servicios o contenidos donde la relación sea útil.
La landing vinculada desde GBP tiene un trabajo especial
Para una empresa con una única ubicación, la home puede ser la mejor URL. Para multi-location, normalmente la página de esa sede ofrece una continuidad mucho más fuerte. El usuario llega desde un perfil local y espera seguir viendo la misma entidad, servicios, dirección, prueba y acción.
No mandaría todos los GBP de una cadena a una home genérica si existen páginas de sede de calidad. Tampoco crearía una location page mínima sólo para tener una URL diferente: la página debe ser útil.
Service-area businesses: city pages sí; ubicaciones imaginarias no
Un SAB puede trabajar en varias ciudades sin tener oficina en cada una. Las city pages pueden ayudar a competir en resultados orgánicos para esas zonas si representan cobertura real y aportan valor propio.
Lo que no hacen es mover físicamente el negocio para el Local Pack. La proximidad sigue siendo una limitación del sistema local. Por eso separo objetivo orgánico de objetivo Maps antes de prometer resultados.
Multi-location: cada sede necesita identidad propia sin romper la marca
La plantilla compartida es normal. No hace falta escribir desde cero política de devoluciones, historia corporativa o todos los servicios comunes. La personalización debe concentrarse donde existe una diferencia real.
Cada página debería dejar inequívoco qué ubicación representa y aportar datos específicos de esa sede. Después, componentes globales pueden mantener coherencia de marca y reducir coste de mantenimiento.
- Nombre de la ubicación y dirección consistente.
- Horarios y contacto correctos.
- Equipo, responsables o departamentos locales.
- Servicios disponibles allí.
- Fotos reales de la sede.
- Reseñas o prueba local cuando sea legítimo.
- Enlace al GBP/mapa cuando ayuda al usuario.
- CTA y proceso de reserva correctos para esa sede.
LocalBusiness schema: describe la entidad que existe, no la ubicación que deseas
Google permite añadir LocalBusiness structured data y recomienda definir cada ubicación local como una entidad propia usando el subtipo más específico aplicable.
Esto tiene mucho sentido en location pages reales. Para una city page sin sede física, no marcaría una dirección ficticia ni inventaría un LocalBusiness para esa ciudad. Structured data debe representar contenido y realidad, no una ambición de ranking.
NAP: coherencia útil, no obsesión por formato idéntico en cada coma
Name, Address, Phone siguen siendo datos fundamentales para identificar una ubicación. En la web quiero información visible y actualizada, especialmente en páginas de sede.
No convertiría pequeñas variaciones tipográficas legítimas en un proyecto de meses. Lo importante es que no haya contradicciones reales: teléfono antiguo, dirección previa, nombre incorrecto o una sede atribuida a otra ubicación.
Prueba local: una de las mejores formas de dejar de parecer una página programática
Fotos propias, casos, testimonios, proyectos, equipo y partners locales hacen dos trabajos. Ayudan a demostrar que la empresa opera realmente en esa zona y mejoran la decisión del usuario.
No necesito fabricar un caso por ciudad. Si no existe prueba local, esa ausencia puede ser una señal de que todavía no hay suficiente sustancia para crear la página o de que el negocio debe empezar a documentar mejor su trabajo.
External links: enlazar recursos locales puede mejorar utilidad, pero no es un ritual de ranking
Si una página de ubicación necesita enlazar parking, transporte público, ayuntamiento, evento o asociación para ayudar al usuario, lo haría. Eso aporta contexto y utilidad.
No añadiría enlaces externos sólo porque una checklist dice que una city page debe tener tres dominios locales. El enlace debe existir por una razón editorial o funcional.
Una landing local que rankea y no convierte sigue siendo una página mediocre
La intención local suele estar cerca de una acción: llamar, reservar, visitar, pedir presupuesto o comprobar disponibilidad. La página debe hacer esa acción fácil y coherente con la ubicación.
En mobile reviso especialmente CTA, teléfono, mapa, horarios, formularios y velocidad. El mejor bloque SEO no compensa una reserva imposible desde el teléfono.
Cómo medir una página local sin engañarte con posiciones aisladas
Mido queries, impresiones, clicks y conversiones por URL en Search Console y analytics. Para ubicaciones con GBP, separo además tráfico e interacciones del perfil. Cuando el objetivo incluye Maps, uso grid tracking para entender la distribución geográfica.
No tomo una posición puntual como verdad universal. Una página puede mejorar cobertura de long-tail local, generar más leads y no mover el head term que el cliente mira cada lunes.
- Impresiones y clicks no-brand por ubicación.
- Número y diversidad de queries locales.
- Leads, llamadas, reservas o ventas por URL.
- CTR y conversión comparados entre sedes.
- Cobertura geográfica cuando hay Local Pack.
- Indexación y canonical elegida para nuevas páginas.
Cuándo consolidar o eliminar city pages
No todas las páginas merecen vivir para siempre. Si después de suficiente tiempo una URL no tiene demanda, enlaces, impresiones, conversiones ni contenido diferenciable, reviso si debe integrarse en una página regional más fuerte.
La poda no es castigo. Es arquitectura. A veces 8 páginas regionales útiles son mejores que 80 city pages vacías.
AI Search: páginas locales claras también facilitan entender entidades y cobertura
Las experiencias generativas siguen dependiendo de información accesible, clara y verificable. Una location page bien estructurada puede expresar dirección, servicios, horario, equipo y relaciones de forma que humanos y sistemas entiendan mejor la entidad.
No crearía una versión GEO separada. Mejoraría la página que ya necesita servir a usuarios, Search y Maps con datos explícitos y corroborables.
Mi checklist antes de aprobar una landing local
Antes de publicar, quiero poder defender la URL desde producto, SEO y experiencia de usuario. Si sólo existe una razón SEO, todavía falta trabajo.
- Tiene una función claramente distinta de otras páginas.
- La empresa realmente opera o tiene sede en esa zona.
- Title y H1 describen con precisión esa función.
- El contenido aporta información local verificable.
- Existe una CTA coherente con la ubicación.
- Recibe enlaces internos desde páginas lógicas.
- No compite innecesariamente con una service page existente.
- Schema representa sólo entidades reales.
- Está incluida en sitemap si queremos indexarla.
- Tenemos una métrica concreta para decidir dentro de unos meses si funciona.
Roadmap 30/60/90 para reconstruir un sistema de páginas locales
En 30 días auditaría inventario, demanda, intención, canibalización y páginas doorway-like. En 60 días construiría o mejoraría las ubicaciones prioritarias, arquitectura y linking. En 90 días mediría qué templates funcionan, consolidaría lo débil y escalaría sólo patrones que demuestran valor.
La secuencia evita el error más común: generar 100 URLs antes de tener una sola página local excelente que funcione como modelo.
Inventario, demanda, roles de URL y riesgos doorway.
Páginas prioritarias, contenido local, schema y enlaces.
Medición, consolidación y expansión basada en evidencia.
La regla final: no construyas páginas para ciudades; construye páginas para personas que están en esas ciudades
La diferencia parece semántica, pero cambia todo. Una página hecha para una keyword local intenta parecer relevante. Una página hecha para una persona local explica por qué el negocio sí es relevante para esa situación.
Cuando arquitectura, oferta, geografía, prueba y conversión están alineadas, la optimización SEO se vuelve mucho más sencilla. Ya no estás tratando de convencer a Google de que existe una diferencia; la diferencia está en la página.
FAQ · SEARCH NOTES
Preguntas frecuentes.
Respuestas directas a las preguntas que conviene cerrar después del análisis. El marcado FAQPage representa este contenido visible; no implica que Google vaya a mostrar un rich result.
01¿Es malo crear una página para cada ciudad?+
No necesariamente. Es problemático cuando las páginas son sustancialmente similares, existen principalmente para captar consultas parecidas y canalizan al mismo destino sin aportar valor propio. Cada URL debería tener una función local defendible.
02¿Qué diferencia hay entre city page y location page?+
Una location page representa una sede física real. Una city page representa un mercado o área donde prestas servicios y puede existir sin una oficina, siempre que no finja una ubicación que no existe.
03¿Una city page ayuda a aparecer en Google Maps en esa ciudad?+
Puede apoyar relevancia web y orgánico, pero no crea proximidad ni una ubicación física nueva. Para Local Pack la distancia y la elegibilidad de la ubicación siguen importando.
04¿Cuánto contenido único necesita una página local?+
No existe un número de palabras. La pregunta correcta es si aporta información, prueba o funcionalidad que no está disponible de la misma manera en otra URL. Reescribir el mismo texto no crea valor por sí solo.
05¿Debo poner ciudad y servicio en el title y H1?+
Cuando describen naturalmente la página, sí. No es necesario repetirlos de forma artificial en todos los headings o párrafos. El contenido debe demostrar la relevancia que title y H1 prometen.
06¿Cada sede debería tener su propia página?+
En multi-location suele ser recomendable cuando cada sede es una entidad real con dirección, horario, servicios, equipo o información propia. La página debe ayudar al usuario y puede conectarse con el GBP de esa ubicación.
07¿Debo usar LocalBusiness schema en todas las city pages?+
No. LocalBusiness debería describir una empresa o ubicación real. No inventes dirección o entidad local para una ciudad donde sólo prestas servicio.
08¿Las páginas locales deben estar en el footer?+
No como única forma de enlazarlas. Las ubicaciones importantes deberían integrarse en una arquitectura navegable y recibir enlaces internos desde páginas relevantes. Evita listas masivas de ciudades creadas sólo para SEO.
09¿Qué contenido local funciona mejor?+
Información operativa y verificable: servicios disponibles, equipo, dirección, horarios, cobertura, logística, casos, fotos, testimonios, acceso y preguntas específicas de esa zona. No hace falta rellenar la página con historia genérica de la ciudad.
10¿Cómo evito canibalización entre service pages y location pages?+
Define roles distintos. La service page profundiza en el servicio; la location page explica cómo se presta en una sede o zona. Enlázalas entre sí en lugar de hacerlas competir por exactamente la misma función.
11¿Cuándo debería eliminar una city page?+
Cuando no tiene demanda, impresiones, conversiones, enlaces ni contenido diferenciable y puede integrarse mejor en una página regional o de servicio más fuerte.
12¿Las landing pages locales ayudan en AI Search?+
Pueden ayudar a que la información sobre ubicación, servicio y entidad sea más clara y verificable, pero no existe una landing GEO especial. La prioridad sigue siendo una página útil, accesible y bien estructurada.
FUENTES Y DOCUMENTACIÓN
Qué respalda esta guía.
Separo lo que está documentado de lo que es observación práctica o criterio propio. Cuando explico cómo funciona Google, priorizo fuentes primarias; cuando hablo de tests de campo, lo presento como evidencia a validar, no como una ley del algoritmo.
Federico Hauer
SEO Strategist con más de una década trabajando en Search con empresas, agencias y proyectos de Europa y Latinoamérica. Su trabajo conecta SEO técnico, contenido, Local SEO, AI Search y negocio.
Ver perfil completo