El Proyecto: Find Emergency Plumber
Hace poco lancé Find Emergency Plumber, un directorio curado de servicios de fontanería de emergencia disponibles 24/7. El proyecto suena simple en la superficie, pero la arquitectura detrás es donde ocurre la magia.
Los números:
- **1.104 páginas estáticas** generadas automáticamente
- **90 ciudades** con listados completos de fontaneros
- **1.251 fontaneros verificados** con puntuaciones de calidad
- **Sanity CMS** para gestión de contenido y blog
- **Dark theme** (diseño estilo Telegram, porque la usabilidad es SEO)
Pero este artículo no es sobre los números. Es sobre lo que aprendí intentando rankear simultáneamente en mercados completamente diferentes con la misma base de código.
Por Qué Multi-Mercado es Complicado (y Por Qué Vale la Pena)
La mayoría de los directectorios que ves online están optimizados para un único país. Tienen sentido: regulaciones diferentes, competencia local, comportamiento de búsqueda distinto.
Pero aquí está el problema: si construyes un directorio robusto en un mercado, el costo marginal de expandirlo a otro es casi cero. El código es el mismo. La infraestructura es la misma. Solo cambian los datos.
Eso significa que si puedes rankear en Estados Unidos, puedes rankear en Reino Unido con el mismo esfuerzo. Y eso es exactamente lo que intenté hacer.
La Stack Técnica: Por Qué Next.js 16 + Sanity + Supabase
Este es el punto donde muchos desarrolladores se equivocan. Construyen directorios con tecnología inadecuada.
Next.js 16 (App Router) fue mi elección porque:
1. Static Generation: Genero 1.104 páginas en build time. Cero latencia en producción. Google ve HTML puro, no JavaScript renderizado. Eso es SEO puro.
2. Incremental Static Regeneration: Cuando un fontanero actualiza su información en Sanity, la página se regenera automáticamente sin necesidad de rebuild completo.
3. TypeScript en modo strict: Con 1.100+ páginas, un error de tipado podría romper cientos de rutas. TypeScript strict me evitó desastres.
Para la base de datos, elegí Supabase (PostgreSQL):
- Almaceno los 1.251 fontaneros verificados
- Consultas rápidas para filtrar por ciudad, disponibilidad, puntuación
- La API REST es perfecta para Next.js
Para el contenido del blog (fundamental para SEO), Sanity CMS v3:
- Interfaz limpia para redactar artículos sobre emergencias de plomería
- Portable Text para contenido flexible
- Integración nativa con Next.js mediante `next-sanity`
El Error Más Costoso: GSC Indexation
Aquí es donde aprendí a golpes.
Lancé el proyecto con confianza. Tenía 1.104 páginas estáticas, todas perfectamente optimizadas. Esperé ranking. Nada.
Reviso Google Search Console y descubro:
- Problemas de canonical duplicados
- Rutas www vs non-www sin redireccionamiento claro
- Vercel estaba bloqueando ciertos assets estáticos
Mi commit del 20 de diciembre lo resume todo: ``` fix: GSC indexation issues - www canonical, redirects, and static asset blocking ```
La lección: No asumir que Google indexará automáticamente. Necesitas:
1. Canonical tags consistentes: Una sola versión de cada página 2. Redirects 301 claros: Si cambias estructura de URLs, redirige 3. Verificación en GSC: Envía sitemap, verifica que se indexan 4. No bloquees assets: Vercel por defecto optimiza imágenes. A veces eso rompe indexación de blogs
El 18 de diciembre tuve otro problema: ``` Fix 402 error: bypass Vercel image optimization for blog/Sanity images ```
Vercel intenta optimizar imágenes automáticamente. Pero si las imágenes vienen de Sanity, ese proceso a veces genera errores 402. La solución: usar `@sanity/image-url` para servir imágenes directamente desde Sanity.
Estrategia Multi-Región: Cómo Rankear en UK y US Simultáneamente
Aquí es donde la arquitectura importa.
Mi estructura de URLs es así: ``` /us/cities/new-york/ /us/cities/los-angeles/ /uk/cities/london/ /uk/cities/manchester/ ```
Cada región tiene su propio árbol de contenido. Eso significa:
1. Google entiende geolocalización: Las páginas `/uk/` rankean en UK, las `/us/` en Estados Unidos 2. Contenido regionalizado: Puedo tener información sobre regulaciones locales diferentes 3. Mismo código, datos diferentes: Una única página de componente Next.js renderiza ambas regiones
La magia está en cómo genero las rutas. Con `getStaticParams()` en Next.js, genero:
- 45 ciudades en UK
- 90 ciudades en US
- Cada ciudad con su propia página
- Cada página con 1.251 fontaneros filtrados por ubicación
Eso es escalabilidad. No estoy escribiendo 1.104 páginas. Estoy escribiendo una plantilla y dejando que Next.js la replique.
El Blog: Por Qué el Contenido es SEO
Tengo 1.104 páginas de directorio. Pero eso no es suficiente para rankear.
Google favorece sitios con E-E-A-T: Experience, Expertise, Authoritativeness, Trustworthiness.
Un directorio vacío de contenido es solo una lista. Un directorio con blog es una autoridad.
Por eso integré Sanity CMS para el blog:
- Artículos sobre "Qué hacer en una fuga de agua"
- Guías sobre "Cómo elegir un fontanero de emergencia"
- Comparativas de servicios por región
Cada artículo linkea a páginas del directorio. Eso crea una red de relevancia interna que Google adora.
Los Commits Recientes: Iteración en Público
Mis últimos cambios muestran exactamente dónde estoy enfocado:
27 de diciembre: ``` feat: add SEO improvements and emergency landing pages fix: use padding-inline for .container to fix Tailwind py-* utility conflicts ```
Añadí landing pages específicas para emergencias. Porque no es lo mismo buscar "plumber" que "emergency plumber at 3am". Ese intent es diferente.
También corregí conflictos de Tailwind CSS. Con 1.104 páginas, un error de spacing se replica en todas partes. Por eso uso TypeScript strict y Tailwind con cuidado.
25 de diciembre: ``` fix: add null-checking for mainImage.asset in blog components ```
Esto es importante: cuando usas un CMS como Sanity, a veces los datos llegan incompletos. Un editor olvida subir una imagen. Tu página se rompe. Por eso necesitas null-checking en cada componente.
Lecciones Aprendidas
1. Static Generation > Dynamic Rendering para SEO
Google prefiere HTML estático. Si puedes pre-renderizar, hazlo.
2. Verifica GSC Constantemente
No esperes 3 meses para descubrir que tus páginas no se indexan. Revisa GSC cada semana.
3. Multi-Región Requiere Arquitectura Limpia
No intentes "hackear" multi-región con redirecciones. Diseña las URLs desde el inicio.
4. El CMS Es Crítico
Sin Sanity, no podría actualizar contenido sin redeploy. El CMS es tu escalabilidad.
5. TypeScript Strict Te Salva Dinero
Con 1.100+ páginas, un error de tipado es un desastre. TypeScript strict cuesta más al escribir, pero ahorra infinito en debugging.
¿Qué Viene Ahora?
Rankear es solo el primer paso. Ahora viene:
1. Validar tráfico: ¿Realmente hay demanda de este servicio? 2. Monetización: ¿Cómo convierto tráfico en ingresos? 3. Escalabilidad: ¿Puedo replicar esto en otros directorios?
Ese es el siguiente capítulo.
Takeaway
Multi-mercado SEO no es magia. Es arquitectura limpia + paciencia + atención al detalle.
Tiene tres componentes:
1. Tech stack correcto: Next.js + Sanity + Supabase 2. Generación estática: 1.104 páginas pre-renderizadas 3. Monitoreo obsesivo: GSC, Search Console, métricas de indexación
Si haces eso bien, rankear en múltiples mercados es cuestión de replicar datos, no reescribir código.
Esto es lo que significa construir en público: documentar no solo los wins, sino también los errores de GSC, los conflictos de Tailwind, los null-checks olvidados. Eso es lo que otros desarrolladores necesitan saber.
