Welcome to WebmasterWorld Guest from 184.108.40.206
Forum Moderators: ergophobe
I've already been to the Adobe Products: Coldfusion MX7 website to read about it, but am looking for specific answers to how SEO friendly this format is?
Any and all info is appreciated.
Although I may be somewhat mistaken, due to my infamiliarity with ColdFusion, I am under the impression that CF itself is more of a scripting language to allow for complex operations using a simple syntax. The CF syntax runs on the server side, and then outputs HTML etc to the client as needed. So, use of CF is, inherently, not going to cause problems with anything.
The reason I question coldfusion seo friendliness is because of a string I read on the seo chat forum - and how while it can be indexed, it presents problems because it's mostly java?
I didn't like what I read and just want to be sure before recommending it or not.
Is this more of a "techie" question? I can follow and understand the techno stuff but am not all savvy to it.
Again, any info from anyone experienced in coldfusion or has optimized coldfusion sites?
We originally chose it so that anyone at the client side offices could log-on and easily update content in real time by themselves. That function has worked like a dream from day one.
Getting a good ranking in the SERP's was difficult during the site's early days. After a year or two the site did achieve the rankings we wanted. I am not sure if that was due more to the SE's learning to accommodate CF sites, the maturation of the site, or my efforts at SEO.
Today we have a stable position in the SERP's, above the fold, for the dozen or so keywords we need.
People tell us that CF is "out-of-date" , but then hasten to add "if it ain't broke, don't fix it".
Skier, any usability concerns you can think of, that would arise from use of ColdFusion? One I can think of is sort of related to what you just mentioned, multiple people updating content, perhaps unaware of the usability implications such updates may have. How is the markup itself handled? Is it predetermined due to previously configured tags, or is the user able to change that too?
Perhaps the biggest concern might be the cost to hire expert help from time to time as you build the site into ever more complex levels of operation.
If you just need a glorified "brochure" type site, this may not be for you. If you expect to develop an active site with various applications for the same information presented in different ways and for different purposes and the information changes regularly...them cf is worth looking at.
In this case, the client built a site initially to serve information to the visitor and wanted to be able to update every day, from their offices without need for a tekkie. Today, that same data base drives direct on-line sales, inventory control, bookeeping, customer communications, and a host of other routines. It just sort of grew naturally as the client saw office data entry activities duplicating the stuff that was going into the website and asked to have the site functions expanded to take advantage of the data stored there.
The pages (or sections) each have a wizard interface for the staff. Each of the staff have their own areas that they work on exclusively. The wizards do limit the extent to which changes can be made. However when staff needs to make more "global" changes the wizards can usually be updated quickly by the "experts". Expansion to give them control over broader parameters often leads to rapid growth in content.
No, there has been little difficulty with staff updating content. The heavily pre-formatted input wizards take care of that.
If we had started with HTML, I greatly doubt the site would have grown to "become the business" as it did. The active involvement of the client in maintaining the site every day, themselves, and spending time thinking about it, has given the site a vitality that is communicated to the visitors and keeps it in tune with the customers and the competition.
If you are asking why CF rather than another format - I really don't remember what options we compared, if any. At the time CF was relatively new and offered features that we needed. There was a CF specialist willing to help out when we got stuck - at a reasonable price and someone we already knew. So it was not really a technical based decision, just a decision "on-the fly" during a fast paced period in the business' life.
[edited by: Skier at 1:02 pm (utc) on Sep. 26, 2006]
On the back end, we started using CF because of its quick learning curve. In classic ASP, I seem to remember needing something like 5 lines of code to declare, open, and access a database connection. That same functionality is handled in 1 CF tag.