SEO ¿tecnología o marketing?

Seguramente al leer este título se os vengan a la cabeza (sobretodo los que me conocéis) las diferentes disputas que he tenido a lo largo de los últimos 10 años con compañeros de la profesión. Para adelantar, siempre he defendido que el SEO es tecnología por una gran razón: los buscadores los programan ingenieros.

Independientemente de esto, estos días atrás tuve la oportunidad de asistir como profesor de WPO una vez más al Master SEO KSchool y fue cuando me di cuenta de que ya no tenemos porqué discutir sobre este asunto.

El Web Performance comenzó, para muchos, como una parte pequeña dentro del SEO, pero cada vez más va teniendo un peso distinto, ya que se puede aplicar WPO sin necesidad de tener que pensar en SEO. El WPO ya es una ciencia completa, de forma complementaria al SEO.

Con los alumnos al final llegamos a la conclusión de que todos los elementos del SEO más técnico se podían integrar en la parte del FEO (Front End Optimization) que, junto al SSO (Server Side Optimization) forman el WPO (Web Performance Optimization). Es decir, que el SEO hoy en día se quedaría principalmente con la parte más de marketing y contenidos y el WPO se lleva la parte más técnica. Que conste, por adelantado, que “hacer bien el HTML” para mi personalmente no es tecnología propiamente dicho, ya que eso es algo que hay que hacer bien por parte de cualquier persona que se dedique a Internet, forme parte del equipo que sea.

¿Qué significa todo esto para el sector? Pues la verdad es que creo que nos venía bien una especialización, en general, de todo. El SEO (para bien o para mal) ya no evoluciona mucho. Al final hay que acabar “haciendo las cosas bien” y sólo se detectan cambios cuando Google “toca” (algoritmos tipo Panda o Penguin) que básicamente lo que consiguen es que aquellos que hacen “trampas” o “las cosas mal” (sabiéndolo o no) se obliguen a mejorar. Pero el resto simplemente han de ir trabajando día a día. En cambio el WPO es un sector muy distinto al SEO, ya que, en paralelo a la tecnología, no deja de evolucionar. Cada vez que hay una nueva versión en un navegador, en un estándar (HTML, CSS, JavaScript…), que “fulanito” se inventa las pantallas 2K o 4K y requiere inventar un sistema para cargar imágenes con muchas resoluciones… todo este mundo cambia en pocos meses y no son muchos los que pueden seguir este ritmo ¡y sólo estoy hablando del FEO! Ya que si nos ponemos a habla de SSO hay que pensar hasta en reconfigurar el kernel de Linux si es necesario para optimizar las conexiones con el servidor.

Los alumnos del master me preguntaban que dónde se podía aprender todo esto del WPO, y la verdad es qe es algo bastante complejo… tengo la suerte de poder dedicar en mi día a día entre 1 y 2 horas a leer, documentarme y probar, en fin, a hacer un poco de I+D+I dentro de este sector y me encuentro la situación en la que es muy difícil encontrar otras personas con las que cruzar información. En España el único evento sobre WPO es precisamente el WebPerf, evento que ahora está parado porque es muy difícil encontrar ponentes que vengan a explicar alguna cosa… ¡y seguro que los hay! Así que habrá que seguir leyendo e investigando al resto del mundo para poder seguir evolucionando en esta parte más técnica.

Cómo dejar Windows 8 para trabajar tranquilamente

Sí, no te has equivocado si eres de los que usa Windows para trabajar y te ha llegado una edición de Windows 8 para tu nueva máquina y… te has dado cuenta de que tu pantalla no es táctil y no sabes qué hacer. Eso es lo que me pasó a mi hace una semana tras la forzosa compra de una nueva máquina.

Llevo usando Windows desde su versión 3.1, del año ’94. Tuve la oportunidad de usar Windows 95 en beta (eran unos 15 discos de 3,5″) e incluso hice reports y mandé soluciones a Microsoft, y hace unos años tuve la oportunidad de ser beta-tester de Windows 7 gracias a un programa en el que me metió Jaume en colaboración con Microsoft España.

Pero, una vez más, llega una “versión par” y lo joden todo. Lo siento, las cosas como son. Al cabo de 2 horas de usar Windows 8 estuve a punto de tirar el nuevo portátil por la ventana porque no sabía usar Windows, tras 18 años utilizándolo. ¿Cómo era posible? La respuesta es muy sencilla… si no tienes una pantalla táctil, no sirve para mucho.

Mi objetivo: convertir Windows 8 en Windows 7 dejando “el core”. Esto básicamente significa que no quiero para nada la interfaz “Windows UI” (aká Metro), que cuando arranque me vaya al escritorio y que cuando mueva el ratón a una esquina no aparezcan menús extraños de la nada.

Hablando con una persona cercana a Microsoft me dijo que en dos semanas me acostumbraría a la nueva interfaz (¿dos semanas? ¿estamos locos o qué?) así que me recomendó una aplicación llamada Start8 para “pasar el mal trago inicial”. Esta aplicación, que tardé en comprar menos de 24 horas tras ver lo que hacía, creo que acaba haciendo todo lo que estás pensando que necesitas, es decir, todo lo que he comentado antes que quería tener: el sistema Windows 8 con la interfaz de Windows 7.

Como la aplicación es válida por 30 días, recomiendo descargarla y probarla… al fin y al cabo podrás comprobar todo. ¿Qué configuración es necesaria? Pues simplemente voy a pegar capturas de pantalla de cómo me la he dejado yo para tener una interfaz “ideal”.

Y con esto verás como se te queda un Windows 8 ya disponible desde el primer minuto para poder “trabajar” con tranquilidad.

ARPANET y el origen de Internet

¿Tienes presente que “Internet” comenzó a gestarse en 1967 y que se puso “en línea” en 1969? Estas últimas semanas he tenido la oportunidad de revisar documentos oficiales y, por curiosidad, comencé a mirar la primera documentación que hubiera sobre Internet… pero, en realidad fui tirando para atrás y, al final, en el RFC 8 [ARPA Network Functional Specifications. G. Deloche. May 1969. (Status: UNKNOWN)] se habla de él…

Es curioso porque este documento no es muy sencillo de encontrar, pero buscando y buscando he conseguido una copia de ese RFC 8. Lo entretenido del documento es que no se entiende prácticamente nada y que sólo la primera página (la portada) está hecha a máquina de escribir. 7 páginas escritas y 2 de un diagrama es la base de Internet, iniciado todo por una petición del Departamento de Defensa de los USA. Gerard Deloche es el redactor de dicho documento, trabajando en UCLA, el 2º nodo de la red de redes el 21 de noviembre de 1969.

Unos años después, en diciembre de 1974, un señor llamado Vinton Cerf (este seguramente os suene algo más) publicaba la primera especificación de una cosa llamada “Internet”, el RFC 675 [Specification of Internet Transmission Control Program. December 1974. (Status: UNKNOWN)]. Que conste que el TCP se preparó antes, pero la especificación “final” apareció con ese documento. Y hay que tener en cuenta que esto sólo explica cómo transportar los paquetes, la información, pero no habla todavía de las direcciones IP; es el RFC 791 [Internet Protocol. J. Postel. September 1981. (Status: STANDARD)], entrada basada en las 6 versiones anteriores existentes del IP de DARPA.

This document specifies the DoD Standard Internet Protocol. This document is based on six earlier editions of the ARPA Internet Protocol Specification, and the present text draws heavily from them. There have been many contributors to this work both in terms of concepts and in terms of text. This edition revises aspects of addressing, error handling, option codes, and the security, precedence, compartments, and handling restriction features of the internet protocol.

Eso sí, mucho protocolo, mucho sistema de transporte pero hasta que el 1989 no se acabaron los OSI para el TCP/IP y que Tim Berners-Lee se inventase el HTML, el primer navegador (llamado WorldWideWeb) y se pusiera en marcha el primer servidor web en un Next (sí, esos ordenadores que fabricó Steve Jobs cuando lo echaron de Apple).

Además, hay un detalle que, si me paro a pensarlo fríamente es muy fuerte. Hasta 1993 el gobierno de Estados Unidos tenía como mandatario que Internet no podía tener un concepto comercial, sólo de comunicación académica, científica y gubernamental. Esto da mucho a pensar de los primeros buscadores, los primeros sitios web y que yo me comenzase a conectar en 1994 de tanto en tanto…

Hay mucha documentación en la red de redes sobre los comienzos de Internet, pero, la verdad, tras unas conversaciones con Xavier (compañero en el Postgrado Web Analytics) que colabora con el CERN, donde se cocinó y coció lo que hoy me da de comer, creo que valía la pena simplemente hacer un pequeño homenaje a todo esto tan grande que se ha creado prácticamente de la nada.

Los DNAME en las DNS

Aunque ahora mismo es tan sólo una propuesta, creo muy acertada esta nueva posible entrada de las DNS porque, sobretodo a nivel de rendimiento de WPO podría dar un salto cualitativo en cuanto a determinadas acciones que hacemos habitualmente con los dominios, más concretamente con las redirecciones. Incluso, he de añadir, para reducir el impacto de la cantidad de líneas que puede haber en los servidores DNS.

Para situarnos estoy hablando de la propuesta del RFC 6672 (DNAME Redirection in the DNS) que propone incorporar una entrada nueva llamada DNAME.

Para no entrar en detalles muy raros, voy a intentar poner un caso para ver el sentido que tiene. Imaginad que tenemos dos dominios iguales, con las mismas entradas DNS. Por ejemplo [example.com] y [dominio.es]. Dado este caso, en que los dos dominios son exactamente iguales (a nivel DNS)… ¿tiene sentido mantener dos copias de las entradas DNS? ¿No sería más fácil decir que las entradas DNS de [dominio.es] son una copia de las de [example.com] y simplemente cambiando las del .com que se actualizase todo?

Pues básicamente este es el objetivo de la entrada DNAME. El ejemplo visual (los que tocáis mucho las DNS seguramente lo pilléis enseguida:

    QNAME            owner  DNAME   target         result
    ---------------- -------------- -------------- -----------------
    com.             example.com.   example.net.   <no match>
    example.com.     example.com.   example.net.   [0]
    a.example.com.   example.com.   example.net.   a.example.net.
    a.b.example.com. example.com.   example.net.   a.b.example.net.
    ab.example.com.  b.example.com. example.net.   <no match>
    foo.example.com. example.com.   example.net.   foo.example.net.
    a.x.example.com. x.example.com. example.net.   a.example.net.
    a.example.com.   example.com.   y.example.net. a.y.example.net.
    cyc.example.com. example.com.   example.com.   cyc.example.com.
    cyc.example.com. example.com.   c.example.com. cyc.c.example.com.
    shortloop.x.x.   x.             .              shortloop.x.
    shortloop.x.     x.             .              shortloop.

El objetivo es que el campo “target” sea como el sustituto del patrón que se le pasa. De esta forma, poniendo la tercera línea de ejemplo, tendríamos que, partiendo de la base de [a.example.com] el dominio sería [example.com] y el DNAME sería [example.net], si hacemos un “sustituir” de [example.net] por [example.com] nos quedaría [a.example.net].

El planteamiento, a nivel de similitud, es como un CNAME con esteroides, ya que no deja de ser como un alias, pero que además sustituye fragmentos de las entradas DNS por otras que pueden ser de otro dominio.

Un detalle interesante es que, aunque no se recomienda su uso, se podría a llegar a utilizar el “wildcard” (o sea, el [*.example.com] para sustituir grandes cantidades de entradas DNS por otras. No se recomienda el uso porque podría invalidar el DNSSEC, pero la verdad, teniendo en cuenta la poca penetración que tiene, tampoco tengo claro que, para la mayoría, sea un problema.

Aunque no deja de ser una propuesta (en mi opinión muy interesante) no tengo claro que sea algo que se vaya a implementar rápidamente. Seguramente dependerá más de los ISP que comiencen a implementar servidores que lo soporten, pero, tampoco es algo que creo que sea muy recomendable para la gran mayoría de los usuarios, ya que un pequeño error puede provocar la invalidación de las DNS. Así que, lo más probable es que para añadir una entrada de este tipo se tengan que hacer varias validaciones “automáticas” para controlar las posibles cagadas poniendo estas entradas.

Keep It Simple Lab + Trip4Real = Kisslab4Real

Hace unas semanas os comentaba que habíamos entrado a formar parte de Boat Bureau y ahora me toca el turno de explicar un poco sobre otro proyecto emocionante en el que llevamos ya unos pocos meses, aunque tan sólo hace unos días que ha aparecido en escena de forma funcional (llevaba varias semanas como presentación). Es el proyecto Trip4Real.

¿Y qué es Trip4Real? Pues, básicamente son esas “cajitas de experiencias” que venden en muchos sitios pero adaptadas a la realidad: que gente local de cada ciudad proponga sus experiencias, explicarte y llevarte a los sitios que mejor conocen, llevarte a comer esas albóndigas que sabes que su madre hace tan ricas en alguna de las ciudades que la plataforma plantea.

Digamos que aquí hay 2 tipos de cliente y 1 tipo de proveedor. Los clientes posibles los separo en 2 (aunque quizá no sea necesario) porque me gustaría distinguir los extranjeros que vienen a la ciudad, pero que no conocen nada, ni el idioma, y por otro lado están los que no son extranjeros pero vienen a hacer turismo a una ciudad que, si fueran solos, conocerían “lo típico”. Los proveedores, pues esto es fácil: gente que lleva un tiempo (o toda la vida en la ciudad) y se la conoce como su palma de la mano.

Quería hacer esa separación porque, si bien es cierto que puedes ir a visitar, por ejemplo Barcelona, y pasearte por las Ramblas, ver la Sagrada Familia o subir a Montjuïc, quizá si eres de Segovia eso ya has tenido la oportunidad de hacerlo en alguna ocasión y prefieres, por ejemplo, irte a ese bar roñoso exótico en el que ponen esas croquetas que no sabías ni que existían pero que alguien de Bacelona sí que conoce. O por ejemplo irte a comer a un restaurante y que el chef te haga una visita por la cocina, te enseñe cómo lo hace y acabéis todos disfrutando de la misma. ¿Cuántas veces has podido hacer eso?

Otra de las cosas apasionantes de Trip4Real es el equipo, encabezados por Gloria Molins, la cabeza pensante del proyecto que lleva trabajando en él desde hace ya bastante tiempo y que tiene un elemento común con todos los que formamos el proyecto: viajar. Y es que, yo creo que en el fondo (como me ha pasado a mi en decenas de ocasiones), Gloria ha decidido hacer este proyecto para poder usarlo ella, para poderse meter en su sitio web, decidir un lugar e irse con los locales de cada ciudad a que la lleven a hacer las experiencias.

Sin duda un proyecto interesante, emocionante, que en el poco tiempo que llevamos nos está haciendo pensar y trabajar mucho y que creo que nos va a dar muchísimas sorpresas los próximos meses en muchos sentidos. Y hasta aquí puedo leer… ¡tar je ti taa por aquí…!

Dominios reservados

¿Cuál es el dominio que no existe y que deberíamos usar siempre que hacemos referencia a una dirección URI que no existe? Pues hay varios, no os lo voy a negar, y todo depende de las necesidades que tengamos.

Y es que existe el RFC 2606 que habla de esto mismo… los Reserved Top Level DNS Names. Básicamente este documento nos informa de los 4 TLD que hay cuando queremos hacer referencia a pruebas.

  • .test: Se recomienda para probar DNS.
  • .example: Se recomienda cuando en un documento se hace referencia a alguna dirección.
  • .invalid: Se recomienda cuando se hace referencia a dominios incorrectos o errores.
  • .localhost: Este es el único que técnicamente no es del todo un error o un ejemplo, ya que se puede utilizar internamente en las DNS para hacer una autollamada o hacer uso de direcciones IP privadas sobre él.

Claro está, esto es siempre para los TLD, pero ¿qué ocurre en los segundos nivele? Vamos, en lo que normalmente conocemos como un “dominio”? Para ello el sistema es claro: example.com, example.net y example.org.

Hay otros TLD de los nuevos que, ya de base, llevan una serie de limitaciones. Por ejemplo el .INFO define el dominio [example.info] como un dominio .info reservado en este caso para la IANA. Esto mismo ocurre con los dominios .biz reservados que excluyen el [example.biz]. En principio, el resto de dominios, como desde hace tiempo, son asignados y aprobados por IANA, ocurre lo mismo.

En el caso de los ccTLD no se especifica nada a nivel general, sino que el bloqueo de los dominios queda en manos de cada uno de los organismos. Por ejemplo, en NIC.ES, el organismo que regula los dominios “.es”, quedan prohibido según su documentación el [dominio.es]. Hay otros tantos, pero este parece ser el único que el organismo no usará (ya que aunque está prohibido, el [dominio.es] sí que lo utilizan como promoción, saltándose sus propias reglas (como decenas de veces han hecho en e pasado).

En otros casos, como por ejemplo el dominio francés .FR (y todos los que gestiona el organismo) no plantea un dominio de segundo nivel reservado para este uso. Sí que es cierto que disponen de varios dominios reservados, pero concretamente para hacerse eco de un ejemplo de uso no.

Así que a partir de ahora, si vas a escribir una entrada hablando de dominios de ejemplo, o tienes que referirte a ellos, ya sabes que has de analizar de forma diferente lo general de los dominios territoriales.

Recomendaciones de Google cuando se va a programar en HTML

Google genera mucho contenido de código abierto, y entre este se encuentra muchísmo código de programación. Pues existen una serie de guías en las que se recomiendan determinadas formas de trabajar que pueden ser interesantes, principalmente (al menos a mi) las que hacen referencia al HTML. Me gustaría destacar algunas de las recomendaciones… que no significa que yo las use o que esté de acuerdo, pero creo que son mencionables.

Uso del protocolo

No se recomienda indicar el uso del protocolo en cuestión cuandos e llama a un objeto. A mi me gusta ponerlo, y aunque sé que en el RFC se dice que no es necesario…

<!-- No recomendado -->
<script src="http://www.example.com/example.js"></script>
<!-- Sí recomendado -->
<script src="//www.example.com/example.js"></script>

Indentación

Algo que yo suelo hacer… que el código esté bien ordenado. Para ello las “tabulaciones” se indicarán con 2 espacios (se recomienda no usar tabulaciones, aunque yo es lo que uso).

<ul>
  <li>Fantastic</li>
  <li>Great</li>
</ul>

Mayúsculas/Minúsculas

Se recomienda que todo el HTML esté en minúculas:

<!-- No recomendado -->
<A HREF="/">Home</A>
<!-- Sí recomendado -->
<img src="example.png" alt="Google">

Espacios en blanco

Es mejor no dejar espacios en blanco si no son necesarios.

<!-- No recomendado -->
<p>¿Qué? </p>
<!-- Sí recomendado -->
<p>Gracias</p>

Codificación

Esto es muy sencillo… se recomienda el uso de UTF-8 (sin BOM). Además, en las plantillas HTML se debe indicar la meta-etiqueta correspondiente:

<meta charset="utf-8">

HTML5

Se prefiere HTML5 en los documentos, con su cabecera correspondiente:

<!DOCTYPE html>

Esto también incluye el uso del MIME text/html y no de XHTML y, por ello, no hace falta cerrar las etiquetas o sea, es mejor <br> y no <br />.

Código HTML válidado

Algo de lo que siempre hay muchas discusiones… personalmente es lgo que me gusta cumplir, al menos cuando la web no tiene códigos de publicidad u otros elementos externos.

<!-- No recomendado -->
<title>Test</title>
<article>This is only a test.
<!-- Sí recomendado -->
<!DOCTYPE html>
<meta charset="utf-8">
<title>Test</title>
<article>This is only a test.</article>

Semántica

Hay que usar el HTML según su valor inicial, esdecir, un P es un párrafo, y un A un enlace.

<!-- No recomendado -->
<div onclick="visitarRecomendados();">Recomendados</div>
<!-- Sí recomendado -->
<a href="/recomendados/">Recomendados</a>

Multimedia

Hay que proveer de contenido alternativo en el caso de uso de elementos multimedia. Por ejemplo, las imágenes deberían llevar un texto alternativo.

<!-- No recomendado -->
<img src="example.png">
<!-- Sí recomendado -->
<img src="example.png" alt="Contenido de ejemplo.">

Inter dependencia

Hay que intentar mantener diferenciado y desvinculado el código de la página, de la estructura (markup) de la presentación (styling) del comportamiento con los mismos (scripting).

Evitar entidades

Gracias al UTF-8, es casi innecesario el uso de entidades HTML (por ejemplo el &eur para representar ). Sólo hay dos excepciones habituales que son el & y el < o >.

<!-- No recomendado -->
El símbolos del Euro es: &ldquo;&eur;&rdquo;.
<!-- Sí recomendado -->
El símbolos del Euro es: “€”.

Etiquetas opcionales

Este es otro de esos puntos en los que no estoy 100% de acuerdo. Si bien es cierto qu una de las grandísimas ventajas del HTML5 es que no es necesario escribir todo el código estructurado como hasta ahora, no tengo muy claro que sea interesante de cara a la compatibilidad con todo.

<!-- No recomendado -->
<!DOCTYPE html>
<html>
  <head>
    <title>gastando bytes</title>
  </head>
  <body>
    <p>Mal.</p>
  </body>
</html>
<!-- Sí recomendado -->
<!DOCTYPE html>
<title>ahorrando bytes</title>
<p>Bien.

Atributo “type”

En cambio, esta sí que la considero del todo útil (ya que antes me arecía completamente inútil). En principio los ficheros externos a los que llamamos (por ejemplo .CC o .JS) no es necesarios indicarles el MIME al que mandamos (al fin y al cabo, los ficheros ya lo indican per sé).

<!-- No recomendado -->
<link rel="stylesheet" href="//www.google.com/css/maia.css" type="text/css">
<!-- Sí recomendado -->
<link rel="stylesheet" href="//www.google.com/css/maia.css">
<!-- No recomendado -->
<script src="//www.google.com/js/gweb/analytics/autotrack.js" type="text/javascript"></script>
<!-- Sí recomendado -->
<script src="//www.google.com/js/gweb/analytics/autotrack.js"></script>

Formateado general

Hay que usar un salto de línea para aquellos bloques, listas o tablas e indentar cada elemento hijo. Esta es otra de las recomendaciones que agradezco, porque veo programadores que han hecho mucho daño al HTML.

<blockquote>
  <p><em>prueba</em> de un texto cualquiera.</p>
</blockquote>
<ul>
  <li>José
  <li>María
  <li>Juan
</ul>
<table>
  <thead>
    <tr>
      <th scope="col">Ingresos
      <th scope="col">Gastos
  <tbody>
    <tr>
      <td>5,00 €
      <td>4,50 €
</table>

Uso de comillas

Se recomienda el uso de comillas dobles en vez de comilla simple para los atributos.

<!-- No recomendado -->
<a class='boton boton-alternativo'>Acceder</a>
<!-- Sí recomendado -->
<a class="boton boton-alternativo">Acceder</a>

También hay una serie de recomendaciones para las hojas de estilo CSS. A parte de que el CSS debería validar (algo lógico). Además, se recomeinda que el nombre de las clases sea corto y genérico. Por ejemplo, es más recomendable usar #nav que #navegacion o usar .aux que no .boton-verde.

Selectores

Además, por un tema de rendimiento (muy importante de cara al WPO) hay que intentar ir al elemento más concreto que incliur los generales. Yo principalmente lo veo claro con los ID, pero no siempre con las clases.

/* No recomendado */
ul#ejemplo {...}
div.error {...}
/* Sí recomendado */
#ejemplo {...}
.error {...}

Propiedades cortas

Algunos elementos permiten propiedades agregadas…

/* No recomendado */
border-top-style: none;
font-family: palatino, georgia, serif;
font-size: 100%;
line-height: 1.6;
padding-bottom: 2em;
padding-left: 1em;
padding-right: 1em;
padding-top: 0;
/* Sí recomendado */
border-top: 0;
font: 100%/1.6 palatino, georgia, serif;
padding: 0 1em 2em;

Valores 0

Los datos que son de valor 0 no requieren de unidades para acompañarlo. De la misma forma, si un vaor va entre -1 y 1, no es necesario indicar el 0.

margin: 0;
padding: 0;
font-size: .8em;

Hexadecimal

Hay que intentar usar los colores cuanto más cortos mejor. De esta forma, si hay colores que se pueden reducir a 3 caracteres, mejor.

/* No recomendado */
color: #eebbcc;
/* Sí recomendado */
color: #ebc;

Ordenar los elementos

Se recomienda ordenar los elementos de forma alfabética. Claro está dentro de cada elemento.

background: fuchsia;
border: 1px solid;
-moz-border-radius: 4px;
-webkit-border-radius: 4px;
border-radius: 4px;
color: black;
text-align: center;
text-indent: 2em;

Finalizar las declaraciones

Al final de cada uno de los elementos se recomienda finalizar con un punto y coma.

/* No recomendado */
.test {
  display: block;
  height: 100px
}
/* Sí recomendado */
.test {
  display: block;
  height: 100px;
}

Separar propiedades y valores

Siempre utilizar un espacio entre las distintas propiedades y sus valores, pero no entre el valor y el punto y coma final.

/* No recomendado */
h3 {
  font-weight:bold;
}
/* Sí recomendado */
h3 {
  font-weight: bold;
}

Selectores y declaraciones

Siempre separar cada selector en una línea distinta de otro selector. Además separara con un salto de línea cada regla.

/* No recomendado */
a:focus, a:active {
  position: relative; top: 1px;
}
/* Sí recomendado */
h1,
h2,
h3 {
  font-weight: normal;
  line-height: 1.2;
}
html {
  background: #fff;
}

body {
  margin: auto;
  width: 50%;
}

Comillas

A diferencia del HTML, en los CSS es mejor evitar las comillas, y en caso necesario (como en los nombres de tipos de letra) usar la comilla simple .

/* No recomendado */
@import url("//www.example.com/css/estilo.css");

html {
  font-family: "open sans", arial, sans-serif;
}
/* Sí recomendado */
@import url(//www.example.com/css/estilo.css);

html {
  font-family: 'open sans', arial, sans-serif;
}

En fin, son simples sugerencias de reglas, unas más aceptables que otras… pero las que Google utiliza internamente cuando tiene que liberar código al mundo mundial. Así que, si quieres ser un buen googler ya sabes lo que te toca hacer.

NoIndex del robots.txt

¿Te has preguntado si tu fichero robots.txt aparece en Google? La respuesta es que, en principio, sí, puede aparecer. Puedes hacer una prueba con una consulta similar a esta [site:javiercasares.com inurl:”robots.txt”].

Es curioso que un fichero que en principio sólo deberían leer los propios rastreadores aparezca en los resultados de búsqueda y que, por norma general nadie se preocupe de evitar que se indexe… pero ¿es posible no indexar este fichero? La respuesta es simple: sí.

Para eliminar de los resultados de búsqueda este fichero robots.txt tenemos dos opciones:

  • Eliminarlo desde el propio robots.txt, es decir, añadir una línea Disallow: /robots.txt.
  • Eliminarlo desde una cabecera HTTP, como X-Robots-Tag: noindex.

Personalmente recomiendo el uso de la segunda opción, ya que el hecho de aplicar un “noindex” implica que sí pueda ser leído pero no mostrado, y la primera, en algún otro buscador, podría ser que no se permitiera su lectura en una siguiente actualización.