Yeah, I think that section of the article could be improved.
If I were facing their problem (where they had already chosen to use URL fragments for navigation but also didn't want to miss out on crawlability) I would use a different approach than maintaining a separate set of static pages.
Instead of static pages, I would create a single servlet/cgi that would handle the URLs to these pages. The content for each URL could be created on-the-fly on the server side using some server-side browser (like HtmlUnit, Cobra or Crowbar...) to receive the requests, translate the URL into the fragment-format, run your actual javascript application (which is already written to handle such fragments) and capture the resulting DOM to send back to the actual browser that arrived via the Google search. Of course the HTML could be persisted so that this process would only need to happen once per URL. The benefit of doing it this way would be that when you deployed changes you could simply invalidate the HTML cache and let your system build them again automatically.
But it would probably be better to avoid the problem entirely by thinking about SEO needs up front.
Comments
That's good to know. From the article, it sounded like hashbang URLs were the default/preferred method of handling navigation.
Yeah, I think that section of the article could be improved.
If I were facing their problem (where they had already chosen to use URL fragments for navigation but also didn't want to miss out on crawlability) I would use a different approach than maintaining a separate set of static pages.
Instead of static pages, I would create a single servlet/cgi that would handle the URLs to these pages. The content for each URL could be created on-the-fly on the server side using some server-side browser (like HtmlUnit, Cobra or Crowbar...) to receive the requests, translate the URL into the fragment-format, run your actual javascript application (which is already written to handle such fragments) and capture the resulting DOM to send back to the actual browser that arrived via the Google search. Of course the HTML could be persisted so that this process would only need to happen once per URL. The benefit of doing it this way would be that when you deployed changes you could simply invalidate the HTML cache and let your system build them again automatically.
But it would probably be better to avoid the problem entirely by thinking about SEO needs up front.