Welcome to WebmasterWorld Guest from 126.96.36.199
Forum Moderators: open
Our site has a large Spanish section and when I look at our main Entry page and Index page there is no page rank. In all the pages that show oursite/espa˝ol.htm there is no PR (greyed out) and yet all other pages have one. Is Google unable to read the ˝ ???? Please help. We were last spidered Aug. 4 so I assume that we'll be revisited soon.
files indexed as: /filmename.htm show a grey bar while the update is in progress.
but html ending with / are a bit diffent.
sometimes at first is shows gray, but when i remove the / and press enter again, i shows the pr in 8/10 cases.
For domain names and all file names ASCII characters only.
No extended characters whatsoever.
This is a major problem of the whole structure of the internet. It's easily imaginable how aggravating this is for all people using non latin alphabets - in fact the majority of the wolrd population. Take Asia, Eastern and central Europe alone.
But even Spanish, German, the scandinavian languages have a lot of extended characters - no go for the web.
You just have to go for the nearest equivalent in ASCII, in this case that would be plain espanol
As the only pages that do not show PR are the ones with the ˝ I can only assume that this is the problem. I also have some pages with "MyPage.htm" captilization and these do not seem to be a problem however just to be on the safe side I'm going to change them all before the next visit by Google.
ikbenhet1, I hope your not using this trick for duplicate content. Because any site using this trick can be at risk on loosing both listings someday.
Not? Fine! Now is it worth the loss of traffic from Fast? Your decision.
Also, how is linkage? Can you link "Foo.htm" as good as you can link "foo.htm"?
In other words if I went from "mysite/MyPage.htm" to "mysite/mypage.htm" that it should end up on exactly same page????
I converted some sites using capitals in sitename. Since it was generally only one of many much needed steps to improve rankings, I could not measure the importance of this isolated step.
As ikbenhet1, mentionned. Google stores some filenames in URL using capitals. I guess when the bot will pay a visit again thoses pages can 404. But is your site is fully crawlable. It should find the new ones. (this can cause a month or 2 of traffic loss on thoses pages. I am not sure about this.)
I believe changing your filenames will have no ill effects on Google. I am sure it can improve your trafic from Fast. It wont change your directory listings since they probably just indexed the home page. ( Hey thatrings a bell [webmasterworld.com]if you have sufficient content in Spanish... )
It's the best long term option.
I read the thread on foreign languages, especially the part about being able to answer the queries. One of our sites is in 4 languages - English, Dutch, Spanish and German - and Google has given us good placement. Fortunately my wife is Dutch and speakes and writes all 4 laguages fluently which has helped immensely in promoting our tourist business.
I spent all day eliminating the ˝'s and caps in our 100+ page site and can offer this word of warning if there are any others out there with the same problem. If you use an HTML editor to change the pages with caps (we use FP 2000) it will ask if you want to correct all the related links. Because this is not a spelling change it will NOT change the links. You must go through page by page and do them one at a time.
On a smaller site that we have on a "Linux" server when we changed the urls with caps to regular size none of the links would work until we changed all the links. This did not happen on the "Windows" server with the bigger site. In other words if you change "mysite/MyPage.htm" to "mysite/mypage.htm" the Linux server will not follow the link even though it is the same spelling.
Still have one 50+ page site to do tomorrow when I can see straighter.
When I replace renamed from capped to 'normal' files on a Linux server (the only ones I use) I always delete the older pages before I upload the new ones.
Fortunately my "Linux" site is relatively small and making the changes was no problem.
I am sure there is an option in Frontpage to also change your on page links to no caps when you rename the files. We have very knolegeable members willing to help in the WYSIWYG and Text Code Editors forum. If most of the job is not all done yet. I suggest you browse this forum a bit. It must ba a simple "preference" check box somewhere.
I delete old files on the linux server before uploading the new ones.
<edid>replaced the "browser forum" buy "WYSIWYG and Text Code Editors forum"</edit>
[edited by: Macguru at 1:49 pm (utc) on Aug. 26, 2002]
I know a site in Fast which is indexed just fine with Capitals in the filenames...100+ pages.
The same adresses do not exist without caps on the site though.
The site also does fine in Google and AV with these filenames.
If it were my site I would have done it differntly to be on the safe side.
Btw..this site also has many spaces in the file names..as in
"file name.html"...also no problem for either fast, google or av.
I just checked Fast and Lycos and they do perfectly right with caps in URL. I can't find the thread here where the glitch was mentionned. Does this make caps in filenames problem mentionned everywhere on the net some old story?
Can anyone expand on this?
Tropical Island, I hope you saved the old version of your site, because the filename change can cause some temporarly negative impact on your traffic. Please wait until we know more before doing anything.
4.0 versions of netscape like to choke on file names with spaces. I am not sure about new versions but old versions hate them.
So always use lowercase filenames, regardless of your web server.
The universal acceptable characters for filenames are:
a-z (may or may not be treated same as above)
. (if used for filename.filetype separator only)
Most systems can cope with the '-' character as well.
Google apparently doesnt like the following URL:
Will it like this URL?
I look forward to my Spanish Home Page and Index page getting spidered next go-round.