Categoría: Tutoriales

Siempre has querido conseguirlo

Siempre has querido mejorar tu SEO sin ser técnico. Si tienes una web de un negocio o actividad empresarial, sabrás lo importante que es que dicha web, además de ser tu «tarjeta de visita de empresa» (cuando la ven los que ya te han conocido), haga de comercial por internet. Es decir, que la encuentren aquellos que no te conocen y buscan productos, servicios o soluciones que tu empresa ofrece.

Todo esto es lo que se trabaja en la compleja disciplina del SEO (Search Engine Optimization). Es cierto que el mundo del SEO es de una alta complejidad técnica y generalmente es recomendable delegarlo a profesionales del sector.

Mejorar tu SEO sin ser técnico ¿es posible?

No obstante, si encontramos que ahora no es momento para embarcarse en una campaña SEO, o simplemente deseamos poder hacer por nuestra cuenta todo lo que sea posible, estamos de enhorabuena: una de las tareas SEO con más impacto en nuestra web que pueden hacerse, la podemos desarrollar sin conocimientos técnicos.

¿De qué se trata?

Desde hace mucho tiempo ya, Google y el resto de buscadores están interesados en verificar si eres autoridad o no en tu sector; si tienes buenas referencias y si estás bien considerado en él. Una forma de demostrarlo es que empresas o entidades de reconocido prestigio en tu sector tengan en sus webs respectivas enlaces a la tuya. Puede tratarse de proveedores, empresas colaboradoras, etc. Es decir, que ellos incluyan en sus webs algún contenido o banner que lleve a algún sitio de la tuya. Con lo cuál, tu trabajo sería hablar (y posiblemente negociar) con representantes de dichas empresas para que publiquen en sus respectivas webs dichos enlaces.

Por supuesto, el impacto variará dependiendo de muchos factores. Entre ellos:

• la importancia del espacio desde donde se haga ese enlace, y del sitio de nuestra web al que enlaza. No es lo mismo que aparezca en medio de un artículo técnico, en el cuál se lleva a tu web para ampliar información, que si ese enlace aparece en «enlaces patrocinados» o algo similar. Tampoco será lo mismo que enlace a la página de servicios, o a una entrada técnica, que enlazar a un artículo sobre un encuentro entre profesionales del sector, por ejemplo.
• Lo natural que sea dicho enlace, sin que se vea forzado o artificial, sin que parezca un «enlace patrocinado» o banner de publicidad. Tampoco tendría que verse como algo pactado o un acuerdo de «yo a ti y tú a mí».
• La relevancia de dicha entidad «reconocida», dentro del ámbito de acción al que nosotros nos dirigimos. Es decir; posiblemente no aporte demasiado si está muy reconocida por ejemplo en otro país, pero tiene un reducido alcance en el mercado al que nosotros queremos llegar. También podría no aportar mucho en caso de no ser relevante en tu región y tu ámbito de acción es de negocio local.

En cualquier caso, en ocasiones con mayor impacto y menor en otras, para mejorar tu SEO sin ser técnico, estará bien que, siempre de forma natural y no forzada ni pactada, los «grandes» del sector en el que operamos, hagan alguna referencia a nosotros mediante enlaces desde su web a la nuestra.

Por supuesto, si quieres que te ayudemos o te asesoremos más sobre cómo conseguir en tu caso enlaces entrantes a tu web desde sitios relevantes de tu sector, contacta con nosotros.

Hoy hablaremos de cómo mostrar las entradas unificadas en multiidioma con Polylang. Esto es importante si, por la razón que sea, consideramos que el sistema multiidioma nos viene bien para las páginas y custom post types, pero no para el apartado de blog y sus entradas.

El problema

Sabemos que Polylang es una excelente herramienta de gestión multiidioma. Por definición, lo que hace es adjudicar una entrada o página a un idioma, y sólo a uno. Después, esa puede vincularse con otras, que serán sus «equivalentes» en otros idiomas. Hasta ahí todo bien.

Puede ocurrir que, en un principio, cuando se creó la web en estructura multiidioma, pensáramos que íbamos a escribir artículos que íbamos a tener traducidos a todos los idiomas que incluimos en la web. Posiblemente al final hemos visto que no; que no nos gustan los resultados de las traducciones automáticas, y que no podemos estar traduciendo todas las entradas que hacemos. Que, finalmente, queremos que todas las entradas de blog estén juntas y las vean todos los que entran a nuestra web, busquen el idioma que busquen. Esto nos ha ocurrido con algunos clientes de mantenimiento de sitios web y de consultoría WordPress.

No existe una fórmula natural y sencilla de mostrar las entradas de forma unificada en multiidioma con Polylang

¿Cómo hacemos esto? Porque recordaremos que hemos dicho que Polylang adjudica cada entrada a uno y sólo a uno de los idiomas. De esa forma, quienes entren al blog en otro idioma no encontrarán las entradas que no se hayan adjudicado a ese idioma. Y es que no hay una «fórmula mixta» reconocida para gestionar esto. No hay una fórmula para mostrar entradas unificadas en multiidioma con Polylang de una forma natural y elegible.

Si, por ejemplo, publicamos en Castellano, pero en nuestro sitio web tenemos también Inglés y Francés, quienes entren al blog Inglés ó Francés no verán esas entradas. Y si, esporádicamente, publicamos en Inglés por ejemplo, sólo los que busquen nuestra web en Inglés verán esas entradas. Puede ser hasta cierto punto lógico. Pero, ¿y si queremos que todos vean todas las entradas, porque queremos que vean actividad y movimiento en nuestro blog? ¿Y si se trata de que trabajamos, además de Castellano, en Euskera o Catalán, y consideramos que nuestros potenciales lectores pueden acceder a esas entradas en Castellano, sin que nos suponga tanto trabajo?

La solución: engañaremos un poco a Polylang

La solución a esto pasa por «engañar» a Polylang. Primero, todas las entradas que publiquemos, sean en el idioma que sean, le diremos que son en el idioma que establezcamos como principal. Esto nos sirve para entradas de nueva creación; pero en las ya creadas también podemos modificar el idioma que tienen adjudicado. De esa forma, ya todas las entradas aparecerán juntas, «bajo el mismo blog». En la URL del blog de uno de los idiomas. En el resto no aparecerá ninguna.

¿Y los usuarios de los otros idiomas?

A los usuarios de los otros idiomas, les pondremos, no el enlace al blog que nos propone Polylang, sino el enlace del idioma principal. Es decir: Al elegir un elemento a añadir al menú de esos otros idiomas, vamos a hacerlo visualizando sólo las URLs de nuestro idioma principal (eso lo vemos en la barra superior de nuestro wordpress).

Buscamos la página Blog… y sólo nos mostrará la del idioma principal, no sus equivalentes. La añadimos. Si tenemos que cambiar la etiqueta del nombre, lo hacemos.

¿El inconveniente de esta solución?

El inconveniente de esta solución es que los usuarios que vayan al blog, si son de esos otros idiomas que no hemos definido como principales, van a salirse de su idioma y van a entrar en el idioma principal. Es importante que hayamos implementado opciones claras de permutar entre idiomas de forma fácil en nuestro sitio web.

Entradas unificadas en multiidioma con Polylang: Resumen y valoración

Polylang es una excelente herramienta para tener nuestro sitio web en varios idiomas. Además, es un plugin gratuito, con una gran comunidad de desarrollo y por consiguiente, con un gran respaldo. Es, por ello, una buena opción.

En muchos casos (algunos los conocemos personalmente), lo que era un afán inicial de publicar todo en los idiomas elegidos para el sitio, acaba quedándose en querer utilizar las opciones multiidioma para las páginas estáticas y secciones interiores fijas de la web; pero no para el blog en continuo desarrollo de contenido. Desafortunadamente, Polylang no nos da una opción para configurarlo así, de forma natural, y decirle algo como «mira Polylang; aplica tus criterios sólo a las páginas y los Custom Post Types que tenemos, pero no a las entradas del blog que estamos haciendo, porque no tenemos tiempo ni posibilidades de hacer y publicar buenas traducciones de todos nuestros contenidos».

Llegados ahí, sólo nos queda la opción de «engañar a Polylang» diciéndole que todos nuestros artículos han sido casualmente escritos en el idioma principal del sitio web (aunque no sea realmente así). Y en el menú de los otros idiomas no habrá enlaces al blog en esos idiomas, sino enlaces al blog del idioma principal.

El inconveniente será que esos visitantes de otros idiomas, al visitar el blog, se salen de su idioma para ir al idioma principal. Por ello tenemos que implementar (siempre, en realidad) buenas y fáciles fórmulas para permutar entre idiomas en todo momento. Pero este inconveniente se ve compensado largamente por haber conseguido mostrar entradas unificadas en multiidioma con Polylang. Fácil, ¿verdad?

En este artículo os voy a contar la experiencia particular de realizar una migración de una web desde un servidor a otro; por si a alguien le interesa o puede tomar nota de ello. Desde luego que podrá hacerse de otras formas, incluso más óptimas. Esta es la que hemos hecho y la que nos ha funcionado en nuestro caso.
Como algunos ya sabréis, UrBerri se ha visto en la necesidad de migrar de proveedor la máquina en la que se aloja esta página web. Ha sido un proceso complicado por lo inesperado del mismo. Ante los reiterados problemas con el servicio prestado por el proveedor de servicios de infraestructura, no ha habido otra opción. Muchos dirán aquello de que ya nos lo podíamos imaginar. Lo cierto es que era lo único que gestionábamos con dicho proveedor. Desde luego, punto final. En cualquier caso, afortunadamente el proceso de migración ha sido satisfactorio; y vamos a aprovecharlo para describir los pasos dados, para el caso de que otros tengan que hacer lo mismo. Por supuesto, este procedimiento está pensado con nuestras circunstancias: Registrador de dominios Godaddy, y nuevo proveedor de infraestructura, OVH. En otros casos, pueden cambiar detalles; pero la idea fundamental se mantendrá, seguramente.

Rescatamos la información que tengamos

Página web

Tanto si trabajamos con WordPress, como con otro CMS, hay una “solución universal”: guardar las carpetas de nuestro CMS, y también la base de datos que empleemos. Todo con sus mismos nombres.

Correo electrónico

Hay que recordar que perderemos el correo electrónico antiguo, porque lo va a gestionar otro proveedor. Siempre está bien comprobar si nos compensa que el registrador nos gestione también el correo electrónico. En este caso, no habría ningún problema ni desaparecería nada.
Si vemos que no nos interesa, y que lo vamos a perder, siempre guardar el correo antiguo. Tenemos dos posibilidades. Estoy hablando de las soluciones para Thunderbird, que es mi caso:

1. Copiar los e-mails que nos interesen en las carpetas locales. Después, cuando se pierda todo lo de nuestro servidor imap, lo tendremos en dichas carpetas, donde siempre lo podemos consultar.
2. Convertirlo en pop3, de forma que se descargue todo en local, en nuestro equipo. De todas formas, esto va a dejarlo en nuestra actual cuenta. La experiencia nos dice que Thunderbird nos puede dar quebraderos de cabeza si modificamos los datos de la cuenta para que apunte al nuevo servidor, más que si simplemente borramos dichas cuentas y las activamos de nuevo.

Gestiones desde nuestro panel de Godaddy

Desde nuestro panel de Godaddy tendremos que eliminar toda configuración de otros proveedores anteriores en relación a dns, Ips, MX, etc., y dejarlo con la configuración original. También podemos indicar la nueva ip que vamos a emplear, en el campo en el que figuraba la anterior. Respecto a los nombres dns, podemos emplear los nuevos de OVH o seguir con los de Godaddy. Para el correo electrónico sí necesitaremos otra gestión una vez que activemos lo que vamos a hablar en el siguiente punto.

Las zonas dns

Al menos con ovh, si queremos comenzar a trabajar con un dominio registrado externamente, me dicen los técnicos que es mejor que, desde la página del registrador, restaure los dns originales de Godaddy para que no dé problemas. Y cuando nos pide el nombre de dominio para el que vamos a generar una zona dns, ¡importante! Recordar ponerlo sin las www; en caso contrario, activaríamos unas direcciones de e-mail del tipo contacto@www.nuestrodominio.com.
Al registrarlo nos pide si queremos con los registros básicos. Le decimos que sí. Esto es importante a la hora de poder activar luego un plan de correo electrónico. No haría falta si no quisiéramos la prestación de este servicio.
Una vez que nos confirman que ya está todo activado, y podemos ver que nos aparece el dominio en nuestro panel de gestión, ya podemos migrar la web.

Migrando la web

Si la web está hecha con WordPress, dado que el nombre de dominio se mantiene, el procedimiento es sencillo pero tal vez no tan evidente. Y no necesitamos emplear ningún plugin. Hay que tener en cuenta algo: tenemos que crear una base de datos con el mismo nombre que teníamos, y el usuario y sus permisos también tienen que ser idénticos. De esta forma, no tendremos problemas.

1. Copiamos los archivos y carpetas que tenemos guardados, a la ubicación correspondiente.
2. Creamos la base de datos y su usuario, recordando lo que hemos dicho de hacerlo con los mismos nombres y permisos que ya tenían. Nos aseguramos de que el archivo de configuración de wordpress mantiene esos datos.
3. Volcamos con una instrucción mysql el contenido de la base de datos antigua en la base nueva que acabamos de crear.

Y en principio, ya está. Podemos ya acceder a la página web tal cual. Si viésemos que algún plugin nos dificulta el acceso, podemos ir, a través del servidor, a la carpeta de los plugins, renombrar dicho plugin añadiéndole una extensión .old (por ejemplo), de tal forma que ya no esté activado al arrancar. Una vez dentro del wordpress, ya veremos qué hacemos con él.

El procedimiento no es complicado; pero puede resultar todo un contratiempo si nos vemos obligados a realizarlo cuando teníamos otros planes de acción. Moraleja: como ya dijo alguien, en esto de los servicios de infraestructura web, como en tantos otros servicios y productos, hemos de recordar la máxima de: «Tenemos tres baremos: bueno, bonito, barato. Elige dos». A buen entendedor… ¡Hasta el próximo post!