27 replies to this topic

[adavidson]

Hi,

This is my second posting... the first was very helpful. Here's the situation.

We are moving from a static HTML site to a database driven (ASP) site. We have very high rankings (1st page on google) for our best keyphrases and we cannot afford to lose them. Initially I was going to maintain 5 of the old static pages to keep the filenames and pages and hopefully retain the rankings for them.

The programmer who is redoing the site said that we don't have to do that, but we can use 'server side includes' which will take care of the problem of maintaining the rankings of any pages we want to keep.

Can someone explain how this works and if it is an acceptable solution.

Thank you so much for any help.

[qwerty]

All SSI does is take one page and load it into another. It's very convenient for information that appears on multiple pages, since a change to a single file will change all the files that include it.

But I don't see how that will help you maintain your rankings. Is the programmer talking about inserting SSIs into the high-ranking pages, or using them as included content? If I had to guess, I'd say it's the former, since turning a page into an include only draws information from the body -- anything in the head of the file, like the title tag, is gone.

[Jill]

The programmer who is redoing the site said that we don't have to do that, but we can use 'server side includes' which will take care of the problem of maintaining the rankings of any pages we want to keep.

This doesn't make any sense to me. Could you ask the programmer to clarify just how SSI will do this?

I think then we will be able to let you know if it's correct. It sounds right now as if the programmer is just giving you some mumbo-jumbo, but perhaps you were just misunderstanding him or her?

Jill

[mcanerin]

I think I know what your programmer is talking about, and if I do it's a good idea.

One problem with switching from static HTML to dynamic content is that all the URLs, specifically the page names, change. This would of course mess up any rankings or links to that page, since it would disappear.

It would be possible to set up redirects for each and every page, but it's not very practical. Further, dynamic systems are infamous for wierd URLs containing strange characters that many SE's don't like.

However, you can create a page that appears to be static, and even have the same name, simply by doing an SSI (server side include). Think of it as running all your scripts (like menus) on the page before it goes to the browser. This also makes it friendly for browsers that have scripts disabled and prevents people from stealing your code (since they only see the output).

Basically the only real difference between a dynamic page and a SSI is that you usually put an SSI inside a static HTML page. This is a great idea.

Why? Well because now you can keep static, keyword rich content on the page and just change the sections that you need to. You also get to keep your metatags and other stuff.

Think of it as a box or spot on your page that you can edit and update whenever you want. Then you tell the server to do the editing and updating for you.

You don't even need to change it everytime. You can easily just generate 2 static pages and put one inside the other.

It's kind of like the older cousin of CSS, except for content. If you have ever used an HTML editor that automatically put borders and menu systems on your pages, you've used an SSI. FrontPage menus, borders and so forth come to mind.

Another type of include would be an RSS feed - which I believe our dear Scottie is working on for this forum right now.

It's a good thing

Ian

Edited by mcanerin, 15 October 2003 - 09:54 AM.

[mcanerin]

SSI's are pretty easy to use, too.

This is the code:

<!--#exec cgi="/scripts/uf.pl"--><P>

Thats it. In this case it calls a perl script on my site and loads in the User Friendly cartoon into my home page for me to read in the morning 'cause I'm too lazy to actually click on the link.


Ian

[mcanerin]

Hmmm,

There is one catch. Your server needs to know whether it should look into the pages and pre-process them before it spits them out. Usually you can do that by changing the extension from html to shtml or asp or something.

But if you did it that way you'd lose the page name anyway. There are ways around this, but make sure you do it or it's not going to be as helpful.

Ian

[adavidson]

Hi all,

Thanks for the feedback. I've emailed the programmer for clarification and will post it once he replies to me.

Ian, he mentioned something about having a dot on the page. Maybe you are onto something and this is what he meant. I don't want to speculate so I'll wait for his repsonse and let you know. Thanks.

[qwerty]

...changing the extension from html to shtml or asp or something.

Front Page include files don't require that (I know, nobody who knows what they're doing uses FP), but it does require that you have Front Page server extensions running.

[adavidson]

Hi,

This was the programmers response:

A web server must compile a page before it is sent to a browser (or spider, or anything that is requesting the page). In straight HTML, the page is virtually untouched by the web server application; it merely passes the text to the requester. However, for example, ASP pages are quickly compiled by executing the lines of code prior to being sent to a web browser. If you've ever looked at the source of an ASP page in your browser, you'll see that there is no database coding or scripting (except for client-side Javascripts which are executed locally in your browser)... all you see is regular HTML. That is because the web server compiles the page and THEN sends it to the requester. A server side include instructs the web server to include the contents of another page (which could be a static or dynamic page... it doesnt matter) BEFORE it sends the requester the HTML. The net effect of using an SSI is that the content of the included page seems as if it IS the page requested. There is nothing that a spider or web browser could detect indicating the presence of an SSI and truly there IS NO difference. Again, what this will do for us is to enable you to keep the long-established links to specific HTML pages alive by SSI'ing the content of ASP pages.

-------

Is this acceptable to search engines, particularly Google?

Thanks again!

[Jill]

Still doesn't make sense to me, but perhaps Ian or one of the others gets it!

Ian, is that the same thing as you were suggesting?

I understand the part about SSI and what it is, and how it is compiled, but I'm just not wrapping my head around how it can be used with a dynamic site to preserve links.

It sounds like the programmer is simply going to put a list of links (via SSI) to your old pages? Is this correct? If so, it doesn't sound like a good idea to me. But I'm pretty confused right now, so I'm probably just not getting it!

Jill

[mcanerin]

As near as I can tell, the answer is yes.

For one thing, SSI is always acceptable to Google unless you are using it for cloaking purposes.

I believe your programmer is going to keep the names of your static pages the same (and hence not break the incoming links to them) then update the actual content (basically the stuff between the <body> tags)with SSI.

This is a perfectly acceptable way to do things. Yahoo used to do it before they went to dynamically generated static pages for performance reasons.

You probably know this, but keep in mind that although you will be keeping the backlinks to these pages, anytime you change the content of a page - whether through manual edits or SSI - you are potentially changing the keyword density, copy and all the other things that make up a great web page.

This can be a good or bad thing. Keep in mind that the content you are putting out in the SSI is exactly that - content. And your pages relevance will be judged on it.

But keeping all your old links is a great start. At least it will make it easy for the spiders to find you.

Ian

[Craig B]

I believe your programmer is going to keep the names of your static pages the same (and hence not break the incoming links to them) then update the actual content (basically the stuff between the <body> tags)with SSI.

I am not sure how he is going to do this. I understand that creating dynamic pages using programming languages such as JSP, ASP, or PHP will still result in the user seeing straight HTML in the page source. The issue is that the server still needs to know how to process these dynamic pages before it gets to the user. This is normally done using extensions (.jsp, .asp, and .php). When the server sees these extensions, it sends the file to an application server (or a module in the web server) to be processed and then sent back to the web server.

If the file extensions stay the same, how is the programmer going to let the web server know to send these instructions to be parsed?

The only way I can think of is to map HTML as ASP, or whatever in the Apache configuration.

The same thing applies so Server Side Includes (SSI). If you don't add .shtml, how does the web server know when to include it?

Another point to make is that SSI is usually used to eliminate maintenance costs, not to increase search engine visibility. For example, if I have a navigation scheme that I use over 100 pages, I could take out the code for the nav and then use a SSI tag instead which would call that nav from one file in another location. This makes it much easier for maintenance as if I need to change a link to a new location, I only have to make the change in one file, not 100. BUT, this does not make for better search engine rankings as I can not customize this code page by page as it will always be the same.

cheers,
Craig.

Edited by crazed_canuck, 15 October 2003 - 11:49 AM.

[Ron Carnell]

The question that seems to remain unanswered is "Why?"

There are probably a few dozen ways to duplicate static HTML pages with various server technologies. But if the content is going to stay the same, and the filename is going to stay the same, why bother? Move the HTML pages and be done with it.

[polarmate]

If you have ever used an HTML editor that automatically put borders and menu systems on your pages, you've used an SSI. FrontPage menus, borders and so forth come to mind.

FP borders are not SSI. If you look at the html code of your page (not using View Source in the browser but the code using Notepad), you will see that the borders are already written to the file. This code can usually be found between comments marked by <!--msnavigation-->. There is no server side include that occurs a web page with FP shared borders is served. It is an FP feature ie a feature of the editing tool, whereby FP displays just the HTML of the page sans the borders to make it easier to edit.

[schecky]

Borders are included by the FP extensions. Turn off the extensions and borders do not work. If you look in FP you can edit just the border, there is a hidden folder where boders are stored so it is in fact one file inside of another which is functioning much like an SSI does. The only difference is FP is using proprietary tags to do it:
<meta name="Microsoft Border" content="tlb, default">
remove that tag and the border is gone so it is functioning like an SSI which is processed by the FP extensions. It's not using conventional coding but is an SSI in functionality.