Use of SSI and SEO

SSI usage in website and how good it is?

[coders]

I'am trying to include the use of SSI in my website. From what I have heard and read, the SSI can make the changes faster, also the loading time is decreased.
I only have html pages as of now and I'am not thinking of making all of them change from .html to .shtml as its a lengthy process. I will be writing this line into the .htaccess file:

AddHandler server-parsed .html

Is this ok or should I use XBitHack, actually I don't know about it much?
If somebody can guide me in the usage of XBitHack, that is also fine.

Can someone tell me how much extra pressure parsing SSI puts on your server? I also want the pages to be cached and result in faster increased performance.

Also, should I block the individual files which are included in the robots.txt file? I'am planning to have 4-5 files to be included in all the pages. Currently there are 100 pages and they will go upto 5000 pages in future.

Will this have an SEO effect in some way or any disadvantage?
Currently I have only one file as a template file and what I update in this file, all pages reflect the change. Is it more convenient as of now or will the implementation of SSI will make my life more comfortable.

[jdMorgan]

Wow -- That's a big pile of questions there, coder! :)

I am trying to include the use of SSI in my website. From what I have heard and read, the SSI can make the changes faster, also the loading time is decreased.

SSI makes maintenance easier, since only one file needs to be changed and uploaded to update all pages on the site. It does not decrease the loading time though, since all pages are "built" on the server, and the client does not "see" anything that indicates that server-side includes were used to create the HTML. It will very slightly slow down server response time though, since each HTML page will have to be 'custom-built' on the server to incorporate the SSI-included elements.

I only have html pages as of now and I'am not thinking of making all of them change from .html to .shtml as its a lengthy process. I will be writing this line into the .htaccess file:

AddHandler server-parsed .html

Is this ok or should I use XBitHack, actually I don't know about it much?
If somebody can guide me in the usage of XBitHack, that is also fine.

It would be silly to change the URLs if they've already been published. You'd have to also put redirects in place to avoid permanent loss of previously-gained incoming links and their PageRank/link-popularity.

XBitHack is better when only a few files need to be parsed for SSI. AddHandler is better if all or most files of the specified filetype need to be parsed. In your specific case, you should use XBitHack only if the transition to SSI will be done page-by-page and very slowly (over months). Otherwise, you'd might as well set the handler and get on with it.

Can someone tell me how much extra pressure parsing SSI puts on your server? I also want the pages to be cached and result in faster increased performance.

No. We can tell you that it *will* require more CPU to process requests, but we can't quantify that extra load. But be aware that sites like this one (WebmasterWorld) are almost entirely dynamically-generated, and many, many sites use CGI SSI or PHP to produce their pages...

Also, should I block the individual files which are included in the robots.txt file? I'am planning to have 4-5 files to be included in all the pages. Currently there are 100 pages and they will go up to 5000 pages in future.

The "things" listed in a robots.txt file are URL-paths, not files. Robots.txt is processed by robots, which are Web clients. As noted above, clients won't "see" or "know" that your SSI-included files even exist. All the client sees is completely-formed HTML pages.

Will this have an SEO effect in some way or any disadvantage?

No more so than the same amount of repetitive hard-coded HTML on each page would have.

Currently I have only one file as a template file and what I update in this file, all pages reflect the change. Is it more convenient as of now or will the implementation of SSI will make my life more comfortable.

I assume that you mean that you are using a template on your 'development' PC that re-creates all HTML pages when you make a change to the template. You then have to upload all of the pages which use that template to the server. By using SSI, the change will be made to the SSI-included file on your development PC, you will upload that one file to the server, and the changes will then be applied to each HTML page by the server, each time that page is requested.

"SSI" is a rather loose term, so I can't be sure if you intend to use CGI SSI or something else. If your SSI code might be even the least bit complex in the future, consider using PHP instead of CGI SSI or PERL; PHP was invented to make HTML page generation easy, and it is one of the best tools for the job today. I think you will find CGI SSI to be very limiting, and more prone to creating hard-to-find errors.

Jim

[g1smd]

I looked at both SSI and PHP at least several years ago, and even back then the decision to use PHP seemed to be very clear, and is still being reinforced every day.

[jdMorgan]

Yes, PHP is what? -- at least 20 years newer that CGI. There have been lots of scripting-language usability and capability improvements in that time. CGI SSI is fine if you're going to do a very few very simple things to a very few pages on your site. After that, PHP is the obvious choice for client-facing scripts.

Jim

[coders]

Thanks a lot jdMorgan for your kind and effective response.
I still have some doubts. Please have a look below and I request for your urgent attention:

"XBitHack is better when only a few files need to be parsed for SSI. AddHandler is better if all or most files of the
specified filetype need to be parsed. In your specific case, you should use XBitHack only if the transition to SSI will be done page-by-page and very slowly (over months). Otherwise, you'd might as well set the handler and get on with it."

From this, I have made the decision of using SSI on my website as I want all pages to use included files.

"AddHandler is better if all or most files of the specified filetype need to be parsed."

I would prefer dong this way: using AddHandler as I want the 4 inculded files to come in all pages.

The "things" listed in a robots.txt file are URL-paths, not files. Robots.txt is processed by robots, which are Web clients.

"As noted above, clients won't "see" or "know" that your SSI-included files even exist. All the client sees is completely-formed HTML pages."

If I don't want Google to index the included files individually and show them in search results, I think I should block their urls in robots.txt !

I want to apply caching for my website:
See this link [developer.yahoo.net...]

Also, see this link:
[httpd.apache.org...]

and read from A brief comment...... upto the 2nd point.
"Apache says to use Xbithack instead of parsing all .html files"

and it also says

"Apache does not send the last modified date or content length HTTP headers on SSI pages, because these values are difficult to calculate for dynamic content. This can prevent your document from being cached, and result in slower perceived client performance" and mentioning the 2 ways to solve this.

If you can guide me about the Xbit hack in detail and if you think this will be good for me considering my requests for good client performance and caching, what would you recommend me to do finally?

All answers are well appreciated.
Sincere thanks

[jdMorgan]

> If I don't want Google to index the included files individually and show them in search results, I think I should block their urls in robots.txt !

Again, as I wrote above: "clients won't "see" or "know" that your SSI-included files even exist. All the client sees is completely-formed HTML pages." Try it. implement your SSI on a test page, then load that page in a browser and do a View->Page source. You will find no SSI code or "included file" names. All you will see is HTML code. Putting the SSI-included files into robots.txt is both unnecessary and risky from a security standpoint -- *anybody* can read robots.txt.

The quote says "Apache does not send ... headers." However, your script can send those headers itself, if you can figure out a proper way to correctly calculate Last-Modified and Content-Length. This is a common problem on dynamic sites, and you should be able to find solutions by searching on those phrases.

Jim