If anyone needed "proof" about what google does, or does not do when scoring pages, read on.

Looking over the google instructions for improving the targeting of your page:

https://www.google.com/adsense/faq-tech

This sticks out, as to why you should use the rewrite rules posted to create SE friendly pages to serve jump.cgi pages.



They seem to specifically target "ID" strings, and assume they are not valid for later use.

They also seem to have problems with frames and iframes, as trying to decide "included" content on a page opens up potential risk from their point of view.

This seems to be the most insight into any search engine that has been "officially" posted.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

 


When you say "SE friendly pages to serve jump.cgi pages." pugdog are you referring to page.cgi using mod_rewrite?


The way i read that quote from Google is their talking about session ID's in a URL that change each time a user closes their browser and revisits a page; or put another way session ID's as an alternative to tracking visitors through a site using cookies.

Yes,
but I've been following things on a bunch of forums lately, and when you use an ID= string, it's sort of a "tag" for passing a non-cookie session ID. Google depricates those URLs in their index... so while they may be in there, their rank is very, very low.

By using the rewrite rules to serve static looking pages, or to use the SE friendly templates in GForum, does wonders.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

  

Mod_rewrite defiantly makes a huge difference to database driven sites on the engines (especially Google).

As far as LinksSQL is concerned the problem lies with using Perl for dynamic pages, Google will index these pages (even with a variable in the URL) example: http://66.102.9.104/search?q=cache:http%3A%2F%2Fwww.bestflashanimationsite.com%2Fcgi-bin%2Freview.cgi%3FID%3D599

but on the whole they avoid it (due to the load it can place on a server) more so than middleware pages like PHP, ASP, CFM etc. that use query strings.

There's a good article here about 3 methods for seting up search engine friendly URLs:

sitepoint.com/article/485

---

Comedy Quotes - Glinks 3.3.0, PageBuilder, StaticURLtr, CAPTCHA, User_Edit_Profile

Not (entirely) convinced.

I reckon the session IDs they're referring to are the specific PHP session IDs that are part of the language (for cookie-free tracking), change for every (duh) session and expire. Consequently, they can't be replicated so that URL (effectively) never exists again ... so can't be indexed. Google are using ID as an abbreviation. not as a string to say any URL with "ID=" in it is going to be treated as a session ID.

This is substantially different from URLs which contain parameters the way they exist in dynamic Links pages (and many other apps).

You don't have to look far down any realistic search to see that "dynamic" URLS get well ranked. Yes, all other things being equal it's prob better to have a fully static URL, but that only holds true if you can conceive a mod rewrite project from the ground up to cater for all eventualities. Any leakage from a less-than-perfect mod rewrite implementation (resulting freaky destinations, 404s, etc) has to be offset against the SE benefits.

Maybe I'm just bitter because I've yet to find a whole-site mod rewrite solution =%)