We generate the pages dynamically. When code gets pushed to a repository indexed by Sourcegraph, we re-analyze it, which means that the location of definitions/references changes and the stats about who uses what change, too. This happens fairly often, so it's easier just to generate pages dynamically.

If you want to get an idea of our site architecture, you can check out https://sourcegraph.com/github.com/sourcegraph/thesrc. (It's a link aggregation site (thesrc.org) that pulls from HN, Reddit, and a few other places and only displays links with programming-related content.) We made it to share some patterns we found useful for building a web app in Go, and the interfaces and structure mirror how Sourcegraph.com is designed. There's also a talk here if you're interested: http://www.youtube.com/watch?v=7zYXhhrRn2E.

That hits close to home. I recently built a single page app with Backbone and SEO traffic is non-existent.

So now I'm dynamically generating pages on the backend, and serving them along with the javascript app so there's some some indexable static content. There are a few ways to directly reuse your client-side code on the server, but they all seem pretty hacky and convoluted.

I bought into the notion that the backend should just be a client-agnostic API, but that's an extreme position that should be considered when your site/app doesn't have any indexable content to begin with. If I could only go back in time...