servidores

Si bien la mayor parte de las veces, el spider que ingresa a un website para navegar las páginas pertenece a un buscador, la realidad es que no faltan robots maliciosos que se dediquen a descargar indiscriminadamente contenido y ha recopilar información de modo clandestino.

Normalmente, el uso del archivo “robots.txt” es inútil, porque directamente es salteado, por lo que “.htaccess” constituye la única barrera para detenerlos. Una manera bastante común es forzar el error 403 ante su intento. El siguiente código encierra algunos de los bots malignos más conocidos:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot@yahoo.com [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} HTTrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} Indy\ Library [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR]
RewriteCond %{HTTP_USER_AGENT} ^larbin [OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR]
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Wget [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus
RewriteRule .* - [F]

Lista extraída de: http://www.enespanol.com.ar/2006/04/03/tutorial-de-htaccess/#7

Desde hace un tiempo, es conocido que Google toma en cuenta la velocidad de carga de una página como un parámetro para determinar el ranking de una página. Sin embargo, hasta ahora se había revelado de manera oficial, por lo que el servidor estaría jugando un papel aún más importante, condicionando el ranking con su velocidad de respuesta.

Esto guarda también una importante relación con la “necesidad” de rapidez que tienen los usuarios. Tanto las webs tradicionales como el mismo sistema AdSense, muestran un mejor desempeño directamente proporcional a la agilidad con que cargue las páginas un servidor. Hubo casos extremos como el de Amazon, dónde un segundo más de carga determinaba miles de dólares de pérdida por “clientes perdidos”.

Tal como describíamos en el párrafo anterior con el caso de Amazon.com, una demora excesiva o mayor de lo esperada en la carga de una página, normalmente implica la pérdida de una visita. Con esta novedad, ya no sólo tendremos este factor en cuenta, sino el hecho de que Google tomará en cuenta la velocidad para privilegiar las páginas más rápidas.

La idea principal detrás de todo esto es acercarse cada vez más a los resultados que se requieren para poner en funcionamiento la búsqueda en tiempo real que Google viene intentando. Revisando la frecuencia y alcance de los bots, el rastreo es muchísimo más continuo, pero relegando para esto un poco de profundidad. Tema polémico si los hay, deja como única posibilidad confiar en Google y su capacidad.

Aunque a simple vista pueda parecer bastante sencillo de utilizar, un archivo “.htaccess” guarda grandes posibilidades. Por lo tanto, resulta lógico que de su uso puedan desprenderse algunas situaciones colaterales conflictivas. Los dejamos con algunos consejos básicos a seguir en la estructuración de este interesantísimo fichero.

El primero de ellos, común también al campo de la programación, es mantener su código ordenado. Utilizar comentarios comenzando con “#” que describan situaciones especiales u observaciones, es fundamental para entender lo escrito durante una revisión o en la medida que aumenta su complejidad.

Otro punto muy importante es el tamaño del “.htaccess”. No debe pasarse por alto el hecho de que un servidor procesa estas líneas ante cada petición, por lo que este factor condicionará notablemente la velocidad de respuesta a un usuario que se encuentra navegando el sitio web.

Finalmente, también es un deber tomar en cuenta el sistema de herencia que utiliza este archivos. Dentro de las posibilidades de configuración, es posible aplicar un “.htaccess” por directorio, caso en el que serán reemplazadas con estas reglas las que haya implementado el archivo perteneciente al directorio raíz. Si se desean crear reglas generales, debe tenerse cuidado en no “pisar” estas directivas globales con directivas locales.

En el anterior artículo, comentamos un poco la definición más básica del archivo “.htaccess” y una de sus posibilidades más conocidas, la restricción de acceso web a un directorio y/o fichero, combinada también con el permiso a IPs determinadas. Esta vez trataremos un poco sobre otro caso bastante común: la personalización del “Error 404”.

Se denomina de esa forma al error que devuelve un servidor cuando se intenta acceder a una página que ya no está en la dirección que se requiere o que directamente no existe. Es posible dejar el mensaje por defecto, pero si queremos mostrar una estructura más profesional, es buena idea crear un mensaje personalizado que mantenga el aspecto del web y permita volver atrás con un simple botón.

Para redireccionar cualquier “Error 404” a una página personalizada, basta con abrir el archivo “.htaccess” (o crearlo en caso de que no exista ya) y escribir lo siguiente:

ErrorDocument 404 /directorioEjemplo/error404.html

Obviamente, habrá que cambiar nombres de acuerdo a como le hayamos programado. Esto resulta interesante, porque además, bastará con cambiar el número “404” por cualquiera para redireccionar otros errores.

Es importante el peso de la página personalizada, porque en algunas versiones de Internet Explorer toda página de 404 menor a los 512 bytes es redireccionada hacia su buscador propio, perdiéndose la visita.

Se llama “.htaccess” (acrónimo de “hyper-text access”) al archivo que se ocupa de manejar la configuración de acceso a directorios/ficheros en los servidores HTTP Apache. Su principal utilidad es darle al webmaster la posibilidad de regular las directivas de seguridad desde un setup maestro que restringe o permite determinados archivos.

Su programación requiere de un trabajo cuidadoso, ya que el otorgamiento/denegación de permisos puede tener implicancias muy importantes. En esta serie de artículos, nos ocuparemos de tratar algunas situaciones bastante habituales cuando se piensa en la modificación de este archivo.

Una de ellas es la restricción de acceso a una carpeta o directorio, muy útil para mantener fuera de vista ficheros que consideremos particularmente importantes para el funcionamiento del site. Para llevar adelante esta práctica, basta con crear un archivo “.htaccess” dentro de la carpeta a la cual queremos aplicar las directivas.

Para denegar los accesos por completo, escribiremos el siguiente código:

#deny all access
deny from all

Puede pasar que, por razones particulares, necesitemos que una IP en particular pueda acceder, por lo que agregaremos la siguiente línea:

allow from xxx.xxx.xxx.xxx (donde “xxx.xxx.xxx.xxx” los números que correspondan)

Podemos ir aún más lejos, limitando un rango específico de IP:

allow from xxx.xxx.xxx.xxx/24

Y finalmente, en lugar de bloquear un directorio, hacerlo con un fichero en particular:

<Files archivo.php>
Order allow,deny
Deny from all

Pregunta del millón, los foros están llenos de ellas y parece que nadie está seguro o nadie acaba de contarlo todo. En realidad son dos preguntas:

• Influye el alojamiento en el posicionamiento web 
• Y, si influye el alojamiento, influye también la dirección ip o la localización geográfica de dicho posicionamiento?

Vayamos por pasos. El alojamiento web influye, confirmado por el propio Matt Cuts, en el posicionamiento, e influye desde el punto de vista de la velocidad de respuesta de tu página. Es decir, si tu web responde de manera lenta, podrías perder, según los responsables de Google, hasta un 40% de tráfico.

Eso es una barbaridad, imaginaos nuestra red de contenidos donde tenemos unas 10.000 visitas diarias a día de hoy.  Un 40% es una caída de ingresos brutal, y volver a la situación de nuestra red de hace 1 o incluso 2 años.

Por otro lado, la ip geográfica influye en el posicionamiento? Bueno, en primer lugar lo que los buscadores tienen en cuenta es la extensión de tu dominio. Si es un .es posicionará mejor en España, si es un .mx posicionará mejor en Mexico... Luego comentaré algunos resultados de experimentos propios.

Dicho esto, si tu dominio es un .es y encuentras un servidor en la India que funciona mejor que uno que tienes en España, los buscadores no tienen nada que decir al respecto. Ahora bien, esto es francamente difícil que ocurra por una razón bien sencilla. Un servidor en España va a responder mucho más rápido ante peticiones dentro de la propia red del país que un servidor situado en otro país (en otra red por tanto). Si nos vamos a la India, o a Estados Unidos donde hay mucha distancia e incluso un océano de por medio es bastante improbable que ese servidor responda mejor que uno en España (o en tu propio país).

Da igual que el servidor tenga una conexión de 1000 megas por segundo y tu hosting en España no llegue a los 10, o que la potencia del servidor sea 10 veces superior con procesadores de última generacion, blablabla. Lo que importa es la enorme distancia que tendrán que recorrer tus paquetes por la red hasta llegar a su destino. Si esos paquetes a penas recorren unos decenas de kilómetros la página se abrirá en décimas de segundo, la respuesta del servidor será más rápida, simplemente porque su origen y destino está mucho más cerca.

Así pues, a la primera pregunta, si, el alojamiento y la velocidad de respuesta importa, y en breve importará mucho mas según las declaraciones y movimientos que se están viendo en Google.

A la segunda, puedes contratar un servidor en Francia, o incluso en Alemania o Gran Bretaña, en países vecinos al tuyo, y usar una ip geográfica que posicione tu servidor en España (una pequeña triquiñuela). Ahora bien asegúrate de que ese servidor sea rápido, cuanto más rápido mejor.

Otro dia hablaré sobre un caso particular de un dominio .com y de un .es. El video lo encontré en s3optimizacion.blogspot.com