Hi. Today, i've got a chicken-and-egg puzzle for your enjoyment :) In order to properly support google indexing of published content hosted by my CMS', which scales to browser-size, no matter what it is initially or how the user resizes it. Adding meta info for the many pictures hosted via my CMS would greatly increase natural search results. In order to get them indexed, i need to provide google with URLs that contain the complete page's content. Pictures and their descriptions included. How many thumbnails get displayed is therefore dependent on (initial) browser-size. So I need to know the browser size in the _initial_ php call to my site. To my knowledge, that's impossible. And besides, google (my target audience for all of this) doesnt execute JS, so i'll have to choose a browsersize for the user when he comes in no matter what. I've come up with this workaround that i'd like your comments and potential improvements on. In the html of some page that is crawled, i have a link that's sorta like this: http://mediabeez.ws/mediaBeez/ clink.php?cmd=desktop&module=ajax&action=viewCollection&target=misc This should call up a page with a photo-album. Currently, to get smoother loading graphic-performance, i split up the rendering of the desktop that holds the photo-album, and the actual photo-album content. First the desktop (and worker-JS-libs) would be properly loaded and displayed, then a loading icon displayed in the photo album, and then the contents of the photo-album loaded. This mechanism is currently used on the link above. The best solution i can come up with till now is to pre-load <IMG>s and descriptions for a desktop 1024x768 in size, then on running of the photoalbum js either remove some images or (if i have too few) call my render_album_contents() again via AJAX with the proper desktop size. With google analytics i could see what browsersize gets used most, and set the default to that, to reduce double-calls to the kinda-expensive render_album_contents() which calls up much meta-info related to the pictures. The main problem i see with this approach is for pagination. The initial link for the 'next page' button should be a static one per "default browsersize" (for google's indexing) but on running it this should change back to a JS call that takes that particular users' browser size in account. I guess that could be achieved with the photo-album js changing the link at pageLoad(), but it could be tricky. What i'd like to know from you is if you can see any other way to achieve google-indexing of all pages of a photo-album that resizes to browser size..
