gusma

Dentro de mi espacio de trabajo habitual semanal, una de las cosas interesantes que descubrí esta semana es la inhabilidad de Adwords de manejar parámetros cuando una página determinada se encuentra bajo algún tipo de rewrite de ISAPI para sitios montados sobre IIS. Es algo que me ocurrió a decir verdad esta semana en la cual los de Adwords fuera de lo habitual pecan por inocentes. Parece ser que fuera de sus guidelines acerca de “sneaky redirects” y del harto poder legal de los 301 redirects y de los ISAPI rewrites para url’s “friendlies”, los redirects relacionados a campañas pagas son algo que no han terminado de zanjar.

Pongámoslo así, imaginemos que en una página determinada

http://www.gusma.com.ar (pongámosle)

intentando implementar un rewrite para una sección determinada que es

http://www.gusma.com.ar/index.aspx?id=20

pero que reescrita se ve como

http://www.gusma.com.ar/bife-con-papas-fritas

Ahora, continuando con esta lógica, lleguemos a la hora de implementar un aviso de campaña paga. El proceso en sí es bastante fácil,

En ciertos casos incluso copia la primera URL hacia la segunda, la destination URL, sabiendo que las dos pueden ser URI’s distintas, pero que sin embargo que fuera de cualquier parámetro que uno pueda incluir, Adwords per se incluye parámetros que corresponden a sus campañas (el &gclid=123456 y todo el string que corresponde), que efectivamente no son soportados. Nuestra URL concluirá en:

http://www.gusma.com.ar/bife-con-papas&gclid=467564567456

por más que en el “Destination URL” uno simplemente haya puedo http://www.gusma.com.ar/bife-con-papas. O sea que finalmente, uno, por un aviso o una keyword determinada recibe la url con un parámetro que ISAPI no acepta, pero que va incluido a la fuerza.

Y en la campaña paga uno se ve obligado, finalmente, a poner una display URL como la que creó con ISAPI, pero forzado simplemente a poner como target URL la primera url con ID, aquella que uno quiso destruir con rewrites para poseer una entrada más accesible o más search engine friendly (o sea, verse forzado a buscar de vuelta a través de la ISAPI el id original, http://www.gusma.com.ar/index.aspx?id=20).

Por lo que sé y he probado estos asuntos ya fueron zanjados con los famosísimos 301 redirects de URLs en Apache, no así se vé la solución a sitios con IIS, cuestión irónica ya que la mayoría de los filtros ISAPI, excepto los muy pequeños y destinados a sitios de poca envergadura (llámese un helicon isapi por ejemplo) si bien son gratuitos, cualquier implementación de ISAPI superior costará dinero. No sólo por el filtro en sí, sino por el dinero que uno arroja en campañas pagas que no están llevando a ningún resultado. En mi caso, afortunadamente, el reclamo fue oído y tuve respuesta (satisfactoria y suficientemente buena) de la gente de Google en EEUU.

(mi comentario es el numerado, lo consiguiente es la respuesta)

6) How is it that 301 redirects are allowed and ISAPIs are allowed in our guidelines, yet we don’t track those.

I am afraid I will not be able to comment on this as we have definitely seen concerns with redirects.

Whoops! Debo aclarar aquí que yo no debo estar sorprendiendo a nadie y tampoco reinventando la rueda. Aunque se que esto me va a complicar un poco la vida (más todavía si los ISAPIS sirvieron efectivamente para que un día yo dejase de usar esos feos ID’s! )

¿Será que al fin Google necesita adaptar su producto para que su producto sea un poco más amistoso con sus propios guidelines para webmasters?

¿Alguien sabe de algún modo de hacer un override al ISAPI o al htaccess, y que todavía pasen esos parámetros?

Tags: campañas pagas, google, seo

This entry was posted on Friday, January 16th, 2009 at 10:53 am and is filed under Search Engine Marketing. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

» Comments RSS Feed