|How does Google read text inside FP shared borders?|
maybe an easy question
| 12:11 am on Feb 21, 2006 (gmt 0)|
I have just finished my 90 odd page site promoting my business and i did not use shared borders, i have now come to realise that when i want to add a new button its 90 new buttons...........i only did not use the borders because someone told me that Google does not read the text in the same way it would read text not in a border? i.e it knocks a bit off the ranking of the keywords, is there any truth in this?
| 1:03 am on Feb 21, 2006 (gmt 0)|
As someone who has used FrontPage for years, I don't think shared borders will cause you a problem. When using shared borders (or FrontPage includes), the various components of the page are assembled "server side" so the googlebot will be presented with and read this content. Shared borders are just a fancy FP version of SSI (server side includes).
Out of all the things that can make Google spit the dummy, I think that the use of shared borders are the thing to least worry about - it's what goes into them that counts ;).
[edited by: icarus at 1:06 am (utc) on Feb. 21, 2006]
| 1:04 am on Feb 21, 2006 (gmt 0)|
I'm not sure what you mean by borders (frames?), but if you have php capabilities on your server then using a simple php include would solve your problem.
If you are indeed referring to frames, then I would recommend you stay away from them, as they are not the best thing for the search engines. If your site is in frames then you'll only be able to use one title tag for the entire website which is basically shooting yourself in the foot.
Sorry about the short answer, but if I were to cover the topic properly it would take a few pages. :)
Hope this helps.
If they are indeed like server side includes then it shouldn't create a problem. I'm not familiar with FP, and try to stay away from it as much as possible.
| 1:32 am on Feb 21, 2006 (gmt 0)|
Thanks, i didn't really see why it would reject them either, unless you filled them with irrelevant or repeated words.
i just thought that maybe it could not crawl them as efficiently because they are in a sense locked in and i take your point about being tied into not being able to have subtle (or not) changes in your titles.
Thanks again, Phil
| 3:58 pm on Feb 21, 2006 (gmt 0)|
Actually I don't think Front Page borders should be thought of as "SSI" Server Side Includes.
The page's content and it's "borders" are compiled into a static page by your web server and the Front Page server extensions everytime you publish your website. I believe you can confirm this by looking at your pages content on your server with an editor. You will see the actual "border" html code. If it were SSI you would see some kind of "include" statement.
This Front Page mechcanism has one interesting effect to which I still do not know the impact with respect to Google.
Every page which uses the common borders has it's date revised on your server everytime you publish even if the core content of the page has not changed at all. I actually don't think Google is thrilled with this constant indication of change where none (or very little) has actually occured. Google talks about servers supporting the 304 return code indicating a page hasn't changed since a last visit, and with Front Page it looks like all pages are changing frequently, assuming you are publishing new pages and revising individual pages to your site regularly.
I find that certain "low level" "low page rank" pages on my site(s) go URL only and I always wonder if its due to the file date changing but little if any content changes have occured on these pages.
Today I logged into my server (using ftp) and checked the dates on my web pages files, they are all 2/18/2006, the last time I published. I can guarantee I didn't change all these pages!
I'm not sure if the dates all change if you do not change the borders at all, but this is rare in my case.
I certainly can live with the quirks of an HTML compiler like Front Page versus hand coding HTML. The server side extensions are a little weird but they can cut publishing times drastically.
Any observations about the constant file date updating and it's impact on Google would be appreciated.
| 4:03 pm on Feb 21, 2006 (gmt 0)|
Shared borders are a BIT like includes, but the static pages are assembled by FrontPage BEFORE being uploaded to the website.
With proper includes (PHP, or SSI, that is), the parts all reside on the server, as parts, and the server assembles them every time the page is called for.
With proper includes you can alter one small file on your own machine, and then FTP it up to the server, and the changes take effect immediately.
With FP shared borders you have to make the change to the file on your own machine, and then recompile every page of the site, and upload the entire website again.
| 4:31 pm on Feb 21, 2006 (gmt 0)|
|With FP shared borders you have to make the change to the file on your own machine, and then recompile every page of the site, and upload the entire website again. |
I guess that's if you're FTPing it. If your server has FP extensions installed the publishing routine only uploads the changed include file or shared border. The extensions then update each affected page on the server.
Or, you can work hot on the live site and affected pages are updated when the include or shared border is saved.
That's one of the neat things about FP, it offers a variety of ways to do the same job and can fit many different work habits.
| 4:45 pm on Feb 21, 2006 (gmt 0)|
I have to disagree, the pages are assembled by executables (the Front Page server extensions) on the server. Front page uploads the borders only, if only the borders change. Front page only uploads changed pages, not all pages. The borders are in files called left.htm, right.htm, bottom.htm, top.htm in the _borders subdir. These border files are uploaded when changed and then combined with the core of the page itself on the server. Front page does fetch file date information for all files on the server to use to detect change between your local copy and the copy on the server, but it does not upload all pages.
I used to manage sites using my 56K modem, if all the pages were uploaded everytime I changed a border I would not be in this business. That's the difference between "publishing" and using ftp in Front Page, it's a huge difference. Sure SSI achieves the same thing, but it's not very portable, and I've already ported sites from windows servers to unix servers fairly quickly using Front Page ( I didn't have to change content to do it ). The onus is on the webhost to make the Front Page server extensions work to achieve this powerful capability.
(jim beat me to it.)
I'd still like to hear any comments about the dates all changing and Google indexing. I think there may be a subtle impact.
| 5:40 pm on Feb 21, 2006 (gmt 0)|
Shared borders aren't a problem, whether you're publishing with FrontPage to a server with the FP extensions or uploading via ftp to a server without the FP extensions.
Need proof? Publish or upload a page with shared borders to your server, then view the page's source code with your browser. You'll see what googlebot does: an HTML file that includes everything from the shared borders.
| 5:50 pm on Feb 21, 2006 (gmt 0)|
You don't even have to publish or upload the file to a server. Just open it on your local machine outside of Frontpage in the browser of your choice. Then as EfV says, view source and all the html is there.
| 10:05 pm on Feb 21, 2006 (gmt 0)|
But what about all the dates on the files being revised everytime you change the borders? I think there is a small negative impact.
This date change means Google sees far fewer 304 codes (page has not changed) returned. Google states that they prefer servers that support this capability, and I have seen my server return a 304 to Google, BUT, it must be much less frequently than for those who do not use Front Page (borders). I have used FP for years as well but still have concerns that there is some small impact on SERP position, and that was the original question; does FP impact SERPS?
It probably does slightly; it does not produce standards compliant code, it changes dates on files needlessly, it loves to use nbsp; (NON-breaking spaces). If your not careful it imbeds NBSP's in <TITLES> which I think does cause problems! (Review your HTML source for these quirks) All these issues may be small black marks in the hundreds of criteria Google must use to rank a page.
So FP has quirks that could subtlely reduce your SERP ranking, maybe only a few positions, BUT it is also a valuable tool that prevents many, many, coding errors, and reduces "time to market", reduces learning curve, etc. Also I've got quite a few Number 1 rank pages (for competive terms) so it can't be all that bad. I wish Microsoft would release a new version, I still use FP 2000!
| 11:21 pm on Feb 21, 2006 (gmt 0)|
|I wish Microsoft would release a new version, I still use FP 2000! |
Well, there's always FP 2003, which is three years newer than your version. :-)
Also, pages created in FrontPage with FP Shared Borders can do just fine in Google's SERPs if my own experience is any guide.