Veo dos problemas con la aplicación AngularJS con respecto a los motores de búsqueda y SEO:

1) ¿Qué sucede con las etiquetas personalizadas? ¿Los motores de búsqueda ignoran todo el contenido de esas etiquetas? es decir, supongamos que tengo

<custom>
  <h1>Hey, this title is important</h1>
</custom>

se <h1>indexaría a pesar de estar dentro de etiquetas personalizadas?

2) ¿Hay alguna manera de evitar que los motores de búsqueda de indexación {{}} se unan literalmente? es decir

<h2>{{title}}</h2>

Sé que podría hacer algo como

<h2 ng-bind="title"></h2>

pero ¿qué pasa si quiero dejar que el rastreador "vea" el título? ¿Es la representación del lado del servidor la única solución?

Actualización de mayo de 2014

Los rastreadores de Google ahora ejecutan JavaScript : puede usar las Herramientas para webmasters de Google para comprender mejor cómo sus sitios son representados por Google.

Respuesta original
Si desea optimizar su aplicación para motores de búsqueda, desafortunadamente no hay forma de ofrecer una versión pre-renderizada al rastreador. Puede leer más sobre las recomendaciones de Google para sitios ajax y javascript pesados aquí .

Si esta es una opción, recomendaría leer este artículo sobre cómo hacer SEO para Angular con renderizado del lado del servidor.

No estoy seguro de qué hace el rastreador cuando encuentra etiquetas personalizadas.

Utilice PushState y precomposición

La forma actual (2015) de hacer esto es usando el método pushState de JavaScript.

PushState cambia la URL en la barra superior del navegador sin volver a cargar la página. Digamos que tiene una página que contiene pestañas. Las pestañas ocultan y muestran contenido, y el contenido se inserta dinámicamente, ya sea usando AJAX o simplemente configurando display: none y display: block para ocultar y mostrar el contenido de pestaña correcto.

Cuando se hace clic en las pestañas, use pushState para actualizar la url en la barra de direcciones. Cuando se representa la página, use el valor en la barra de direcciones para determinar qué pestaña mostrar. El enrutamiento angular lo hará automáticamente.

Precomposición

Hay dos formas de acceder a una aplicación PushState Single Page (SPA)

1. A través de PushState, donde el usuario hace clic en un enlace de PushState y el contenido se incluye en AJAX.
2. Al presionar la URL directamente.

El golpe inicial en el sitio implicará golpear la URL directamente. Los éxitos posteriores simplemente AJAX en el contenido a medida que PushState actualiza la URL.

Los rastreadores recopilan enlaces de una página y luego los agregan a una cola para su posterior procesamiento. Esto significa que para un rastreador, cada golpe en el servidor es un golpe directo, no navega a través de Pushstate.

La precomposición agrupa la carga útil inicial en la primera respuesta del servidor, posiblemente como un objeto JSON. Esto permite que el motor de búsqueda muestre la página sin ejecutar la llamada AJAX.

Hay alguna evidencia que sugiere que Google podría no ejecutar solicitudes AJAX. Más sobre esto aquí:

https://web.archive.org/web/20160318211223/http://www.analog-ni.co/precomposing-a-spa-may-become-the-holy-grail-to-seo

Los motores de búsqueda pueden leer y ejecutar JavaScript

Google ha podido analizar JavaScript desde hace algún tiempo, es por eso que originalmente desarrollaron Chrome, para actuar como un navegador sin cabeza con todas las funciones para la araña de Google. Si un enlace tiene un atributo href válido, se puede indexar la nueva URL. No hay nada más que hacer.

Si, al hacer clic en un enlace, se activa una llamada pushState, el usuario puede navegar por el sitio a través de PushState.

Soporte de motores de búsqueda para URL de PushState

PushState es actualmente compatible con Google y Bing.

Google

Aquí está Matt Cutts respondiendo a la pregunta de Paul Irish sobre PushState para SEO:

http://youtu.be/yiAF9VdvRPw

Aquí está Google anunciando soporte completo de JavaScript para la araña:

http://googlewebmastercentral.blogspot.de/2014/05/understanding-web-pages-better.html

El resultado es que Google admite PushState e indexará las URL de PushState.

Consulte también la búsqueda de herramientas para webmasters de Google como Googlebot. Verás que tu JavaScript (incluido Angular) se ejecuta.

Bing

Aquí está el anuncio de Bing de soporte para bonitas URL de PushState con fecha de marzo de 2013:

http://blogs.bing.com/webmaster/2013/03/21/search-engine-optimization-best-practices-for-ajax-urls/

¡No uses HashBangs #!

Las URL de Hashbang eran una solución fea que requería que el desarrollador proporcionara una versión pre-renderizada del sitio en una ubicación especial. Todavía funcionan, pero no necesitas usarlos.

Las URL de Hashbang se ven así:

domain.com/#!path/to/resource

Esto se emparejaría con una metaetiqueta como esta:

<meta name="fragment" content="!">

Google no los indexará de esta forma, sino que extraerá una versión estática del sitio de la URL _escaped_fragments_ e indexará eso.

Las URL de estado de inserción se parecen a cualquier URL normal:

domain.com/path/to/resource

La diferencia es que Angular los maneja por usted al interceptar el cambio en document.location que lo trata en JavaScript.

Si desea utilizar las URL de PushState (y probablemente lo haga), elimine todas las URL y metatags de estilo hash y simplemente habilite el modo HTML5 en su bloque de configuración.

Probar su sitio

Las herramientas para webmasters de Google ahora contienen una herramienta que le permitirá buscar una URL como google y representar JavaScript como lo hace Google.

https://www.google.com/webmasters/tools/googlebot-fetch

Generando URL de PushState en Angular

Para generar URL reales en Angular, en lugar de # prefijas, configure el modo HTML5 en su objeto $ locationProvider.

$locationProvider.html5Mode(true);

Lado del servidor

Como está utilizando URL reales, deberá asegurarse de que su servidor envíe la misma plantilla (más algún contenido precompuesto) para todas las URL válidas. La forma de hacerlo variará según la arquitectura de su servidor.

Mapa del sitio

Su aplicación puede usar formas inusuales de navegación, por ejemplo, desplazarse o desplazarse. Para garantizar que Google pueda manejar su aplicación, probablemente sugiera crear un mapa del sitio, una lista simple de todas las URL a las que responde su aplicación. Puede colocar esto en la ubicación predeterminada (/ sitemap o /sitemap.xml), o informar a Google al respecto utilizando las herramientas para webmasters.

Es una buena idea tener un mapa del sitio de todos modos.

Soporte del navegador

Pushstate funciona en IE10. En navegadores antiguos, Angular volverá automáticamente a las URL de estilo hash

Una página de demostración

El siguiente contenido se representa utilizando una URL pushstate con precomposición:

http://html5.gingerhost.com/london

Como se puede verificar, en este enlace , el contenido está indexado y aparece en Google.

Sirviendo códigos de estado de encabezado 404 y 301

Debido a que el motor de búsqueda siempre llegará a su servidor para cada solicitud, puede servir códigos de estado de encabezado desde su servidor y esperar que Google los vea.

Vamos a ser definitivos sobre AngularJS y SEO

Google, Yahoo, Bing y otros motores de búsqueda rastrean la web de manera tradicional utilizando los rastreadores tradicionales. Ejecutan robots que rastrean el HTML en las páginas web y recopilan información en el camino. Mantienen palabras interesantes y buscan otros enlaces a otras páginas (estos enlaces, la cantidad de ellos y la cantidad de ellos entran en juego con SEO).

Entonces, ¿por qué los motores de búsqueda no tratan con sitios javascript?

La respuesta tiene que ver con el hecho de que los robots del motor de búsqueda funcionan a través de navegadores sin cabeza y, a menudo, no tienen un motor de representación de JavaScript para representar el JavaScript de una página. Esto funciona para la mayoría de las páginas, ya que a la mayoría de las páginas estáticas no les importa que JavaScript represente su página, ya que su contenido ya está disponible.

¿Qué se puede hacer al respecto?

Afortunadamente, los rastreadores de los sitios más grandes han comenzado a implementar un mecanismo que nos permite hacer que nuestros sitios de JavaScript sean rastreables, pero requiere que implementemos un cambio en nuestro sitio .

Si cambiamos nuestro hashPrefixpara ser en #!lugar de simplemente #, los motores de búsqueda modernos cambiarán la solicitud para usar en _escaped_fragment_lugar de #!. (Con el modo HTML5, es decir, donde tenemos enlaces sin el prefijo hash, podemos implementar esta misma función mirando el User Agentencabezado en nuestro backend).

Es decir, en lugar de una solicitud de un navegador normal que se parece a:

http://www.ng-newsletter.com/#!/signup/page

Un motor de búsqueda buscará en la página con:

http://www.ng-newsletter.com/?_escaped_fragment_=/signup/page

Podemos establecer el prefijo hash de nuestras aplicaciones angulares utilizando un método incorporado desde ngRoute:

angular.module('myApp', [])
.config(['$location', function($location) {
  $location.hashPrefix('!');
}]);

Y, si estamos usando html5Mode, necesitaremos implementar esto usando la metaetiqueta:

<meta name="fragment" content="!">

Recordatorio, podemos configurarlo html5Mode()con el $locationservicio:

angular.module('myApp', [])
.config(['$location', 
function($location) {
  $location.html5Mode(true);
}]);

Manejo del buscador

Tenemos muchas oportunidades para determinar cómo lidiaremos con la entrega real de contenido a los motores de búsqueda como HTML estático. Podemos alojar un back-end nosotros mismos, podemos usar un servicio para alojar un back-end para nosotros, podemos usar un proxy para entregar el contenido, etc. Veamos algunas opciones:

Autohospedado

Podemos escribir un servicio para manejar el rastreo de nuestro propio sitio usando un navegador sin cabeza, como phantomjs o zombiejs, tomando una instantánea de la página con datos renderizados y almacenándola como HTML. Cada vez que vemos la cadena de consulta ?_escaped_fragment_en una solicitud de búsqueda, podemos entregar la instantánea HTML estática que tomamos de la página en lugar de la página renderizada previamente solo a través de JS. Esto requiere que tengamos un backend que entregue nuestras páginas con lógica condicional en el medio. Podemos usar algo como el backend de prerender.io como punto de partida para ejecutar esto nosotros mismos. Por supuesto, todavía tenemos que manejar el proxy y el manejo de fragmentos, pero es un buen comienzo.

Con un servicio pago

La forma más fácil y rápida de obtener contenido en el motor de búsqueda es usar un servicio Brombone , seo.js , seo4ajax y prerender.io son buenos ejemplos de estos que alojarán la representación de contenido anterior para usted. Esta es una buena opción para los momentos en que no queremos ocuparnos de ejecutar un servidor / proxy. Además, generalmente es súper rápido.

Para obtener más información sobre Angular y SEO, escribimos un extenso tutorial sobre esto en http://www.ng-newsletter.com/posts/serious-angular-seo.html y lo detallamos aún más en nuestro libro ng-book: El libro completo sobre AngularJS . Compruébalo en ng-book.com .

Realmente deberías consultar el tutorial sobre cómo construir un sitio AngularJS compatible con SEO en el año del blog moo. Te guía a través de todos los pasos descritos en la documentación de Angular. http://www.yearofmoo.com/2012/11/angularjs-and-seo.html

Con esta técnica, el motor de búsqueda ve el HTML expandido en lugar de las etiquetas personalizadas.

Esto ha cambiado drásticamente.

http://searchengineland.com/bing-offers-recommendations-for-seo-friendly-ajax-suggests-html5-pushstate-152946

Si usa: $ locationProvider.html5Mode (verdadero); estás listo

No más páginas de renderizado.

Las cosas han cambiado bastante desde que se hizo esta pregunta. Ahora hay opciones para permitir que Google indexe su sitio AngularJS. La opción más fácil que encontré fue utilizar el servicio gratuito http://prerender.io que generará las páginas que se pueden cursar para usted y lo servirá a los motores de búsqueda. Es compatible con casi todas las plataformas web del lado del servidor. Recientemente comencé a usarlos y el soporte también es excelente.

No tengo ninguna afiliación con ellos, esto proviene de un usuario feliz.

El sitio web de Angular ofrece contenido simplificado a los motores de búsqueda: http://docs.angularjs.org/?_escaped_fragment_=/tutorial/step_09

Digamos que su aplicación Angular está consumiendo una API JSON Node.js / Express, como /api/path/to/resource. Tal vez podría desviar todas las peticiones con ?_escaped_fragment_a /api/path/to/resource.html, y utilizar la negociación de contenido para hacer una plantilla HTML del contenido, en lugar de regresar los datos JSON.

Lo único es que sus rutas angulares tendrían que coincidir 1: 1 con su API REST.

EDITAR : Me estoy dando cuenta de que esto tiene el potencial de enturbiar realmente su API REST y no recomiendo hacerlo fuera de casos de uso muy simples en los que podría ser un ajuste natural.

En su lugar, puede usar un conjunto completamente diferente de rutas y controladores para su contenido amigable con los robots. Pero luego está duplicando todas sus rutas y controladores AngularJS en Node / Express.

Me decidí a generar instantáneas con un navegador sin cabeza, aunque siento que es un poco menos que ideal.

Una buena práctica se puede encontrar aquí:

http://scotch.io/tutorials/javascript/angularjs-seo-with-prerender-io?_escaped_fragment_=tag

A partir de ahora Google ha cambiado su propuesta de rastreo AJAX.

Los tiempos han cambiado. Hoy en día, siempre y cuando no esté bloqueando que Googlebot rastree sus archivos JavaScript o CSS, generalmente podemos renderizar y comprender sus páginas web como navegadores modernos.

tl; dr: [Google] ya no recomienda la propuesta de rastreo AJAX [Google] realizada en 2009.

La especificación Crawlable Ajax de Google, como se menciona en las otras respuestas aquí, es básicamente la respuesta.

Si está interesado en cómo otros motores de búsqueda y bots sociales tratan los mismos problemas, escribí el estado del arte aquí: http://blog.ajaxsnapshots.com/2013/11/googles-crawlable-ajax-specification.html

Trabajo para una https://ajaxsnapshots.com , una compañía que implementa la especificación Crawlable Ajax como un servicio; la información en ese informe se basa en observaciones de nuestros registros.

He encontrado una solución elegante que cubriría la mayoría de sus bases. Inicialmente escribí sobre esto aquí y respondí otra pregunta similar de StackOverflow aquí que hace referencia a ella.

Para su información, esta solución también incluye etiquetas de respaldo codificadas en caso de que el rastreador no detecte Javascript. No lo he delineado explícitamente, pero vale la pena mencionar que debe activar el modo HTML5 para un soporte adecuado de URL.

También tenga en cuenta: estos no son los archivos completos, solo las partes importantes de los que son relevantes. Si necesita ayuda para escribir la plantilla para directivas, servicios, etc. que puede encontrar en otro lugar. De todos modos, aquí va ...

app.js

Aquí es donde proporciona los metadatos personalizados para cada una de sus rutas (título, descripción, etc.)

$routeProvider
   .when('/', {
       templateUrl: 'views/homepage.html',
       controller: 'HomepageCtrl',
       metadata: {
           title: 'The Base Page Title',
           description: 'The Base Page Description' }
   })
   .when('/about', {
       templateUrl: 'views/about.html',
       controller: 'AboutCtrl',
       metadata: {
           title: 'The About Page Title',
           description: 'The About Page Description' }
   })

metadata-service.js (servicio)

Establece las opciones de metadatos personalizados o usa los valores predeterminados como retrocesos.

var self = this;

// Set custom options or use provided fallback (default) options
self.loadMetadata = function(metadata) {
  self.title = document.title = metadata.title || 'Fallback Title';
  self.description = metadata.description || 'Fallback Description';
  self.url = metadata.url || $location.absUrl();
  self.image = metadata.image || 'fallbackimage.jpg';
  self.ogpType = metadata.ogpType || 'website';
  self.twitterCard = metadata.twitterCard || 'summary_large_image';
  self.twitterSite = metadata.twitterSite || '@fallback_handle';
};

// Route change handler, sets the route's defined metadata
$rootScope.$on('$routeChangeSuccess', function (event, newRoute) {
  self.loadMetadata(newRoute.metadata);
});

metaproperty.js (directiva)

Empaqueta los resultados del servicio de metadatos para la vista.

return {
  restrict: 'A',
  scope: {
    metaproperty: '@'
  },
  link: function postLink(scope, element, attrs) {
    scope.default = element.attr('content');
    scope.metadata = metadataService;

    // Watch for metadata changes and set content
    scope.$watch('metadata', function (newVal, oldVal) {
      setContent(newVal);
    }, true);

    // Set the content attribute with new metadataService value or back to the default
    function setContent(metadata) {
      var content = metadata[scope.metaproperty] || scope.default;
      element.attr('content', content);
    }

    setContent(scope.metadata);
  }
};

index.html

Complete con las etiquetas de respaldo codificadas anteriormente mencionadas, para rastreadores que no pueden detectar ningún Javascript.

<head>
  <title>Fallback Title</title>
  <meta name="description" metaproperty="description" content="Fallback Description">

  <!-- Open Graph Protocol Tags -->
  <meta property="og:url" content="fallbackurl.com" metaproperty="url">
  <meta property="og:title" content="Fallback Title" metaproperty="title">
  <meta property="og:description" content="Fallback Description" metaproperty="description">
  <meta property="og:type" content="website" metaproperty="ogpType">
  <meta property="og:image" content="fallbackimage.jpg" metaproperty="image">

  <!-- Twitter Card Tags -->
  <meta name="twitter:card" content="summary_large_image" metaproperty="twitterCard">
  <meta name="twitter:title" content="Fallback Title" metaproperty="title">
  <meta name="twitter:description" content="Fallback Description" metaproperty="description">
  <meta name="twitter:site" content="@fallback_handle" metaproperty="twitterSite">
  <meta name="twitter:image:src" content="fallbackimage.jpg" metaproperty="image">
</head>

Esto debería ayudar dramáticamente con la mayoría de los casos de uso de motores de búsqueda. Si desea una representación totalmente dinámica para los rastreadores de redes sociales (que son dudosos en el soporte de Javascript), aún tendrá que usar uno de los servicios de representación previa mencionados en algunas de las otras respuestas.

¡Espero que esto ayude!

Use algo como PreRender, crea páginas estáticas de su sitio para que los motores de búsqueda puedan indexarlo.

Aquí puede averiguar para qué plataformas está disponible: https://prerender.io/documentation/install-middleware#asp-net

Con Angular Universal, puede generar páginas de destino para la aplicación que se vean como la aplicación completa y luego cargar su aplicación Angular detrás de ella.
Angular Universal genera HTML puro significa páginas sin javascript en el lado del servidor y las sirve a los usuarios sin demora. Por lo tanto, puede lidiar con cualquier rastreador, bot y usuario (que ya tiene baja CPU y velocidad de red). Luego puede redirigirlos mediante enlaces / botones a su aplicación angular real que ya se cargó detrás de ella. Esta solución es recomendada por el sitio oficial. -Más información sobre SEO y Angular Universal-

Los rastreadores (o bots) están diseñados para rastrear el contenido HTML de las páginas web, pero debido a las operaciones de AJAX para la obtención de datos asíncronos, esto se convirtió en un problema, ya que lleva un tiempo representar la página y mostrar contenido dinámico en ella. Del mismo modo, AngularJStambién use el modelo asíncrono, que crea problemas para los rastreadores de Google.

Algunos desarrolladores crean páginas html básicas con datos reales y sirven estas páginas desde el lado del servidor al momento del rastreo. Podemos representar las mismas páginas con PhantomJSel lado de publicación que tiene _escaped_fragment_(porque Google busca #!en las URL de nuestro sitio y luego toma todo después del #!y lo agrega al _escaped_fragment_parámetro de consulta). Para más detalles, lea este blog .

Los rastreadores no necesitan una interfaz gráfica de usuario con un estilo bonito y rico, solo quieren ver el contenido , por lo que no es necesario que les des una instantánea de una página creada para humanos.

Mi solución: darle al rastreador lo que el rastreador quiere :

Debes pensar en lo que quiere el rastreador y darle solo eso.

CONSEJO no te metas con la espalda. Simplemente agregue una pequeña vista frontal del lado del servidor usando la misma API