El uso del fichero sitemap.xml y robots.txt está muy extendido desde hace muchísimo tiempo en el mundo del posicionamiento web. El primero contiene las URLs del sitio web, facilitando así la labor de indexación para los buscadores, y el segundo representa el caso contrario, las carpetas, ficheros, etc..., que no queremos que sean rastreados ni indexados por los buscadores. A grosso modo, claro, porque luego hay muchas excepciones y casos a tener en cuenta.

Ambos fichero se colocan habitualmente en la raíz del sitio web al que hacen referencia, y en la medida en que actualizamos contenido deben ser actualizados periódicamente para que no pierdan su valor, sobre todo en el caso del sitemap; tanto es así que la mayoría de los gestores de contenidos utlizados para el desarrollo de sitios web tienen sus plugins para generar el sitemap, y normalmente crean el fichero robots por defecto con los directorios que no deben ser rastreados. Incluso existe la posibilidad de crear el fichero sitemap desde sitios online que rastrean nuestra web y generan el mapa por nosotros, como el conocido http://www.xml-sitemaps.com/

Una vez tenemos los ficheros listos, le decimos a Google que están preparados desde las Google Webmaster Tools, y ya tenemos una parte de nuestro SEO realizado con relativamente poco esfuerzo, y si no hay otras complicaciones veremos que Google indexa nuestras páginas con más rapidez, o al menos ese efecto es el que buscamos.

Hasta aquí todo correcto; el uso de estas herramientas es fácil e intuitivo y exigen poco trabajo por nuestra parte, tanto en la instalación como en el mantenimiento posterior, pero, como todo en la vida, las cosas no suelen ser tan sencillas y tienden a complicarse.

Un ejemplo clásico del uso de ambos ficheros

Imaginemos que tenemos nuestro dominio www.dominio.com. Aquí está nuestra web de empresa, con nuestros ficheros sitemap y robots.txt situados directamente en el directorio raíz. Nuestro fichero robots.txt puede ser algo así:

User-agent: *
Disallow: /wp-admin/ 
Disallow: /wp-includes/

Es decir, le decimos a los buscadores que no rastreen ni los directorios wp-admin ni wp-includes. Obviamente, en este caso tenemos una instalación de Wordpress.

Siguiendo con el ejemplo, aunque podríamos haber creado el sitemap con algún plugin como SEO Yoast, hemos optado por hacerlo de forma manual a través de un servicio online, con las siguientes líneas:

<?xml version="1.0" encoding="UTF-8"?>
<urlset 
     xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://www.sitemaps.org/schemas/sitemap/0.9                                                                       
         http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd">
<!-- created with Free Online Sitemap Generator www.xml-sitemaps.com -->
<url>
<loc>http://www.dominio.com/</loc>
</url>
<url>
<loc>http://www.dominio.com/pagina1</loc>
</url>
<url>
<loc>http://www.dominio.com/pagina2</loc>
</url>
<url>
<loc>http://www.dominio.com/pagina3</loc>
</url>
<url>
<loc>http://www.dominio.com/pagina4</loc>
</url>
<url>
<loc>http://www.dominio.com/pagina5</loc>
</url>

El fichero puede contener otros parámetros, pero lo hemos reducido por simplicidad.

Así que, en resumen, nuestro sitio web tiene seis páginas, y los buscadores no indexarán el contenido bajo los directorios wp-admin y wp-includes.

De hecho, podemos acceder a ambos ficheros desde cualquier navegador:

http://www.dominio.com/sitemap.xml

http://www.dominio.com/robots.txt

Múltiples ficheros sitemap y robots

¿Qué ocurre si creamos un nuevo sitio web que va a albergar la tienda online y lo situamos en una subcarpeta?

O dicho de otra manera, creamos una tienda online con nuestro gestor favorito y la situamos en el directorio tienda, http://www.dominio.com/tienda. 

En la subcarpeta tenemos también el fichero robots.txt, con un contenido que podría ser similar a éste, muy típico de gestores como PrestaShop.

# Directories
Disallow: */classes/
Disallow: */config/
Disallow: */download/
Disallow: */mails/
Disallow: */modules/
Disallow: */translations/
Disallow: */tools/

Esta es una situación tan clásica como incorrecta. Las reglas en cuanto al fichero robots.txt son muy claras: sólo puede haber un fichero, y debe estar en la raíz del dominio principal. Es decir, un fichero robots como el que acabamos de ver, en una subcarpeta, será ignorado. Para resolver el problema y que ambos ficheros sea considerados, lo más efectivo en este caso será fusionar los dos en la raíz principal, de la siguiente forma: 

User-agent: *
Disallow: /wp-admin/ 
Disallow: /wp-includes/
# Directories
Disallow: /tienda/*/classes/
Disallow: /tienda/*/config/
Disallow: /tienda/*/download/
Disallow: /tienda/*/mails/
Disallow: /tienda/*/modules/
Disallow: /tienda/*/translations/
Disallow: /tienda/*/tools/

Como vemos, hemos añadido el directorio tienda en las rutas que estaban en el fichero de la subcarpeta para asegurarnos de que no se rastrean esos directorios, y con esto el fichero estaría ya terminado y, ahora sí, cumpliendo con su función.

Por otra parte, podremos tener también en la subcarpeta de la tienda un fichero sitemap.xml similar al que hemos visto anteriormente. En principio, los crawlers pueden leer ficheros sitemap en diferentes subcarpetas, y todos ellos serían interpretados, por lo que la opción no es incorrecta. Eso sí, las URL referenciadas dentro de cada sitemap deben ser de ese misma carpeta o inferiores, nunca de carpetas padre.

Aunque esta alternativa puede ser válida desde un punto de vista técnico, no es muy elegante. Tenemos múltiples sitemap repartidos por la web, con el consiguiente riesgo de fallo, y además, no podremos enviar todas a Google Webmaster Tools, puesto que la herramienta sólo admite un sitemap por dominio.

El fichero de índices sitemap

Para solventar esa problemática, existe una solución mucho más elegante que consiste en la creación de un índice central que haga referencia a todo el resto de sitemaps que tenemos en el sitio web. Dicho fichero se llama sitemap_index.xml, y presenta el siguiente formato: 

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.google.com/schemas/sitemap/0.84">
 <sitemap>
    <loc>http://www.dominio.com/sitemap.xml</loc>
    <lastmod>2014-08-01T18:23:17+00:00</lastmod>
 </sitemap>
 <sitemap>
    <loc>http://www.dominio.com/tienda/sitemap.xml</loc>
    <lastmod>2014-08-01</lastmod>
 </sitemap>
</sitemapindex>

Hemos añadido en el fichero el enlace a los dos sitemap que tenemos en el sitio web. El del sitio principal, y el de la tienda. De esta forma todo el mapa está enlazado a través de un único fichero que podemos enviar a Google Webmaster Tools. 

Conclusiones

Aunque en apariencia sitemap.xml y robots.txt no dan mucho juego, realmente tienen la suficiente potencia para amoldarse a gran cantidad de situaciones. En este ejemplo hemos presentado el caso más clásico de sitio web integrado en una subcarpeta de otro sitio web principal, pero el juego puede seguir hasta el infinito, y más allá.

Ultimamente, hay un rumor, basado en diferentes experiencias, que está circulando como la pólvora por los foros y los sitios especializados de SEO. Al parecer, Google podría haber introducido una modificación en su algoritmo que impediría que un sitio nuevo pudiese alcanzar posiciones altas en los primeros 30 días.

Esta medida estaría pensada para evitar sitios de rápida aparición y desaparición que son creados para conseguir ganancias rápidas y que no aportan excesivo valor. La creación de este tipo de sitios ha sido muy común hasta ahora en ciertos círculos, que posicionaban estas nuevas páginas rápidamente a base de crear una gran cantidad de enlaces hacia ellas de forma automatizada. Para cuando Google y su algoritmo advertían esta circunstancia y penalizaban el sitio web, el creador ya había recogido ciertos beneficios y estaba listo para volver a empezar el ciclo con un nuevo sitio.

En todo caso, aún no está del todo claro que sucede con los sitios web con autoridad ya contrastada como wordpress, blogger, youtube, etc. ¿También penaliza a las nuevas páginas creadas en estos dominios? Si no fuese así los "expertos" en la generación rápida de dinero podrían hacer lo mismo utilizando páginas dentro de estos dominios. Sin embargo, si Google cierra también esta puerta corre el riesgo de dejar en el tintero y no mostrar ciertas páginas que sí deberían estar, como las típicas noticias que generan gran cantidad de tráfico y repercusión en el medio Internet y que aparecen en las primeras posiciones de un día para otro. Como serían páginas nuevas, correrían el riesgo de quedarse fuera, para finalmente aparecer cuando la información ya estuviese desactualizada.

Desde el punto de vista de nuestro trabajo SEO, debemos tener presente esta circunstancia e introducir esta "penalización" en nuestros programas y seguir trabajando con normalidad. Al fin y al cabo, el trabajo a largo plazo no se ve afectado, y como ocurre siempre, realizar las cosas con naturalidad y sentido común es el mejor de los consejos.

En su momento instalamos una flamante instalación Wordpress con el ánimo de crear un sitio web. Y como estábamos de prueba, lo hicimos en una carpeta del dominio, por ejemplo, en http://www.dominio.com/blog, siguiendo el famoso proceso de instalación simplificada que nos proporciona Wordpress.

Durante todo el proceso, instalamos un nuevo tema, además de múltiples plugins y widgets para la correcta personalización del sitio. Al final, todo está como queremos, y nuestra web luce fenomenal. Ha llegado el momento de migrarla al lugar en el que queremos que esté, por ejemplo a http://www.dominio.com, pero no ya en la carpeta blog sino directamente sobre la URL principal.

Aparentemente puede parecer un proceso sencillo, pero la facilidad con la que puede complicarse es asombrosa. Como paso previo, lo mejor es hacer una copia de seguridad del sitio web. Puedes utilizar un plugin wordpress, o copiar directamente los archivos vía FTP. No olvides también realizar una copia de la base de datos por lo que pudiera ocurrir.

Comenzando ya el proceso, tendremos que cambiar la URL principal a la que apunta nuestra instalación. Para ello, entraremos en la administración de nuestro wordpress y en la opción Ajustes -> Generales, cambiaremos los campos Dirección de Wordpress(URL) y Dirección del Sitio(URL)

Mucha atención porque una vez grabados estos cambios ya no podremos entrar de nuevo a la administración de Wordpress en la dirección antigua. Si por alguna circunstancia hemos cometido un error, tendríamos que arreglar directamente el desaguisado en la base de datos, a través de phpmyadmin y accediendo a la tabla wp_options.Allí, tendremos que buscar los campos siteurl y home, que contendrán precisamente la URL que hemos introducido en el administrador de Wordpress. Si restauramos los valores anteriores, podremos acceder normalmente como si no hubiéramos hecho nada.

Una vez actualizada la URL, hay quien recomienda borrar la caché de Wordpress. Para ello basta con eliminar todo el contenido bajo el directorio wp-content/cache. Mucho cuidado en este punto con no borrar más de la cuenta.

Ahora ya sí, podemos copiar todos los ficheros desde el directorio en el que se encuentran actualmente a su nuevo destino, bien directamente sobre las carpetas del propio servidor o bien a través de un programa FTP. Debemos vigilar especialmente que si el fichero .htacess existe en la instalación, se copie también en la carpeta destino. A veces el fichero existe y no se copia adecuadamente, y es fuente de multitud de problemas.

Una vez terminado el proceso anterior, podríamos pensar que la migración ha concluido y que todo estará disponible, pero en el 99% de los casos no ocurrirá así. En la medida en que hayamos instalado más plugins y algún tema no estándar, es muy posible que aparezcan problemas.

El problema de los permisos de directorios y archivos

La mayoría de problemas post-migración vienen por los permisos. Al mover los directorios y ficheros, normalmente los permisos iniciales habrán cambiado, y esto complicará la puesta a punto del sistema recién migrado. En la mayoría de los casos lo más recomendable será dar inicialmente permisos máximos a todos los archivos que forman parte de la instalación de Wordpress, para, una vez solventados los problemas volver a un esquema de normalidad, que sería, como norma, permisos 644 a los ficheros y 755 a los directorios.

Pero lo dicho, inicialmente lo mejor será usar el clásico "777" para todos los archivos/directorios hasta solventar los problemas. 

El fichero .htaccess

Muchos de los problemas vienen dados por una incorrecta configuración del fichero .htaccess ya mencionado. Normalmente, con la reescritura activada, si teníamos la instalación de Wordpress en un directorio /blog, en el fichero .htaccess podría aparecer una línea de este estilo:

RewriteBase /blog

Lógicamente si nuestra nueva instalación ya no está en el directorio blog, el sitio web fallaría. Por tanto, hay que prestar atención al fichero. La mejor forma de resolver este problema será reescribiéndo el fichero a través del administrador de Wordpress mediante Ajustes->Enlaces permanentes y grabando los cambios.De esta forma se guardará la configuración correcta.

Otros problemas comunes

Con lo explicado hasta aquí habremos solucionado muchos problemas, pero es posible que todavía quede alguno, que podemos ir repasando...

- Acceder al administrador en la nueva dirección, es decir www.dominio.com/wp-admin. Si hay algún error y no conseguimos acceder, posiblemente nos hemos equivocado en el paso inicial al escribir las URLs en la sección General de Wordpress y tendremos que entrar a la base de datos tal y como se ha indicado anteriormente para comprobar que efectivamente la dirección es correcta. 

- Si conseguimos acceder, es conveniente repasar que los plugins que originalmente estaban activos sigan estándolo. En ocasiones los plugins se desactivan, por lo que debemos asegurarnos de que estén como en la instalación origen.

- Repasaremos también las opciones del tema, particularmente si no es un estándar de Wordpress. En ocasiones, los temas toman rutas directas para imágenes y otros ficheros, y si hemos movido la instalación tendremos que adecuar las rutas para que el sistema pueda encontrar dichos ficheros.

- De igual forma en los widgets, sobre todo si son de texto, en ocasiones incluimos rutas directas que tendremos que repasar y en su caso modificar.

- Finalmente las entradas y páginas también pueden contener enlaces directos a rutas inexistentes que debemos repasar.

Y si todo falla...

Si has llegado hasta aquí, y siguen fallando cosas, la labor de investigación tendrá que ser ya más profunda: inspección en las tablas de bases de datos para referencias erróneas, plugins en estado "inestable", etc. Ante todo hay que mantener la calma, tenemos una copia de seguridad y no hay mal que cien años dure. Pero si no puedes esperar tanto tiempo, llámanos y te echamos un cable.

Ya tenemos nuestro nuevo y flamante sitio web. Siguiendo las tendencias del mercado y tras consultar la opinión de algunos expertos, hemos decidido hacerlo con Wordpress.

Se trata de una opción estándar, probada y estable, que además es muy "amigable" desde el punto de vista del usuario y del posicionamiento. Además, las actualizaciones son frecuentes y fáciles de ejecutar sin conocimientos técnicos, con lo que siempre estaremos al día sin tener que contratar un servicio de mantenimiento que se ocupe de esas cosas. Total, para qué vamos a pagar a alguien para que nos haga ese trabajo si al final no es más que entrar al sistema y pinchar un par de botones.

Así que no lo pensamos más, y cuando en alguno de los plugins que tenemos instalado aparece la opción de actualización, algo como esto

pinchamos el botón "update now". Y sí, es verdad que Wordpress es un CMS maduro, probado y estable. Es verdad que las actualizaciones suelen funcionar sin mayor problema, pero también es cierto que en ocasiones, en función, del plugin, o su posible incompatibilidad con otros plugins instalados, dichas actualizaciones pueden no funcionar correctamente.

En el mejor de los casos la actualización no habrá funcionado y el plugin no estará operativo, podremos borrarlo y volver a instalar la versión anterior, si es que tenemos una copia.

En el peor de los casos el problema puede ser más grave, y ni tan siquiera podremos acceder al panel de administración para desactivar y eliminar el plugin.

La copia de seguridad

Sudores fríos empiezan a recorrerte la espalda; quizás haber pagado por ese mantenimiento no habría sido tan mala idea al fin y al cabo. Para colmo, seguramente tampoco tienes una copia de seguridad de tu sitio web. 

Entonces, seguramente llamarás a quien te ha creado la página en busca de soluciones. 

Y es que no todo está perdido, existen varios escenarios:

- El sistema ha fallado al instalar y actualizar un plugin. Normalmente no tenemos acceso a la pantalla de administración, por lo que no hay forma de desactivar y quitar el plugin por esta vía. Pero sí mediante FTP. Debemos acceder a nuestro sitio web, concretamente a la ruta wp-content/plugins. Ahí veremos una carpeta por cada plugin instalado. Si borramos la carpeta del plugin que nos ha generado el problema, seguramente todo volverá a la normalidad. Eso sí, hemos perdido la funcionalidad de dicho plugin, que tendríamos que volver a instalar en una versión que funcione si no queremos renunciar a él, o bien probar otro que tenga un comportamiento similar.

- El sistema ha fallado realizando una actualización completa de Wordpress.

Este caso tiene peor solución. Si el proceso se detiene en algún punto, o termina pero el sistema queda en situación inestable, seguramente no nos queda otra que restaurar una copia de seguridad. Si no la has hecho, es posible que tu proveedor de hosting la haga automáticamente cada cierto tiempo. Y que te la quiera dar, que esa es otra. Si finalmente la consigues, habría que restaurarla y proceder a crear de nuevo todo el contenido generado desde esa copia. Desde luego, trabajo poco agradecido y que es posible evitar con unas sencillas recomendaciones.

 Los experimentos con gaseosa

Lo diche el acervo popular, y desde luego es aplicable al caso de Wordpress. Nunca actualices nada en tu wordpress sin hacer una copia de seguridad. En todo caso, entradas del blog y contenido, pero nada como un plugin, la versión del sistema, etc.

Por si no ha quedado suficientemente claro: no actualices tu sistema sin hacer una copia de seguridad. Pinchar el botón actualizar alegremente es jugar con fuego, y al final te acabarás quemando. 

Para ayudarte en esa tarea, uno de los plugin que te puede resultar muy útil es WordpressBackup. Su función es realizar copias de seguridad programadas, tanto de los archivos del sitio web como de la base de datos, y almacenarlas en el propio servidor o incluso en una cuenta Dropbox para mayor seguridad.

Su uso es muy sencillo, una vez instalado sólo debemos definir la periodicidad de las copias:

Conclusiones

Por desgracia, no siempre las cosas son tan simples como pinchar el botón de actualizar y listo. Como hemos podido comprobar, existen muchos problemas que pueden surgir a la hora de mantener a punto nuestro sitio web Wordpress, y sólo hay un método 100% efectivo y probado de evitar problemas, que es mantener las copias de seguridad a punto.

Por tanto, cada vez que actualicemos, habrá que crear una copia de seguridad previa, y si tenemos problemas que no conseguimos resolver tendremos la opción de restaurarla para que todo quede como estaba.

Y es que tal vez esa opción de contratar el mantenimiento no resulte ahora tan descabellada...sobre todo si ya has pulsado el botón.