viernes, 15 de noviembre de 2013

Velocidad de carga: cómo incrementar un 100% el tráfico a tu página web (II)

En la entrada anterior mostraba una serie de gráficas, basadas en datos empíricos recabados por Google Analytics, en las que se observaba como las mejoras en el rendimiento y en el tiempo de carga de las páginas del portal de búsqueda de mapas Looking4Maps se tradujeron en un incremento de tráfico del 100%, ocasionado por la mejor valoración  que de esta web de mapas hizo el buscador Google, y en un importante aumento de los ingresos recabados por publicidad. En esta entrada, continuación de la anterior, voy a enumerar cuales han sido las técnicas de optimización aplicadas.

  1. Utiliza una herramienta de diagnóstico: Google Page Insights.

    En primer lugar, antes de optimizar a ciegas, lo conveniente es detectar dónde optimizar. Y si uno de los objetivos de optimizar, además de mejorar la experiencia de usuario de nuestros visitantes, es que Google nos ponga una buena nota y así aparezcamos antes en sus resultados de búsqueda, parece razonable utilizar la herramienta de medición de rendimiento Google Page Insights. Para muestra  la nota que Google Page Insights pone ahora mismo al buscador de mapas Looking4Maps.
  2. ¡ Es la base de datos, estúpido!

    En una aplicación web que va a soportar mucho tráfico, y que almacene sus datos en una base de datos relacional (y en la mayoría de los casos MySQL) la base de datos es el principal cuello de botella. Si vuestra web está basada en un gestor de contenidos o plataforma de publicación, como pueden ser WordPress, Joomla, o Drupal, o en algún software de tipo genérico para gestión de foros, comunidades, etc. es probable que los accesos a la base de datos ya estén muy optimizados, pero aún así, estos serán el principal cuello de botella. La base de datos te da muchas cosas (datos ordenados, prevención ante corrupción de los mismos, facilidad de consulta, etc.) pero a cambio, penaliza en el uso de memoria y en el rendimiento. 

    Looking4Maps está programado íntegramente por mí, en PHP, así que al principio los accesos a la base de datos no estaban muy optimizados.  Si éste también es tu caso, y trabajas con tablas grandes (ahora mismo el buscador de mapas tiene indexadas más de 600.000 entradas), desnormaliza, evita los JOINs, evita consultas anidadas, asegurate de que creas índices en aquellas columnas a partir de las que haces consultas, etc. De cara e mejorar el tiempo de carga de una página, es preferible hacer varias consultas muy rápidas, que una única consulta pero más lenta. Por tanto, el contenido principal de la página se puede cargar con una única consulta a la tabla principal de contenido, y contenidos relacionados existentes en otras tablas se pueden cargar de forma asíncrona mediante peticiones AJAX, que no penalizarán el tiempo de carga de la página.

    Cuando trabajamos con un hosting compartido este factor, la velocidad de ejecución de las consultas a la base de datos, cobra todavía una mayor importancia. La razón es que en un hosting compartido cada cuenta de cliente tiene limitado el número simultáneo de conexiones a la base de datos que puede realizar. Supongamos que nuestra web está en un hosting compartido, y que nuestro proveedor nos permite tener 30 conexiones simultáneas a la base de datos. Si nuestras consultas tardan en ejecutarse, o nuestro tráfico es elevado, puede darse el caso de que no queden conexiones disponibles, por lo que las páginas que quieran hacer uso de la base de datos tendrán que esperar a que se liberen conexiones.

    Y este es precisamente el problema relacionado con la base de datos que pueden sufrir los usuarios de productos como WordPress, en los que las consultas sí que están muy optimizadas. Por muy optimizadas que estén nuestras consultas, el número de conexiones que podemos tener con la base de datos es finito, mientras que el número de usuarios que pueden visitar nuestro sitio web no lo es (en términos de órdenes de magnitud ;) ).

    La solución a este problema pasa por cachear los contenidos de la web, en memoria una pequeña cantidad de los contenidos más accedidos, y en fichero todos los contenidos que nuestra cuota de almacenamiento nos permita. Para Wordpress hay disponibles varios plugins de cache. Para Looking4Maps, desarrollado en PHP, he utilizado la libreria PHPFastCache que permite cachear en memoria y también en una base de datos intermedia SQLite. Algunos frameworks de desarrollo PHP como Code Igniter también permiten cachear, tanto los resultados de consulta a base de datos (caché de datos) como las páginas generadas a los usuarios (caché de vista). ¡Todo sea por minimizar las veces que accedemos a la base de datos!
     
  3. Habilita la compresión GZip de tu servidor web.

    Cuando un navegador solicita una página web a un servidor, en realidad se está descargando decenas, incluso cientos, de pequeños recursos en forma de ficheros, a través del protocolo http. Esto lo podeis ver con herramientas de desarrollador como Firebug o Chrome.


    Cuanto mayor sea el tamaño que tienen estos archivos, mayor será el tiempo que el navegador necesita para descargarlos y por tanto el tiempo necesario para cargar la página desde la que se descargan.

    Afortunadamente, los servidores web están preparados para comprimir estos ficheros (normalmente GZip) y los navegadores para detectar que el servidor permite acceder al contenido comprimido, pedirlo comprimido, y descomprimirlo.

    Si usais un hosting con el panel CPanel, podeis habilitar esta opción en la sección "Software / Services" y entrando en la pantalla "Optimize website". Ahí, podrás optar por comprimir ciertos tipos de contenidos o comprimirlo todo.


    Los archivos de imágen ya suelen utilizar buenos algoritmos de compresión, así que lo ideal es comprimir archivos de texto: html, js, css, etc.

  4. Utiliza CloudFlare CDN (Content Delivery Network).

  5. Una CDN (red de distribución de contenido) es una red de ordenadores distribuída por todo el mundo, que se encarga de cachear tus contenidos estáticos, está diseñado para servirlos por tí a muy alta velocidad (con la que aligera de trabajo a tu servidor) y que además sirve estos contenidos a tus usuarios desde el servidor más cercano a su localización geográfica, con lo que disminuye el "número de saltos" por la red que deben realizar estos contenidos hasta llegar a tus usuarios. En la siguiente figura vemos la distribución de servidores por el mundo del CDN CloudFlare.



    ¿Por qué recomiendo CloudFlare? Es el CDN que yo he utilizado, y además de ofrecer un servicio básico gratuito, ofrece una serie de servicios adicionales de valor añadido que también tienen un impacto directo sobre el tiempo de carga de vuestra web. Una vez que el CDN se descarga nuestro contenido estático, y antes de servirlo desde el servidor más próximo a nuestros usuarios, aplica una serie de optimizaciones de rendimiento sobre dichos archivos.
  • "Minimiza" al vuelo los caracteres innecesarios de ficheros de texto, llegando a reducir su tamaño un 20 %, con el consiguiente ahorro en los tiempos de descarga. 

  • Utiliza las características de almacenamiento local de los navegadores modernos (basadas en html 5) para cachear en el cliente.

  • Ajusta automáticamente las cabeceras http de respuesta de los servidores para que den instrucciones a los navegadores sobre cómo deben cachear los recursos servidos, para minimizar el número de peticiones http que éstos le realizan.
  • Modifican el código HTML de las páginas servidas por las webs originales, para que los recursos que bloqueen la carga de la página (archivos javascript, etc) se carguen al final, de forma que parezca que la página se carga más rápido. 

  • Combina múltiples ficheros javascript en un único fichero, de forma que en lugar de a través de múltiples peticiones http se sirvan a través de una única petición.

Con estos sencillos pasos he conseguido la sensible mejora de tráfico descrita en la entrada anterior. Todavía quedan algunos pasos, especialmente de cara a optimizar la carga de la web para dispositivos móviles, pero parece claro que el retorno de inversión en optimizar la carga de una web es inmediato en términos de posicionamiento en Google.

 


 







Velocidad de carga: cómo incrementar un 100% el tráfico a tu página web (I)

El objetivo de todo creador de una web es que ésta sea utilizada: todos queremos que nuestra web tenga mucho tráfico, que muchas personas la visiten al cabo del día.

Está claro que el primer factor que determinará que una web tenga un tráfico elevado es que su contenido tenga calidad, y despierte el interés de los usuarios. En este sentido, www.lookingformaps.com pretende convertirse en el "Google de los Mapas", localizando e indexando las principales fuentes de mapas existentes en Internet, y ofreciendo a los usuarios un buscador que les permita localizar  rutas, tracks GPS, mapas o guías turísticas y posteriormente descargarselas para planificar sus viajes o excursiones.

No obstante, que un producto sea bueno no es suficiente para que la gente lo "compre", es necesario que la gente lo conozca. Y en el caso de la web, todos en mayor o menor medida nos hemos acostumbrado cuando buscamos algo a entrar en Google y poner dos o tres palabras relacionadas con el mismo. Para muestra un botón: en los últimos cinco meses, en torno al 75 % del tráfico de www.lookingformaps.com procede de búsquedas  de Google.



En este sentido, está claro que para que una web tenga un tŕafico alto, un requisito indispensable es que aparezca en los primeros lugares de los resultados de búsquedas mostrados por Google, para aquellas "palabras clave" relacionadas con los contenidos de dicha web.

Google, para decir "cómo ordena" las páginas webs que va a mostrar como resultado de una búsqueda, tiene en cuenta múltiples criterios: la relevancia que se le da a esa web medida a través del número de links que apuntan a ella, la coincidencia de las palabras de búsqueda con el contenido de la web, etc. Los creadores de sitios web intentan tener en cuenta todos estos factores, que Google ha hecho más o menos explícitos a través de sus Directrices para Webmasters, y optimizar sus páginas para que le gusten a Google y el buscador les de una nota alta: es lo que se conoce como el SEO (Search Engine Optimization).

Pero para Google, no solo es importante que el contenido que una página ofrece sea de calidad, y tenga relación con la búsqueda hecha por el visitante. Google da mucha importancia a que la "experiencia de usuario" que va a tener quien visite esa página sea buena, y un factor muy importante en dicha experiencia de usuario es la velocidad de carga de la página.

Ahora bien ¿hasta cuanto de importante es que una web cargue rápido, para que Google la recompense con un lugar superior en sus resultados de búsqueda?

En los últimos meses he hecho una serie de pruebas para "Looking for Maps", y la verdad es que los resultados obtenidos han sido muy reveladores: la reducción en los tiempos de carga de las páginas de la web ha supuesto como mínimo un incremento del 100% en el tráfico del sitio web, y como efecto secundario, prácticamente un incremento del 100% en los ingresos por publicidad.


 En la gráfica de Google Analytics se pueden observar dos momentos clave:
  1. En el que se produce un primer incremento de tráfico, ligado a una serie de optimizaciones básicas en el código del buscador de mapas.
  2. En el que se produce un segundo "salto" cuantitativo en el número de visitas, ligado a una serie de optimizaciones de rendimiento.
Quizás podamos observar mejor estos "saltos" en el tráfico de LookingForMaps.com si en vez de ver la curva diaria de visitas, más sujeta a fluctuaciones, vemos la curva semanal en esta otra gráfica, en la que también se aprecia mejor como el tráfico semanal en términos de número total de visitas únicas semanales se ha duplicado (de menos de 5.000 a más de 12.000).


Aunque no sea una "regla de proporcionalidad", que siempre se cumpla, lo cierto es que la cuantía de ingresos en publicidad es altamente dependiente del número de visitas de una web, siendo habitual que el número de anuncios en los que hacen clicks nuestros visitantes esté en una orquilla de entre el 0,5 % y el 1,5 %, con lo que el aumento del tráfico se traduce también en un aumento de ingresos por publicidad de la web, como podemos ver también en la siguiente gráfica de ingresos de Google Adsense.



En la siguiente entrada detallaré cuales son las medidas de optimización que he aplicado en la carga de las páginas de lookingformaps.com para mejorar su rendimiento. Simplemente, como dato final, esta gráfica conseguida con la herramienta de Google para Webmaster, en la sección "Rastreo / Estadísticas de Rastreo".



 Se puede ver como el tiempo medio de carga se ha reducido a la mitad, si bien aparecen picos. Estos picos responden a momentos concretos en los que el tráfico ha sido muy elevado, muy por encima de la media. Descontando estos picos, se observa como la "curva" se estabiliza, más cerca del eje de las Xs.




jueves, 24 de octubre de 2013

Mapas de leyendas: la Cova Simanya


Lo cierto es que la geografía de los paises del mundo está plagada de leyendas relacionadas con lo sobrenatural y lo oculto.

En el Parc Natural de Sant Llorenç del Munt i l'Obac se encuentra  la cima del Montcau. La Cova Simanya es una de las más visitadas de las 163 cavidades catalogadas que hay en este macizo, y con sus 372 metros de longitud es la más larga. Esta cueva estuvo habitada desde el Neolítico hasta épocas medievales, y sobre ella hay muchas leyendas, que hablan de ella como un nido de bestias y de extrañas aves. Incluso se afirmaba que escondía dentro una ciudad subterranea. Otra leyenda nos cuenta que el sacerdote Ermendia, en el siglo XVII, se aventuró en el interior de la cueva Simanya hasta encontrar en una gran plaza, un montón de estiércoles frescos, que lo hicieron sospechar de la existencia de una gran bestia, supuestamente un Dragón. También decía que en el interior de la cueva había plazas y calles, como de un pequeño pueblo, donde había hombres y niños desnudos esperando ser la ofrenda para el Dragón.



En este video de Youtube puedes ver el interior de la cueva....parece remontarnos miles de años atrás, a la época de los hombres de las cavernas.

viernes, 27 de septiembre de 2013

Virtual Tour of Dutch History

Virtual Tour of Dutch History Map


En este otro mapa, de gran calidad visual, tenemos un recorrido turístico de interés histórico, en el que se geolocalizan lugares y acontecimientos de relevancia, como por ejemplo la casa de Ana Frank, en Amsterdam, la leyenda de Laurens Koster Printing, el castillo Muiderslot, Utrech, el Veluwe, Ribe Viking Center, etc.

Recomendable descargarse el mapa, en formato KML, y realizar el tour navegando por los distintos puntos de interés haciendo uso de Google Earth.

Virtual Tour of Dutch History:  http://www.lookingformaps.com/mapa.php?mapa=mapas-www-ikimap-com-virtual-tour-of-dutch-history

Recorrido virtual de interés histórico en formato KML: http://www.lookingformaps.com/mapa.php?mapa=mapas-www-ikimap-com-virtual-tour-of-dutch-history

martes, 10 de septiembre de 2013

Mapas para encontrar fruta gratis en tu ciudad

La cartografía está de moda. Ya no es terreno exclusivo de técnicos cartógrafos, geógrafos, o ingenieros de diferentes disciplinas (agrónomos, arquitectos, etc.)

Y es que la necesidad de orientarnos en el territorio en el que vivimos, y de encontrar (localizar) cualquier cosa en dicho territorio siempre ha existido en la historia de la humanidad. La aparición primero de herramientas como Google Maps / Google Earth, y luego la eclosión de los Smart Phones con GPS incorporado ha permitido que cualquiera pueda "cartografiar" su entorno, indicar a los demás dónde encontrar hechos, cosas o fenómenos que sean de su interés-

Una de las pequeñas "alegrías" que me da mantener LookingForMaps.com es la de revisar las estadísticas de acceso al portal, y descubrir nuevos mapas (que yo desconocía) que visitan los usuarios conducidos por Google.



http://www.lookingformaps.com/mapa.php?mapa=frutas-en-espacios-p-blicos-de-montevideo


Para muestra un botón, tenemos este mapa para ubicar árboles frutales en espacios públicos de la ciudad de Montevideo, Uruguay.

El mapa muestra la ubicación de higueras, granados, menta, nísperos, árboles cuya posición ha sido compartida por los voluntarios que se han encargado de construir el mapa.

Seguiré desgranando por el blog alguno de estos mapas que han despertado mi atención.

jueves, 2 de mayo de 2013

Do we stop to think how people come to our maps on the Internet?


Lately spanish speaking web mapping developers community is very active, producing a series of awesome web mapping applications. 

One of the latest applications  I had known is http://www.spaininbooks.com/ a mashup that combines maps produced by ArcGIS Online API, pictures of landmarks and points of interest from Wikimedia Commons and the Amazon API to locate books to buy. Its author, Aitor Calero, is well known in the spanish speaking GIS community, especially through his participation in RedIRIS GIS mail list.
 
http://www.spaininbooks.com/
 
Last summer, practically coinciding with the publication of www.lookingformaps.com was published another social mapping platform, http://natmaps.com/ whose most outstanding feature is, imho, the visual quality of its maps compositions.
 
http://natmaps.com/ Application to build web maps.

Both applications offer a sensational user experience.  They're completely optimized for users who open their browser, visit a web page knowing previously its address, offering them high quality graphics, and a good usability,  whre everything is a map.

However, the question would be how users search for geographic information on the Internet? This question was left in the air last summer in MapBrief blog, in its post "How the Public Actually Uses Web Local Government Maps: Metrics from Denver ".  In it, the author offers a number of statistics on how users access the Denver local gobernment geoportal, and finish with a number of interesting conclusions.

To provide a fresh vision to this debate, we will rely on Looking4Maps user access data, collected with the web analytics tool Google Analytics, recognizing  that Looking4Maps is far from reaching the levels of usability of NatMaps, SpainInBooks or extended solutions as CartoDB or MapBox.
 
From August 8, 2012, date on which came into operation Looking4Maps, 33,245 unique users have visited the site, and of these, only 13.69% did it by writing http://www.lookingformaps.com in their browser . In contrast, 71.23% of visits come from users who performed searches on a search engine.  If we compare this data with data provided by MapBrief post, we must conclude that are not too different: 60% in the case of Denver.

We can conclude that the vast majority of users who come to our website made it through Google, so it's critical that our website will be friendly to Google,  it is essential that our web mapping projects will do a few search engine optimization task . Let's see two examples:
  • If we search in Google "site: spaininbooks.com" the engine only shows 46 results. A visit to the website of SpainInBooks.com shows that the number of books and monuments of its database is of several hundreds, but the application is not designed to allow Google to discover this information.
  • If we do the same search for the portal NatMaps, "site: natmaps.com" , in this case we get 184 results, but the information provided by the search engine, is not at all descriptive and user friendly: all the titles of the pages are the same ("natmaps - Social Mapping"), and URLs are not self descriptive about the content behind them. It doesnt invite the user who has searched for information through Google to click on them.
For SpainInBooks, making the application more friendly to search engines force a change in the system architecture. As it is designed using the same metaphor of conventional GIS applications, providing detailed information on points of interest on the map in internal dialogues. It Would have to evolve it so that each item of information, each point of interest and each of the related books, will be accessible through its own and unique URL, because that is what search engines store:  URLs and descriptive metadata about the information behind these URLs
.
http://spaininbooks.com/ shows the detail information using modal dialogs, not addressable by a unique URL, which makes it difficult for search engines.


The task of optimizing NatMaps to be more friendly to search engines seems simpler: you just have to change the title of the maps (html attribute "title"), to be unique and representative of each map, and exchange URL to be more  autodescriptive (instead of the hexadecimal string that uses right now) and that each map has a description, in the form of the html tag "meta description".

 

And a tip ...


Did you know that Google in the information displayed to users of the search engine is based on the content of certain HTML tags that indexes the contents?

It is essential to pay attention to the content of the labels "title", "meta name = 'description'" and keywords, as well as the friendliness of the URL that identifies our resort.


Did you know that youy can help Google to find the contents of your web application?

 To do this, create one or more XML files according to a format provided by Google called "sitemaps".  Within each sitemap, we should create an entry for each URL that we want Google to include in its index.

jueves, 11 de abril de 2013

¿Nos paramos a pensar cómo la gente llega a nuestros mapas en Internet?

Últimamente la comunidad de desarrolladores hispana de aplicaciones web "espaciales" está muy activa, produciendo una serie de aplicaciones de web mapping realmente impresionantes.

Una de las últimas aplicaciones de las que he tenido conocimiento ha sido http://www.spaininbooks.com/ un mashup que combina mapas producidos por el API de ArcGIS Online, imágenes de monumentos y puntos de interés de Wikimedia Commons, y el API de Amazon para la localización y venta de libros.  Su autor, Aitor Calero, es bien conocido en la comunidad SIG hispana, especialmente a través de su participación en la lista de distribución especializada en Sistemas de Información Geográfica de RedIRIS.

http://www.spaininbooks.com/ Estupendo mashup geográfico basado en ArcGIS Online, el API de Amazon y Wikimedia Commons.


El verano pasado, coincidiendo prácticamente con la publicación de www.lookingformaps.com se publicó otra plataforma de mapas sociales, http://natmaps.com/ cuya característica más destacable es, en mi opinión, la gran calidad visual de los mapas compuestos con ésta.


 http://natmaps.com/ Aplicación para construir mapas en la web.

Ambas aplicaciones ofrecen una experiencia de usuario sensacional. Están completamente optimizadas para que los usuarios que abran su navegador, y tecleen de memoria la dirección web asociada, obtengan una gran calidad gráfica, y una buena usabilidad, siempre teniendo en cuenta que siguen una metáfora visual muy parecida a la de las aplicaciones SIG convencionales: todo al alcance de un mapa, o un mapa que contiene toda la información.

No obstante, cabe preguntarse ¿Es así como los usuarios buscan información geográfica en Internet? Esta pregunta ya se dejó en el aire el pasado verano en el blog MapBrief, en su entrada "How the Public Actually Uses Local Government Web Maps: Metrics from Denver". En ésta, el autor ofrece una serie de estadísticas de cómo los usuarios acceden al geoportal municipal de la ciudad de Denver, USA, y acaba obteniendo una serie de conclusiones muy interesantes.

Por aportar una visión "fresca" a este debate, nos basaremos en los datos de la web Looking4Maps, recabados con la herramienta de analítica web Google Analytics, y recalcando siempre que en ninǵún momento pretendo poner Looking4Maps como ejemplo de nada, reconociendo que no deja de ser un experimento, lejos de alcanzar las cotas de usabilidad de NatMaps, SpainInBooks o soluciones más extendidas como CartoDB o MapBox.


Desde el 8 de Agosto de 2012, fecha en la que entró en funcionamiento Looking4Maps, 33.245 usuarios únicos han visitado la web, y de estos, solo un 13,69% lo hicieron escribiendo http://www.lookingformaps.com en su navegador. Por contra, el 71,23% de las visitas provienen de usuarios que realizaban búsquedas en un motor de búsqueda. Si contratamos este dato con el aportado por el blog MapBrief en relación a las visitas recibidas por el SIG en la web de la ciudad de Denver, no difieren demasiado: un 60% para el caso de Denver.

Este dato es fundamental tenerlo en cuenta: la gran mayoría de usuarios que llegan a nuestro sitio web lo hacen a través de Google, por lo que es fundamental que nuestra web sea amigable para Google, si queremos tener éxito, o que al menos los inicios sean menos duros, mientras nos hacemos un nombre o podemos invertir en publicidad.

En este sentido, y en consonancia con lo expuesto en anteriores entradas de este blog, es fundamental que nuestros proyectos de web mapping realicen un mínimo de tareas de optimización para motores de búsqueda. Veamos como muestra dos botones:
  • Si hacemos en Google la búsqueda "site:spaininbooks.com" el motor solo nos muestra 46 resultados. Una visita a la web de SpainInBooks.com demuestra que el número de libros y de monumentos de su base de datos es de varias centenas, pero la aplicación no ha sido diseñada para que Google pueda descubrir esta información.

  • Si hacemos la misma búsqueda para el portal NatMaps, "site:natmaps.com", en este caso se nos muestran 184 resultados, pero la información que aporta el buscador web sobre los mapas no es para nada descriptiva ni amigable para el usuario: todos los títulos de las páginas son iguales ("natmaps - Social Mapping"), y las URLs no son autodescriptivas del contenido del mapa que hay detrás de ellas. No invitan al usuario que ha buscado información a través de Google a hacer click sobre ellas.


En el caso de SpainInBooks, hacer más amigable la aplicación para los motores de búsqueda obligaría a modificar la arquitectura del sistema. Tal y como está diseñado, utiliza la misma metáfora de las aplicaciones SIG convencionales, proporcionando información de detalle sobre los puntos de interés del mapa en diálogos internos. Habría que evolucionarlo para que cada item de información, cada punto de interés y cada uno de los libros relacionados, fuese accesible a través de una URL propia y única, pues al fin y al cabo, eso es lo que hacen los motores de búsqueda: indexar URLs y asociarles metadatos descriptivos sobre la información contenida en ellas.

 http://spaininbooks.com/ muestra la información de detalle mediante diálogos modales, no referenciables mediante una URL única, lo que dificulta el trabajo de los motores de búsqueda.


La tarea de optimizar NatMaps para que sea más amigable para los motores de búsqueda parece más sencilla: tan solo tendría que modificar el título de los mapas (atributo html "title"), para que sea único y representativo de cada mapa, siendo conveniente también que la URL identificativa de cada mapa tenga significado (en vez de la cadena hexadecimal que ahora mismo utiliza) y que cada mapa tenga una descripción, en forma de la etiqueta html "meta description".

En futuras entradas de este blog intentaré seguir profundizando en este tema relativamente novedoso del SEO para mapas.

@lookingformaps