Tutoriales

En el mundo virtual, tal como ocurre en el real, hay competidores que se valen de cualquier arma para poder vencer a la competencia. Esto es más probable cuánto más competencia tenemos en el ambiente. De otra manera que se podría decir esto es: cuánto mayor es el rédito de un nicho, mayores son las posibilidades de ser víctima de estas acciones.

¿Cómo se hace SEO Negativo?

Básicamente, la respuesta sería hacer todo lo contrario a las políticas de los motores de búsqueda. Es decir, todo aquello que te dicen que es malísimo de hacer contra una web se hace contra la web del competidor. Lamentablemente, este tipo de SEO logra mejor sus objetivos (incluso más rápido) que el SEO que hacemos a webs propias. Tal vez, este sea uno de los motivos por el cual muchísimos se sienten atraídos por la realización de estas prácticas.

Si soy víctima de SEO Negativo ¿Puedo hacer algo para que no me perjudique?
La respuesta es sí. Teniendo en cuenta que la base del SEO negativo es realizar campañas de linkbuilding de forma masiva desde sitios tóxicos. La forma más sencilla de dejar esos enlaces sin efecto es desautorizándolos desde herramientas como Webmaster Tools. No podemos decir que el proceso en sí sea rápido de hecho, dependiendo de la forma en que se hizo la campaña es probable que pases mucho tiempo seleccionando aquellos enlaces entrantes que deseas desautorizar. Aun así, lo positivo es que puedes defenderte cosa que no era posible hasta hace un par de años atrás. De hecho, Google debió permitir esta posibilidad luego de ver cómo estas malas prácticas de atacar al competidor fueron en incremento. En realidad, tienen que haber llegado a una cuota alta para que el buscador se interese por hacer algo así. En estas líneas, se debería leer: este tipo de ataques deben haberse incrementado muchísimo en el mercado estadounidense para que a Google le haya interesado agregar esta defensa.
Si te interesa el tema te recomiendo que mires este vídeo: https://www.youtube.com/watch?v=o9QJi32jL1U

Un punto a aclarar, es que al realizar la desautorización de los sitios no se logrará una mejora inmediata en las serps. De hecho, puede ocurrir que se demore un largo tiempo en que esos cambios tomen efecto. Por este hecho, lo mejor que puedes hacer para prevenir los efectos del seo negativo es realizar una inspección asidua de los tipos de enlaces que tus sitios reciben. Para hacer esto no te centre solo en la herramienta de google sino también en otras externas como ahrefs.com o moz.com. En síntesis, cuántas más fuentes de información tengas mejor más posibilidad tendrás de hallar enlaces tóxicos. No olvides que al fin y al cabo, esos datos son recopilados por un bot araña que puede demorar un largo tiempo en hallarlos. De ahí, la necesidad de chequear con diversas fuentes. Así, lo que no halló una herramienta puede hallarlo la otra.
En el SEO gana aquel que mejor preparado está, quien mejores estadísticas lleva y quien más eficiente es a la hora de inspeccionar su web.

Search engine optimization (SEO)

Si estás en un mercado donde la competencia es alta deberías extremar las medidas para hallar posibles ataques lo antes posible. Te estarás preguntando cómo darse cuenta de ello ¿No? Esta respuesta reside en la base que debes revisar anchors con una repetición muy alta y que no hayan sido creados por ti mismo, anchors extraños, anchors con palabras consideradas ultra negativa por google como viagra, porn y similares. Estos son términos que supuestamente son muy penalizados por el buscador. De ahí, que sean muy utilizados para realizar este tipo de ataque.
Para evitar SEO negativo no existe una herramienta infalible ni un método 100% efectivo así que solo se debe circunscribir al ámbito de la inspección asidua.

Git es un sistema de gestión de versiones, como SVN o CVS, con algunas características que lo diferencian

Es distribuido. Mientras SVN o CVS, están orientados a tener un repositorio central sobre el que todos modifican, Git esta orientado a que cada cliente tiene su propio repositorio y sincroniza con uno central, o con alguno intermedio o con otro usuario. Esto da mucha flexibilidad a tu flujo de trabajo.
SVN o CVS son sistemas mas maduros que Git, con lo que existen mas clientes para todos los sistemas, y es mas fácil encontrar información concreta sobre estos. Sin embargo gracias al uso de Git para el desarrollo del kernel de Linux, ahora esta empezando a tener cierto auge.

Lo primero es o primero, y en este caso es instalar todas las herramientas necesarias para trabajar con Git, en mi caso trabajo exclusivamente desde la terminal, así que solo tengo que descargar los paquetes principales de la página de Git, dependiendo del sistema operativo en el que trabajemos.

Iniciando el repositorio:

La estructura general de un árbol de repositorios de Git, suele estar compuesta por un numero indeterminado de clientes que gestionan cada uno su propio repositorio, y que en algún momento ponen en común su trabajo con otro repositorio superior y común de Git. Para empezar a trabajar con ese repositorio superior y común, si ya existiera, deberíamos ejecutar algo como:

git clone protocolo://rutadelservidor/rutadelrepositorio

Pongo “protocolo://” por que git puede trabajar tanto con FTP, como con FTTP, como con RSYNC, o con el que yo trabajo normalmente SSH. Una vez ejecutado este comando, tendremos una copia del repositorio superior, o común en nuestro sistema, en la carpeta donde lo hayamos ejecutado, es decir, en nuestro repositorio privado. Se generaran todos los archivos necesarios, tanto los propios del servidor Git, como los archivos del proyecto en el que estemos trabajando.

Modificando el proyecto:

Una vez tenemos los archivos a nuestra disposición, podemos añadir nuevos archivos al proyecto, podemos eliminarlos del proyecto, o bien, cambiar los existentes. Para añadir nuevos ficheros al repositorio debemos ejecutar:

git add nombredelfichero-o-directorio

Para eliminar los archivos, es algo similar:

git rm nombredelfichero-o-directorio

Una vez hemos añadido, eliminado, o modificado un fichero ya existente en el proyecto, podemos ejecutar el comando:

git status

Este comando nos mostrará cuales son los archivos que se han modificado, añadido o eliminado en la carpeta del proyecto, pero que están pendientes de ser grabados en el repositorio privado. Es decir, para guardar en el repositorio privado los cambios, debemos ejecutar algo como:

git commit -a -m “mensaje descriptivo de esta versión que se esta subiendo”

Una vez ejecutado este comando, nuestro repositorio privado debe tener la ultima versión que existe en nuestro sistema de los archivos. Pero siempre hablando de nuestro repositorio privado. Si ahora ejecutáramos un “git status” deberíamos comprobar que no queda nada por actualizar o añadir.

Sincronizando con el repositorio público:

Una vez que tenemos una versión que queremos compartir con el resto de los usuarios del sistema debemos sincronizar con el repositorio público. Ya que es un repositorio público, pueden darse errores, como por ejemplo que dos personas hayan modificado la misma linea del mismo archivo, y Git no sepa con exactitud cual es la correcta. Para evitar esto, el flujo de sincronización es invertido con respecto a lo que seria lo “natural”. Es decir, seria algo como:

Obtengo versión pública -> Soluciono errores de mezclado -> Actualizo versión pública

Para obtener la versión pública, debemos ejecutar algo como:

git pull [alias del repositorio] [nombre de la rama]

Pues eso, podemos configurar para obtener de varios repositorios diferentes, aunque no es lo común. Ademas de obtener de varios repositorios, podemos obtener de varias ramas, dentro de cada repositorio. El tema de las ramas no lo voy a tratar hoy, así que simplemente pensaremos que existe una sola rama que se llama “master”. La rama “master” se crea por defecto en Git. Tanto, la rama por defecto, como el repositorio por defecto pueden configurarse en el archivo de configuración del repositorio de git, de forma que podríamos trabajar simplemente con un “git pull” a secas si lo tenemos todo bien configurado.

Una vez obtenida la información del repositorio público, Git nos alertará en el caso de existir discordancias entre las versiones, y no nos dejara publicar hacia el servidor público hasta que las resolvamos. Una vez resueltas las discordancias, debemos hacer un commit, tal y como explicamos antes, y para terminar y subirlo al servidor público, debemos ejecutar un:

git push [alias del repositorio][nombre de la rama]

Si todo ha ido bien, el servidor público de Git debe tener nuestra versión del proyecto como la ultima versión.

Resumiendo:

El flujo natural de trabajo que yo sigo es el siguiente:

Al iniciar a trabajar: git pull para obtener la ultima versión de todas.
Editas, añades(git add) o eliminas(git rm) los archivos que sean.
Comprobación de que se ha cambiado con un git status, si falta algo por cambiar, volvemos al paso anterior.
Sincronizas con tu servidor privado con un: git commit -a -m “mensaje”
En el caso de querer actualizar el servidor público:
Obtenemos la ultima version de nuevo: git pull
Resolvemos las incoherencias entre las versiones
Comprobación de que se ha cambiado con un git status, si falta algo por cambiar, volvemos al paso anterior.
Hacemos un commit a nuestro repositorio local
Sincronizamos hacia el servidor público con: git push.

No soy ningún experto en Git, y he obviado muchas cosas, como las ramas (branchs) o mas información sobre la configuración de los repositorios remotos (origenes). Puedes consultar muchísima mas información, y mucho mas correcta y precisa en las páginas de información de Git. Y si observas que cualquier cosa es incorrecta o puede ser explicada de mejor forma, no te cortes y compártelo en los comentarios.