google indexing forward URL --> no keyword analysis

[gudemswebmaster]

Hello!

I'm having an issue with Google's indexing of my site -- the page it recognizes as being the first page of my site is forwarding to the index page of my site, and then my site is redirecting to the actual first page of the site*. The two levels of indirection mean that StatCounter isn't able to log the keywords of people who find the site via Google searches, and of course I want to fix this. Any ideas how to?

I tried submitting the actual URL ( http://democrats.georgetown.edu ), and that was up and indexed for about a day -- until Google realized that it already had a copy of this site on file with the following not-so-great forwarding URL:
http://eis.georgetown.edu/web/uis/ke....edu%2Fdems%2F

How can I tell Google that this URL isn't the one that it should have on file for my site and correct it?


* Because the site has at least 4 different symbolic links, I am redirecting all pages to just one of them so that all the hits for .internship.html, for example, count as hits for just .internship.html and not somedomain+internship.html and anotherdomain+internship.html, etc.

[webado]

Your "actual" url forwarding elsewhere doesn't help. Why exactly isn't the site at the "actual" url itself? Why do you forward to a lower level folder?

How exactly is the forwarding done anyway?

[gudemswebmaster]

>> Why exactly isn't the site at the "actual" url itself? Why do you forward to a lower level folder?

It's a solution to organizational issues.

The two real reasons:
-- keeps all the files at the same directory level so relative links in SSI files work (I have to have dems/members/ because there will be a password on the members directory soon, and I want the pages in this subdirectory to call the same dems/menu.html SSI file [the menu items with large stars] as the pages that the general public can access. I can't solve this by using non-relative links in the menu.html file because all the links in that SSI file need to be relative links, so that someone accessing from domain A gets the same site as someone accessing from domain B [a result of the symbolic links, e.g. http://studentorgs.georgetown.edu/dems/ and http://www.georgetown.edu/organizations/dems/ ]. Instead, I've solved it by moving the general files to their own subdirectory. It's a lot of restrictions, and making a lower level folder containing the actual index page seemed to be the best solution.)
-- gives an index page that everyone will see -- an index.shtml (which the lower-level welcome page is) will not come up automatically, so the redirecting index page forwards users with javascript to an .shtml file and gives those without a chance to forward themselves to it

(And as benefits that would never justify this redirection on their own, the redirection:
-- forwards everyone with javascript to the democrats.georgetown.edu site so the web statistics can count all the hits for (eg) "internship.html" together, no matter which URL the user first typed in
-- weeds out the people without javascript and offers them the chance to turn it on.)


----edit----
>>How exactly is the forwarding done anyway?
Oh, and mine is a javascript redirection:

<script language="JavaScript" type="text/javascript">
window.location.replace("http://democrats.georgetown.edu/general/index.shtml");
</script>

After that comes a bit of text inviting non-Javascript users to enter the site through a clickable link to /general/index.shtml. (If you want to see the page, disable your JavaScript.)

Theirs is done in Cold Fusion, I think, but I don't have any access to change it.


----edit again----
Oh, and I have StatCounter installed on the http://democrats.georgetown.edu/index.html page, before it forwards to http://democrats.georgetown.edu/general/index.shtml, so that's not the issue.

[webado]

Javascript poses a problem with search engine spiders. They don't follow that. They will instead follow the clickable link, but then the page from which this happens is going to have no content or almost none - and that's what gets indexed as root.

You will have to reorganize it better.

Your root here is http://democrats.georgetown.edu/ so from anywhere lower down by refering to a file as ../file.ext means it will be looking for it in the root folder as http://democrats.georgetown.edu/file.ext . If you link to ../foldera/folderb/file.ext it will go look for http://democrats.georgetown.edu/fold...lderb/file.ext and so on.

Also the javascript redirects do not work with Statcounter so you may really want to revise this mechanism. When I say they don't work I'm referring to the fact that you will lose the referrer on the page that you redirect to and quite possibly your page from you you redirect may not even get logged depending where the js redirect is placed in the code. If it's in the head of the page it won't have executed the Statcounter code before the redirection takes place - I think.

A meta refresh works much better navigation-wise and Statcounter wise though search engines don't like it. Or you can use php or .htaccess to redirect.


----
Hmmm... Cold Fusion means you may be on a Windows Server so the .htaccess is out, as possibly is php.

[gudemswebmaster]

Hmm -- thanks! I'm going to look into .htaccess; I'm pretty sure I have access to it, at least through my server administrator. Two questions left ...

Is there a another option besides meta-refresh that StatCounter will recognize and log?

Is there some way to get Google to replace the long and convoluted URL of the Cold Fusion page that automatically forwards with the actual site URL? I'd like to delete the first 2/3 of what it has in its memory as my site's root URL, since although it works in getting people to the page, it's not really accurate.

Thanks so much again!!

[webado]

The actual url displayed in the addresss bar is what Statcounter logs. It must be accurate. If you want to use shorted url's then the links in the application must use shorter url's.

Therefore you must look into how the links are used. Since your site is a subdomain, and the subdomain is a folder on the site, the links ought to be relative to the subdomain's root, rather than relative to the entire site. Maybe this is the problem you are facing. For this you have to go into the way all the links are being set up in the scripts that Coldfusion makes. I can't help you there, as I have no idea how that is.

On a windows server there's no .htaccess file to control those things, or rather if you have one it's ineffective. There must be other means I'm not familiar with.

It's not up to Statcounter to "recognize" the redirection. It's a question that a javascript redirection does not provide a referrer url, the way a link would. A meta-refresh , while frowned upon by search engine spiders, at least allows for logging at the entry point. As would a php redirection. But often php is not available on windows servers either. So maybe Coldfusion or asp has somethign equivalent to the php header function.

It would be best not to have any of those redirections at all, and simply structure your site adequately to avoid them.

[gudemswebmaster]

Oh, I see what's happening -- it's getting sent forward so soon that StatCounter doesn't have a chance to log.... I was making an issue where there was none and where I knew how to fix the problem.... *argh* I really appreciate you nonetheless!!!

By the way, you said
>> It's a question that a javascript redirection does not provide a referrer url, the way a link would.

But StatCounter is getting the referring page out of the javascript redirection I have just fine, now that I'm giving it enough time to log it -- my javascript redirection code is:

window.location.replace("pathName");

I thought you might want to know this for future troubleshooting, or for a FAQ, or whatever (not that I imagine it would come up much).

Thanks again!

[webado]

It depends where you placed the script I guess.

You cannot have it after anything else is output to the screen as it would cause an error (you may not see the error if you don't have the option of being notified of javascript errors).

If you place it in the head section it will not get to the statcounter code, as it would redirect before that. If you place it after the statcounter code, that code better be for the totally invisible counter, otherwise the fact an image file has to be output before the redirect will generate that javascript error. Although it may still actually log.