Welcome to WebmasterWorld Guest from 126.96.36.199
Forum Moderators: mademetop
Im in the middle of developing a cms solution for a newspaper.
Its key that the content of this site contributes to a higher rank in the search engines.
I can produce the content in one of two ways, dynamic content where the page would be found by a querystring or by actually creating a seperate html/aspx page for each seperate news story.
What would suggest to do, does it really make a difference?
If I do create a page on the fly, does it matter if its an aspx page or an html page. The reason I ask this is that I would want to use iframes in the site and the page that I create I would like to include an iframe for the menu. it would seem that for an html page you cant create an iframe with the src of the frame set to an aspx page.
Thanks for your time
Here's my 5c worth. I have a site that is very dynamically driven with no new static content at all. Content is created by users' posts and it's all stored in a database.
Judging by the importance given here to "fresh content", I'm considering doing the following:
In addition to the dynamically driven page, I'd like to create a new static HTML page programatically, with the title, description, content and physical filename based on the new content.
So I'd have a new directory, let's call it
In it I would have a static HTML file:
Everytime a new post is created I overwrite the file with the new content and "voila" - a freshly updated page that Google will LOVE...hehe
OK I'm probably barking up the wrong tree?
Very similar to how Im thinking of doing mine.
Store the article in the database (for searching purposes) with a link to the physical html page.
Creating the physical file is easy enough, give the page a file name of [Category][year][dayofyear][dd/hh/mm/ss/ms].html such as [news20043002015113010.html] and then linking the article results and home page to the physical file.
Sounds fairly similar. Is this the best way of going about this?
Pros of dynamic publishing (frying): you can easily customise/personalise the content, and the pages displayed are always up to date. Cons: additional overhead of generating a page every time (whether it's changed or not), unfriendly urls (unless re-written) and a dependency on the database being up.
Pros of static publishing (baking): static pages are faster, no database/CMS dependency (if it falls over, your website will still be up) and friendly urls. Cons: you have to keep the database and published files in sync, dependencies between content pages means tracking what other pages need to be republished when one page changes.
Or you can use a combination of the two approaches: statically publish dynamic pages - and get a mix of the pros and cons of each!
I'm not sure if it's the "right" approach but I've noticed many high-ranking sites in my neck of the woods have a lot of static pages with different titles and content. It's the difference bewteen having one page heavily optimised for many phrases vs. many pages optimised for one phrase, one per page.
I'm going to investigate URL rewriting before I embark on a mission to create static files programatically.
Just one question though - is it a legitimate practice or can I be penalised?
Url rewriting takes place inside the web server, so to all external users (including search engine spiders) the friendly urls are the actual urls. Url rewriting does not involve redirecting or cloaking content.
Not sure I'm explaining this v.well - but search WebmasterWorld and you'll find lots of folks use it with no problems.
Looks like you've just saved yourself a large amount of work!
It was mentioned on the supporters forum that the best way is to have static content with server side includes.
To summarise am I right in thinking that the best solution is.....
1) Server side includes for navigation
2) Static pages
3) Url friendly urls.
Does it matter that the ssi is an aspx page with server controls? or does this have to be html only?