On Wed, Mar 4, 2009 at 7:09 PM, Alan Burlison <[email protected]> wrote: > > Actually, generating the content dynamically *is* the problem. We get > heavily spidered by search engines, virtually all the site content is > dynamic, much of the ARC content is only ever visited by spiders and that's > one suspect for what is killing the site - hence tomorrow's test. > > If you needed to access content via a HTML form, it can make it hard for > spiders to find it - and we *like* being spidered, it's just at present we > are being loved to death.
Ah, thanks, I hadn't considered this angle. I wonder if that was the motivation behind the hide div on the overly abundant left hand nav pane? Ok, so from the perspective of the website as a whole, all of the open ARC case contents should be spiderable. I suppose that's probably going to be true for any other project related materials if anything is built that handles more than just the ARC case portions. And for performance reasons, generation of this portion of content must have low overhead given the sheer volume. So if it stays dynamic, then it must be performant, scalable, and low impact for the rest of the site. I think there's going to be tension about building out the large lists of case dirs into any one portion or component of the site. As we can already see, building something like that nav pane for every page has gotten too unwieldy. Why can we not break that up hierarchically as long as we maintain the links? I suspect that might make it easier for background exporting tools to process if they are able to do it in smaller chunks. Or maybe I don't understand the complexity around the background tools. Another note: do the current URL's need to be maintained? Is there any sort of guarantee as to how long a given OSo or arc case URL must be valid? Would we need to provide redirects for the entire caselog if they are changed? _______________________________________________ website-discuss mailing list [email protected]
