Ya puedes agrupar propiedades en la Search Console de Google Webmaster Tools

Nos pasa a todos: tu sitio web tiene una versión móvil, la versión de escritorio, la versión con las www, la versión sin www, la http://, la https://… Etc. Todas ellas, dadas de alta como propiedades individuales en la Search Console de Google Webmaster Tools. Si, además, has dado de alta las versiones de idioma, y gestionas cuatro o cinco dominios más, la visibilidad y la usabilidad de la pantalla principal de sitios web verificadas de la Search Console es una autentica jungla.

Por suerte Google está poniendo remedio, y ahora nos permite ver de forma agregada los datos estadísticos de todas las propiedades que agrupemos en un conjunto. De momento, la funcionalidad solo permite visualizar los datos del panel de “análisis de la búsqueda” para un conjunto de propiedades, pero es probable se amplíen las herramientas para la gestión masiva de propiedades.

Cómo agrupar propiedades en Search Console

  1. En la pantalla principal de la Consola de Webmaster Tools, al lado del botón rojo” añadir una propiedad”, nos aparece un nuevo botón con el literal “Crear un conjunto”.
  2. añadir un conjunto en Search Console

  3. Rellena los datos del formulario y añade las propiedades que quieras englobar en el conjunto.
  4. pasos para añadir un nuevo conjunto de propiedades en Search Console

  5. En unos días se empezarán a mostrar los datos de búsqueda para el conjunto. ¡Paciencia!

Dentro del conjunto de propiedades creado, Google tratará los dominios como si fueran uno solo, agregando todos los datos analíticos y las métricas que antes se mostraban por separado. Por supuesto, mantendrás los datos segregados de cada una de las propiedades.

Desde el inicio de Google Webmaster Tools, esta ha sido una de las funcionalidades más demandadas por los usuarios de la herramienta, y ahora por fin la han implementado. Esperemo que sigan incluyendo mejoras en la funcionalidad de la consola.

Motivos por los que Google te puede penalizar

Desde que decidí que el SEO sería mi oficio, y desde que me tomé en serio esto de hacer páginas web “de calidad”, estoy más atento que nunca a lo que ocurre a mi alrededor. Sobre todo, a aquello que tiene que ver con la percepción que las empresas/usuarios tienen del buscador Google.

Es curioso, porque existe una idea generalizada de que Google es casi un servicio público en el que todos tenemos derecho a participar. Pero no es así, es una empresa privada, con unas reglas y unas normas. He pasado el último año participando de forma más o menos regular en el Foro de Ayuda para Webmasters de Google, y es increíble la cantidad de hilos que se abren, semana tras semanas, de usuarios/empresas/profesionales a los que les ha desaparecido su página del índice de Google. Tras analizar las páginas penalizadas puedo afirmar que, en prácticamente todas las ocasiones, la culpa es del propietario del sitio web.

Matt Cutts te va a penalizar

¿Por qué mi página ha desaparecido de Google?

  • Contenido de baja calidad o robado de otras páginas: Google no es tonto, acéptalo. Crear contenido irrelevante, de baja calidad, con una gran densidad de palabras clave y claramente orientado a obtener un posicionamiento en el buscador, suele tener consecuencias funestas. Google quiere páginas web con contenidos interesantes para el usuario, con valor añadido, originales y no necesariamente orientados a SEO. Olvídate de copiar el contenido de otra página, aunque proceda de otro idioma. Google te va a pillar y serás penalizado por duplicidad de contenidos.
  • Contenido potencialmente perjudicial para el usuario: Algo que poca gente sabe, es que Google detesta las páginas “Your Money or Your Life” (Tu dinero o tu vida). Son páginas que pueden poner en riesgo la seguridad y la salud del usuario. No necesariamente mediante actos de delincuencia, sino haciendo que tome una mala decisión. Aquí una lista:
    • Páginas que solicitan información personal: documentos de identidad, cuentas bancarias, números de licencia o cualquier otro dato que pueda ser usado para identificar al usuario fuera del entorno digital.
    • Páginas donde se realizan transacciones monetarias: cualquier página donde el usuario puede hacer una compra. Google puede poner en cuarentena estas páginas hasta que no verifica la autenticidad y la calidad.
    • Páginas web con información médica que pueden tener un impacto sobre el bienestar físico o psicológico del usuario. ¿Quién no ha buscado en Google “dolor de riñón” y ha descubierto que padecía un cáncer terminal?
    • Páginas con recomendaciones o consejos sobre decisiones de compra importantes, como comprar un coche o una casa.
    • Páginas que ofrecen información sobre temas importantes de la vida, como información financiera o asesoramiento jurídico.

Tener un sitio web con este tipo de contenidos no significa estar condenado a una penalización de Google. Pero seguramente Google va a estar muy atento a lo que publicas, a la calidad de tus contenidos, y a la calidad global de tu sitio web.

¿Tu página web es puro Spam?

He visto algunos casos realmente impactantes en los últimos meses: páginas repletas de publicidad invasiva que impide al usuario realizar acciones básicas, interrupciones de la navegación y pop ups insoportables. Digo que son casos impactantes, no porque las páginas sean pura basura, sino porque el webmaster acude al Foro de Ayuda buscando una explicación a la penalización. Según el anuario 2015 sobre webspam de Google, en 2015 se han aplicado más de 4,3 millones de penalizaciones manuales a sitios web de baja calidad o comportamiento claramente fraudulento.

¿Has sido hackeado?

Tener un sitio web protegido es responsabilidad de sus propietarios. Contraseñas seguras, evitar agujeros de seguridad en los servidores, etc. Aún así, durante 2015, Google ha detectado un incremento del +180% de sitios web hackeados. Más de 400.000 sitios web han sido denunciados por los usuarios como perjudiciales, y un 65% de estos han sido censurados en el buscador. Un ataque puede causar que tu web adquiera un comportamiento anómalo, y Google penalizará sin dudar cualquier sitio sospechoso.

Conclusiones

Google es de Google. Esto significa que estás en su casa, y bajo su techo se deben cumplir sus normas. Google quiere, literalmente, un “ecosistema limpio”. Creer que eres más listo que los demás no te llevará a la cima. Parece increíble que, en 2016, tengamos que andar dando lecciones sobre este asunto.

SEO Multi-idioma (II): Localización orientada a SEO

Resumiendo mucho para ir al grano, la localización web consiste en la traducción del contenido del sitio para que sea comprensible para el usuario objetivo. Evidentemente, un usuario de Londres no entiende el Español, del mismo modo que un español no entiende el chino. Debemos traducir nuestro sitio, es condición imprescindible si queremos traspasar fronteras.

translation meme image

¿Cómo puedo traducir mi sitio web?

No voy a entrar en los pluggins necesarios o en la tecnología que requiere implementar un nuevo lenguaje en una estructura web. Hay tantos casos como sitios web. Me voy a centrar en la propia traducción.

Volviendo a ser breve: Google translator = mal, traductores profesionales = muy bien. Google ha reconocido que lo mejor, si nos tomamos esto del posicionamiento orgánico en serio, es contratar a traductores profesionales para realizar la traducción de nuestro sitio web. Pero… ¿debo gastar dinero?.

Cuando traducimos nuestros contenidos a otros idiomas, debemos realizar un proceso de optimización de palabras clave para cada idioma de destino. Es decir, no sirve una traducción literal de nuestros contenidos. Un ejemplo práctico es el de un e-commerce de material deportivo y fitness especializado en la venta de bicicletas estáticas. No lograba posicionar sus “landings” en Inglaterra. El motivo, es que usaron una traducción literal de “bicicletas estáticas”, es decir, “static bikes”. Rápidamente, un traductor profesional advirtió que el término correcto es “exercise bikes”. Este simple cambio influyó de forma significativa en el posicionamiento.

Si disponemos de los recursos humanos o el conocimiento necesario para realizar este proceso «in house», genial. Si no es posible, os recomiendo que busquéis alguna agencia especializada en traducción web. Barriendo para casa, os recomiendo esta Empresa de traducción en Barcelona, con la que he trabajado traduciendo contenidos para otras webs.

Por último, advertir que algunas soluciones de traducción “freemium” realizan traducciones “al vuelo”. Es decir, mediante la sustitución del texto a través Javascript. Esto no es especialmente malo para el usuario, pero ejecutar funciones AJAX no son del agrado de Google. Realizar la traducción con estas herramientas puede ser muy cómodo, pero Google no va a ver vuestro sitio web traducido, no te vas a posicionar y todo el esfuerzo no servirá para nada.

Esta entrada es la segunda de una serie de posts con recomendaciones, buenas prácticas y consejos para la implementación de una estrategia SEO multi-idioma. La guía consta de 3 partes:

  1. SEO Multi-idioma I: Geolocalización
  2. SEO Multi-idioma II: Localización orientada a SEO
  3. SEO Multi-idioma III: Implementación de etiquetas hreflang (sistema solo para Google y Yandex).

SEO Multi-idioma (I): Geolocalización de un sitio web

A estas alturas de la película, cuando ya está todo escrito, no hay mucho más que añadir sobre la implementación de una estrategia SEO multi-idioma en un sitio web. Aún así, siempre hay alguien que me pregunta sobre el tema. Vamos a ver si es posible poner algo de orden.

Esta entrada es la primera de una serie de posts con recomendaciones, buenas prácticas y consejos para la implementación. La guía consta de 3 partes:

  1. SEO Multi-idioma I: Geolocalización
  2. SEO Multi-idioma II: Localización orientada a SEO
  3. SEO Multi-idioma III: Implementación de etiquetas hreflang (sistema solo para Google y Yandex).

Geolocalización de un sitio web

La geolocalización de un sitio web, consiste en ubicar nuestros contenidos en un entorno físico próximo al usuario. El principio es simple: cuanto más cercana esté nuestra página a un usuario, mayor será la relevancia en los resultados de búsqueda de ese usuario. Es decir, nuestro sitio web mejorará su posicionamiento para una ubicación concreta.

Tiene toda su lógica. Si, por ejemplo, tenemos un sitio web donde vendemos pan a domicilio en el área metropolitana de Barcelona, no tiene ningún sentido que nuestro sitio web aparezca en los resultados de un usuario que busca comprar pan en Lima (Perú).

¿Cómo determina Google donde está ubicada mi página?

  1. Domino ccTLD: Dominio con código de país (.es .fr .uk, etc). Estos dominios ofrecen una información clara al buscador sobre el ámbito geográfico al que va dirigido un sitio web. Del mismo modo que Google prioriza un .es para España, lo penaliza para cualquier búsqueda que se realice desde fuera del Estado Español.
  2. Orientación geográfica del dominio: En la Consola para Webmasters de Google se puede orientar geográficamente un Dominio, un Subdominio o un directorio de nuestro sitio web. De este modo, es posible segmentar geográficamente un sitio genérico en su totalidad (.com .net, etc), o realizar segmentaciones de distintas partes del dominio.
  3. IP del servidor: Durante algún tiempo, Google tenía en cuenta la ubicación física por un principio de velocidad de carga. Cuanto más cercano, mayor velocidad. En la actualidad, con la existencia de CDNs, esto deja de ser un factor relevante para el posicionamiento. Aún así, ayuda.
  4. Geolocalización de enlaces entrantes: Google cruza los datos de geolocalización de todos los sitios web con enlaces entrantes a nuestro sitio, de modo que puede establecer el entorno o “cosmos” en el que se alberga nuestra web. Si nuestra web está geolocalizada en España, no es normal que todos los enlaces procedan de sitios web en Chino y ubicados en Tailandia. Es una buena manera de detectar la compra de enlaces ;).
  5. Domicilio del titular del dominio: Aunque parezca mentira, Google consulta los registros para saber quien es titular del dominio y su domicilio. De este modo, puede establecer una vinculación entre la página, el dominio, el titular y la ubicación geográfica.
  6. Existencia de perfiles en Google My Business con oficinas localizadas, contactos, teléfonos, etc. Si nuestro e-commerce de pan a domicilio tiene un sitio físico, debemos dar de alta las oficinas o la tienda en Google my Business, donde establecemos la ubicación exacta y datos de contacto. Este punto sea, quizás, uno de los más relevantes.

Con esto, ¡nuestro sitio ya estará segmentado y geolocalizado!

Cómo desactivar xmlrpc.php de WordPress

Una de las vulnerabilidades más comentadas de WordPress es la que tiene que ver con el archivo xmlrpc.php. Para resumir, este archivo es el que permite la interacción entre wordpress y aplicaciones remotas. Sirve, a la práctica, para que los propietarios/editores de un sitio WordPress puedan acceder al Gestor de Contenidos y publicar nuevas entradas desde aplicaciones conectadas con WordPress.

La vulnerabilidad tiene que ver (sobre todo) con ataques de fuerza bruta. Es decir, se realizan muchas consultas simultáneas al archivo xmlrpc.php de desde distintos puntos, de modo que el servidor se vuelve inestable y cae, dejando el sitio web inoperativo. Esto es un resumen muy tosco, claro. En realidad existen muchas otras vías por las que el xmlrpc.php puede causar una vulnerabilidad en nuestro sitio web, pero no vamos a entrar en detalles.

Si no tienes intención de realizar operaciones remotas con WordPress y deseas desactivarlo, aparentemente no existe una opción que permita inhabilitar esta funcionalidad desde los menús de configuración. Pero no está todo perdido.

Método radical para desactivar el xmlrpc.php

Si revisas tu código fuente, encontrarás una línea como esta:

<link rel="pingback" href="http://www.adriapadilla.net/xmlrpc.php" />

Para eliminar este vínculo, accede al fichero header.php y busca la siguiente línea:

<link rel="pingback" href="<?php bloginfo( 'pingback_url' ); ?>" />

Comenta la línea y la función php para que el vínculo se inhabilite

<!--<link rel="pingback" href="<?php // bloginfo( 'pingback_url' ); ?>" />-->

Por último, en el directorio raíz de tu instalación de WordPress, busca el fichero xmlrpc.php y cambia su nombre a algo completamente distinto. Si estás seguro de que no vas a utilizar nunca esta funcionalidad, lo puedes eliminar. Con esto bastaría para que el fichero no sea detectado por los “hackers” malintencionados.

Método suave para desactivar el xmlrpc.php

Si crees que en algún momento vas a necesitar la funcionalidad y no deseas eliminar el fichero, hay otra vía para desactivarla de forma “menos agresiva”, que consiste en denegar el acceso al fichero xmlrpc.php. Consiste en añadir las siguientes líneas al .htaccess de tu sitio web:

<Files xmlrpc.php>
	Order Deny,Allow
	Deny from all
</Files>

Existe un último método que permite el acceso parcial al archivo. Se trata de combinar la anterior directiva del .htaccess con permisos de acceso para una o varias IPs concretas. Por ejemplo:

<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
    Allow from xxx.xxx.xxx
    Allow from xxx.xxx.xxx
</Files>

Con esto ya tenemos las espaldas cubiertas frente a cualquier intruso malintencionado. Creo que no hace falta recordar la necesidad de realizar una copia de seguridad antes de proceder.

¿Cómo quitar el shortlink de WordPress?

Cuando creamos un sitio web en WordPress, una de las primeras cosas que hacemos es personalizar los enlaces permanentes. Se trata de evitar esa odiosa estructura por defecto que hace que nuestras URL sean tan feas.

Por ejemplo: http://www.tusitioweb.com/?p=8

A la mayoría de los usuarios les basta con realizar la modificación correspondiente en el panel “enlaces permanentes” del menú Ajustes de WordPress.

Este procedimiento no evita que el «shortlink» (el enlace feo) siga apareciendo en nuestro código fuente, y su presencia puede llegar a ser molesta. Aquí lo tenéis:

<link rel='shortlink' href='http://www.adriapadilla.net/?p=8' />

Tener este tipo de enlaces en nuestro código permite que los crawlers lo sigan encontrando. Algunos, como ScreamingFrog o Xenu, nos mostrarán estos enlaces «simples» (podéis llamarlos «feos») en el listado de links de nuestro sitio web. Puede que esto no nos interese.

Pasos para eliminar el shortlink de nuestro código fuente

  1. Abre el fichero “link-template.php”, que encontrarás en el directorio «/wp-includes/», en el directorio raíz donde tengas instalado WordPress. Para editarlo, es recomendable usar algún programa tipo Notepad++.
  2. Busca la siguiente función
  3. function wp_shortlink_wp_head() {
        $shortlink = wp_get_shortlink( 0, 'query' );
    	if ( empty( $shortlink ) )
    		return;
    	echo "<link rel='shortlink' href='" . esc_url( $shortlink ) . "' />\n";
    }
  4. Comenta el “echo”, que es lo que se encarga de hacer que el shortlink se muestre en tu código fuente. Debería quedarte así:
  5. function wp_shortlink_wp_head() {
        $shortlink = wp_get_shortlink( 0, 'query' );
    	if ( empty( $shortlink ) )
    		return;
    //	echo "<link rel='shortlink' href='" . esc_url( $shortlink ) . "' />\n";
    }

Con esto, ya has eliminado de tu código fuente el shortlink con la estructura «simple» de wordpress!

Google y los caracteres especiales en una URL

¿Es correcto usar caracteres especiales en las URL de nuestra web? ¿Google tiene problemas para rastrear las URL con caracteres especiales? ¿Cómo puede afectar esto a nuestro sitio? La respuesta es sencilla, ya que Google se ha pronunciado sobre la cuestión en un par de ocasiones.

La versión oficial más reciente es de diciembre del 2015, cuando John Muller (analista de tendencias de webmasters para Google en Zurich), contestó a una pregunta similar en el foro para Webmasters de Google («Google Crawler Truncates Comma in URL and Reports 404»):

I generally recommend avoiding special characters like commas, semicolons, colons, spaces, quotes etc. in URLs, to help keep things simple. URLs like that are often harder to automatically link (when someone posts in a forum or elsewhere), and hard for us to recognize correctly when we parse text content to try to find new URLs. When they’re linked normally or submitted through a sitemap directly, they work as expected. However, when we try to recognize the URL in something that we crawl as a HTML or a text page, then we’ll probably «guess» them wrong — which is fine, since we’ve probably already seen them through the normal links & sitemap usage. In practice this doesn’t matter, finding links which don’t work is perfectly normal for us; it won’t break the crawling, indexing, or ranking of your site assuming we can crawl it otherwise. We’ll show these as 404s in Search Console because they return 404, but they’re not something critical that you need to suppress. If you want to move to a cleaner URL structure that’s less-likely to be misinterpreted like that, you can use normal 301 redirects & rel=canonical elements on the page. It’ll generally take some time to crawl & reindex the URLs like that though, so you’ll continue to see these old URLs in Search Console in the meantime. Cheers, John

Otras respuestas oficiales de Google

No es la primera vez que se habla del tema. En marzo del 2012 se publicó una video respuesta en el canal oficial de Google Webmasters en Youtube: “Do you recommend using special characters in URLs?”. La respuesta, como vemos, es la misma: se pueden usar pero mejor que nos abstengamos de ello.

El 12 de enero del 2016, un usuario del Foro en español de Google para Webmasters lanzó una pregunta donde se exponía un caso similar: un cliente usa caracteres especiales en sus URL. ¿Cómo es el uso correcto de los caracteres especiales en las URLs?

A pesar de que Google admite tener algunas dificultades para rastrar URLs con caracteres especiales, la conclusión general es que no existe una prohibición o una incapacidad total para trabajar con estas URL. Para Google no existe un listado de caracteres prohibidos o poco recomendables para las URL. De un modo u otro, Google es capaz de acceder a las páginas con una URL difícil, ya sea «recomponiendo» la dirección o usando el sitemap para el rastreo completo del sitio.

¿Significa esto que puedo poner caracteres especiales en una URL?

Que Google tenga métodos para corregir errores en la lectura de las URL con caracteres especiales no significa que tengamos barra libre para su uso.
Los caracteres especiales pueden estar justificados. Por ejemplo, cuando guardamos en una URL información introducida por el usuario en un formulario, o cuando el usuario está realizando una navegación personalizada y se incluyen variables de sesión. Es decir, cuando el uso de el caracter que usamos se corresponde al propósito para el que se considera reservado.

Sí, has leído bien. A pesar de no existir un listado de «caracteres especiales prohibidos», si que existe un estándar de caracteres reservados, y en él se define el rol que se le ha asignado a cada uno dentro de la estructura de una URL.

En resumen, lo que nos interesa está en el punto 2.3 del documento de estándares, donde se habla de los caracteres «no reservados» y que, por lo tanto, que pueden ser usados sin problemas en una URL.

Characters that are allowed in a URI but do not have a reserved
purpose are called unreserved. These include uppercase and lowercase
letters, decimal digits, hyphen, period, underscore, and tilde.
unreserved = ALPHA / DIGIT / «-» / «.» / «_» / «~»

Entonces, ¿qué sentido tiene usar caracteres especiales en una URL? Bajo mi punto de vista, si no se hace para un propósito justificado, no tiene sentido alguno.

Introducir caracteres especiales complica las cosas para el usuario: dificulta la comprensión, memorización y reproducción de la URL, provocando que el usuario acabe en páginas 404 cuando intenta reintroducir la dirección de forma manual. Además, ¿qué ocurre si un usuario no dispone de ese caracter en su teclado?

El razonamiento para no usar caracteres especiales no se sustenta en la capacidad de Google para comprender y procesar una URL, sino en que sea viable para el usuario entender lo que está visualizando. Excluir estos caracteres de forma sistemática, mejorará la experiencia del usuario, la usabilidad y la navegación por la página. Crear reglas para la construcción de patrones de URL dotará a nuestro sitio web de consistencia y facilitará el SEO de forma sustancial.

La regla general: siempre «user friendly»

Debemos recordar que todo lo que es malo para el usuario es malo para Google. El uso de los caracteres especiales sigue el mismo principio que la construcción de patrones URL friendly. Cuanto más sencillo y humano sea el patrón de la URL, mejor. Cuanto mayor sea la facilidad del usuario para comprender el contenido de la URL a partir de su patrón, mayor será la confianza..

En resumen: Google desaconseja su uso y los estándares indican que los caracteres especiales (salvo excepciones) están reservados para un propósito concreto, por lo tanto… abstenerse.