If you own a website, you may think that the information released by Google is reliable information to base your actions upon regarding your website. You’d only be partially right. Because Google doesn’t tell you everything, and doesn’t want you to know everything.

Google has a set of standards. They want you to think that those standards are completely enforceable, when in fact, they are not. They want you to adopt those standards as your own, and to never never try to trick the search engines into giving you what they consider to be an unfair advantage. Of course, their definition of “unfair” is probably not the same as yours – but they want you to act in a way that is in compliance with what THEY prefer to have you do – and not necessarily what is in your best interest.

Google does NOT want you to know their exact methods of judging what they consider to be quality and what they do not. They do not want you to know what their technology is, or is not, capable of. And they do not want you to know exactly how they decide that one site is more important than another. They are afraid if you know that, that you will use that knowledge to manipulate their search engine to give you an unfair advantage. In fact, the Guidelines in the Webmaster Tools contain many verifiable inaccuracies, combined with instructions so vague and commonplace as to be completely uninformative  – so even their own instructions do not yield any useful information.

They would like you to believe that their technology is capable of more than it really is. You see, computers cannot THINK, and never will be able to. So when it comes to judging quality, they really can’t do that. Because they cannot think, they’ll punish you unfairly a good percentage of the time, and reward you unfairly a good percentage of the time. And interestingly enough, those numbers really haven’t changed a lot with improvements in their system, they’ve just changed the kinds of things they reward or punish.

Let me be clear on one point right off – I do not recommend “black hat” (sneaky or deceptive) SEO tactics, and I never have. I have always believed that quality and value are the best choices, and that they give you the best return, no matter where they are applied, and that this philosophy is the best one for SEO. I believe that an honest person, trying to convey an honest message, has the advantage in the long term.

The fact that Google (and other search engines as well) do not really WANT you to know what they measure and what they don’t, means that to an extend, SEO professionals are simply guessing on many points. Oh, sure, experience tells them that this matters and that does not, but sometimes that experience is misinterpreted. There is NO SUCH THING as objective double blind testing with SEO – because no two situations are identical, so they cannot be objectively measured. So it is not only impossible to get Google to give you a straight answer, it is also impossible to figure it out by objective analysis.

This accounts for many of the misconceptions online about SEO, and for many of the wild theories that repeatedly resurface. It also accounts for the buzz raised each time Matt Cutts says anything even mildly suggestive of real information (which, upon closer examination, always reveals itself to be more sidestepping of genuine communication). It is almost funny to see the news reports after he gives a public address – people will be announcing the amazing thing he said, when in fact, he did not say anything at all, just suggested that he might know something he is not going to tell.

So take the words endorsed by Google with a grain of salt. They are not always true – and they are more often implication than actual statements.

Because in reality, Google doesn’t WANT you to understand how it all works.

It has been a new experience to begin experimenting with advertising on FaceBook. I have run, or attempted to run, several ads, and one of my associates also used FB ads.

They can be purchased as PPC, or Pay Per Page Load (referred to as CPM). PPC costs more per, but is action based. CPM just charges you to show the ad, and does not guarantee clickthroughs.

FaceBook has some rather strict, and often strangely implemented rules about advertising. It seems to be implemented through keyword flagging, rather than by thinking people. If you have an ad that has certain words in it, which they consider to be restricted, your ad will be disapproved. No appeal. NO second chance. Once disapproved you may NEVER resubmit it, and never advertise that website again.  We find this to be not only harsh, but entirely unreasonable, especially since reading their guidelines won’t really clue you in as to which keywords they are flagging, or even why. Their terms of use are fairly vague, and non-specific, so it is difficult to tell sometimes just what they are forbidding.

This means, that if you word a disallowed topic to sound like an allowed one, you can promote it. If you accidentally describe an allowed topic using a word that they have flagged, your ad will be disapproved, regardless. Even more oddly, when we had one ad approved, they subsequently disapproved an ad for the SAME THING (using a word they did not like), and they said I could never advertise that item again  – all the while, the original ad, going to the same URL, was running in the background and they were happily charging us for it.

The second thing that people often misunderstand about FaceBook ads, is how they are targeting. If you are offering Web Design services, for example, and list “web design” as a keyword in your list, they will display your ads to OTHER WEB DESIGNERS! Because the match words are pulled from the profiles. So you have to list keywords that fit your target market, and NOT necessarily words they would use in a search engine. This is obviously a problem to many users, because I am constantly bombarded with ads for web design, and graphic design.

Can they work? The verdict is still out. We did get clickthroughs – though the price we had to pay for them was pretty steep for one industry ($1.50 to $2.00 per click). The “suggested bid” was so far off that it was pretty well useless – it suggested bidding $.67, when clicks were STARTING at $1.52.

We did not make any sales, but we also did not run it for an extended period of time. We did try tweaking the ad – but ran into the disallowed issue above, and did not dare submit another ad for the same thing, lest they blast our current ad. Such inconsistencies make it very difficult to truly test and optimize the system.

They do have a nice ability to target regionally, which is useful for some businesses.

Overall, I think they could really work for our seminars. But having insulted their word list, I’ll never know that unless I want to set up another website and promote it there and link to the main site. That seems a bit too much like playing games to me, and frankly, I’m finding that FaceBook is making it a bit too difficult to allow me to pay them money, so I have sort of lost the enthusiasm for testing it anymore.

Our associate who used this found that it was good for delivering visitors – though she also had to tweak her keyword list – but that it really didn’t result in increased sales. She is hopeful that some of the people who still associate with her due to contact through the ads may eventually result in business.

If you decide to play with them, realize that a $5 per day budget may not go as far as you think, and that the censor-bot that screens your ads is impossible to predict.

Some of my friends are able to make money from WordPress sites. I have found that it is much harder to make money from WordPress sites than from Joomla or other dynamic systems. Oh, I don’t mean as a website owner, I mean as a website developer.

WordPress has more of a reputation for being “easy”, and for being “cheap”. So most people who come to us wanting WordPress solutions, expect to pay about half what they do for Joomla site services.

If WordPress really WERE easier to set up than Joomla, that would be ok. But it isn’t. It takes as much time to set up a simple site in WordPress as it does to set up a simple site in Joomla. Editing templates and controlling template display is actually harder in WordPress than it is in Joomla, and since Joomla does more out of the box than WordPress, I spend more time installing things on WordPress than I do on Joomla, and find that many things that clients want simply are not possible in WP.

We have automated some of our installation and configuration processes. This means we can now install a pre-configured Joomla install, along with the standard extensions, instantly, when the customer purchases. We are also automating updating processes for our systems – we are finding this a bit easier to do with Joomla than with WordPress, because Joomla generally has better separation between core code and the extensions.

WordPress also stores the site URL in the database. This means moving the site, or building it under a temp domain and then activating it under the final domain, is one step harder than it is with Joomla.

Overall, in the final analysis, I can simply earn far more with Joomla. We have timed both WordPress sites and Joomla sites, and find we spend almost EXACTLY the same amount of time on the sites, no matter which system they are built in. Creating custom templates takes exactly the same amount of time in either one, using the tools we use. But we can earn much more from the Joomla site – often two or three times as much. Our hourly profit on WP sites drops to such a low level, that it would be very difficult to sustain a growth business on what we’d earn from them.

We do intend to offer WP options, but they will be simply pre-configured options, with a custom template, and DIY options other than that. Doing that will provide an acceptable profit margin if we can generate sufficient volumes of installs. But other than that, we find that offering custom solutions in WordPress has been a losing proposition for our company.

I applaud those who have been able to work out a successful business model creating WP sites, but with our target market, and our other earning potentials, it has not been an option that allows us to earn as successfully as other systems.

Ooooh! I actually SAID that! But really, tableless design is one of the most irrelevant things I’ve come across in a long time. As though by eliminating the use of table code, you prove yourself a superior designer, regardless of the annoyances and extra time that it takes, when it isn’t even detectible in any way to the site user.

For the average site, there are absolutely NO advantages to tableless design. None. I don’t know which designer decided it was superior, or why it caught on, but the only explanation I can find is ego. It is more difficult to code a tableless template for many structures, which makes those who do so feel superior. Silly, really.

Neither type of coding is better. Those who advocate tableless design say that it produces leaner code. Not true. Bloat is just as prevalent with tableless design, often MORE so, because you have to create so much more code to do what a table can do without even trying.

My biggest issue with the elitism on this issue though, is that common sense is being ignored. The fact is, tables can do some things faster, easier and more predictably. And a design coded in divs just CAN’T do it. The code can’t be FORCED to do it.

An example…

We created a design with a menu that had multiple blocks across. Four cells across on each level. My coder originally coded it tableless. And the results were disastrous.

About every third refresh, the divs would stack instead of laying side by side – they would stack in all sorts of arrangements. And you could not MAKE them go side by side. The code does not exist to make them do so. She tried everything to force them to predictably do so. No go. Because with divs, they are independent containers. And if the browser wants to load them wrong, it can, there is no way to require it to display four across.

Now, there are those that insist that if you MUST use table code, then code it into the CSS instead of in the HTML. Really a stupid idea, because doing so removes every advantage of using table code in the first place – the predictability. Being a progressive coder though, my coder tried this next. It still had the same problem. Because CSS tables have the same problem divs do – the cells are independent containers, which are not required to behave in relation to one another.

We replaced the div code with HTML table code. It has behaved predictably ever since. Because a table is a single entity, with containers that are part of the whole. If you specify four cells across, it HAS to display them all across, and CANNOT stack them inappropriately.

There are other times when divs simply do not behave themselves, and debugging them takes so much time that it is more fair to the client to just use table code and get on with life. Getting anal about this issue is pretty dumb, and is responsible for a LOT of wasted time and energy, with absolutely NO benefit to the client or the site visitor.

The claim is made that the ONLY reason that divs will refuse to go where you tell them is that the width numbers don’t add up right. Not true. There are all KINDS of bugs and conflicts that can cause this, and tracking them down can be a nightmare, especially when working with someone else’s code.

I just find that any claim that tableless design is superior is a pointless claim. That superior design is not arbitrated by whether you use one type of structure or the other, but by whether what you use WORKS, in the MOST EFFICIENT manner. If you have not gained BOTH predictability, AND efficiency, you’ve made the wrong choice! Statistically, tableless design holds no corner on that market – in fact, about 50% of the time, it will WASTE time, and result in a higher level of INEFFICIENCY, and UNPREDICTABILITY.

The end result is what matters – irrelevant fussing over whether you used tables or not is not an intelligent use of either time, or intellect.

Blog or Website? Which is better? There has long been controversy over whether one really is better for SEO, and if so, why.

I’ve heard reports that blogs do actually index faster, by a week or so, from a credible source. I’ve not heard any other compelling or believable information on long term SEO benefits that were specific to blogs. There was a time when SEs were indexing every blog and treating them like they were something special, but it was short lived – stopped about the time the spammers caught on and started abusing blogs left and right. There hasn’t been any preference for YEARS.

Faster indexing is the ONLY difference I’ve been able to isolate as having any validity, that isn’t attributable to other factors, which are independent of the structure. Most differences have to do with the quality and desirability of the content, the individual optimization efforts, and the promotional efforts of the site owner. Period. Potentials are equal between most good structures, whether it is WordPress, Joomla, Drupal, HTML, etc.

Speculation runs the gamut… I’ve heard all of these things touted as reasons why blogs or websites are “better”.

• Search engines like blogs better.
• Search engines like websites better because they are more stable.
• Search engines like blogs because they have changing content.
• Blogs optimize better.
• Websites build backlinks more stably.

Actually, these factors are all pretty irrelevant.

Search engines don’t really care whether it is a blog or a website. Blogs can behave like websites, websites can behave like blogs, and search engines don’t care. They care about UNIQUE CONTENT. Structure, aside from ability to optimize to a reasonable degree, is completely irrelevant.

We’ve noticed that website pages, or blog pages (posts), index and get traffic long term based on backlinks, and demand for the content. If they are referenced elsewhere, they get more traffic sent directly to them. And if you are the best source for a high demand, low availability topic, you’ll get traffic no matter what structure the site is in (this is, in fact, a great key to getting spontaneous traffic).

Changing content is also irrelevant to the structure. Search engines DO like new content, but ONLY if it is GOOD content. Doesn’t matter how often your content changes if it is trash, Search engines can recognize trash, and they treat it the same way people do. Ever seen those Splogs… You know, those tacky blogs responsible for 99% of comment spam, which consist of nothing but quoted blog posts? Search engines dislike them, and they are a waste of time, because they lack quality original content. The only people who create them are the ignorant, and the dishonest who are charging people for bogus “SEO” services.

Some blogs don’t have regular posts. Some websites have regular updates. So changing content isn’t the reason why some people feel that blogs index faster, either.

So what is it?

It is the ping.

The ONE significant difference in BEHAVIOR, aside from user actions, structure, or quality, is the PING. Potentials are completely equal in all other respects.

Blogs ping when you create a new post. New content has a brief appearance in the latest items index on some directories, then goes into the archives. You have to claim your blog at Technorati and list it with some directories. But as soon as you do, your new posts are announced to them, and fed through RSS.

Some of the blog directories are considered very high credibility links by Search Engines. It helps you get linked faster.

It is important to note though, that the power of the ping is MOSTLY transient. One brief moment in the spotlight, then your page disappears into oblivion unless it is highly desirable information, in which case it will regularly resurface.

So what is the real power information here?

You can make a website ping and feed. You can make pages behave like a blog, you can post regularly, and you can install an extension to make it ping when you update content. Many dynamic site structures have RSS capabilities which can be enabled and used.

The choice of whether you use this or that structure doesn’t depend primarily on indexing speed, or any assumptions of blog preference. It depends on what features are needed, and what the long term growth needs are.

Where SEO is concerned, the playing field can be completely leveled in all other respects.

I have some pet peeves about the elitist attitudes of some web designers. They seem to feel that the way they do it is the only way to do it, and that anyone who fails to do it their way, is somehow inferior. One of those issues, involves hand coding.

Their assertion is that hand coding is always superior to that created by a WYSIWYG HTML editor.

My assertion is that 99% of the time, a WYSIWYG editor will produce a superior result. Because 99% of the time, the site is being coded by someone who has an insufficient understanding of code to produce superior code.

The fact is that human error is responsible for more poor site performance than even bad WYSIWYG editors. And human error doesn’t just cause non-compliant or oddly coded sites. It causes major problems. Well, the one exception would be MicroSoft Word – there are people who think that it is an HTML editor, and it is NOT. It out classes the worst human errors. But as a rule, people are the source of the greatest mistakes, and the mistaken notion that hand coding is somehow superior is responsible for a large percentage of those mistakes.

There are three levels of skills:

1. Beginner. These people know nothing of code, they create a site in an HTML editor because they cannot create one any other way. Any attempt to edit code by hand will potentially cause more problems than it solves.

2. Intermediate. They understand code, can hand edit it to improve or alter some kinds of code, but do not hand write it, and SHOULD not. As much as possible, they should either start with an existing template and customize it, or, use a WYSIWYG editor to create the site code, then only make necessary alterations by hand.

3. Expert. This is someone who understands code so well they can write it from scratch. In this case, they should STILL start with an editor – why? Because it is, frankly, faster to use a WYSIWYG editor, and then tweak it, than it is to write it from scratch. This is more fair to the client who is paying for it. It is also more accurate. Editors are by nature more accurate, and less likely to make typo mistakes. A good one will consistently produce good code 90% of the time, with consistently known issues with the other 10%. A smart coder can easily improve that 10% in less time than it takes to write the other 90%.

It simply is not true that hand coding is superior. In most cases, it is a complete waste of time. It is a myth in itself too, because many people who are touting hand coding as the ultimate skill are using some kind of software to do half of the job anyway.

The key for most designers is to choose a good WYSIWYG editor, and then learn to use it well. Good tools IMPROVE the quality of work, they don’t compromise it, and there is no shame in depending on good tools. It is, in fact, smart strategy.

The myth that hand coding is somehow better than software coded pages is perpetuated by snobs who want to belittle those who don’t have a highly specialized understanding of code.

I rarely make product announcements, but am taking the liberty of doing so today. We’ve been working on a nifty little script for about 9 months now, and it is finally ready for prime time.

WildFire DSI is an auto-installer for Open Source or Custom website Scripts. DSI stands for “dynamic script installer”.

It works with our hosting billing manager (WHMCS), and on Cpanel/WHM reseller accounts, VPS, or dedicated servers. It has a lot of features which make it really cool, if you don’t mind my tooting my own horn for a bit.

The neatest thing is, that it can install just about anything. We have templated install files for Joomla, Joomla with VirtueMart, WordPress, and CRE Loaded/OSC. If it will install those, it will install practically anything. And it can install as many different ones as the web service provider wants to install.

In plain English, this means a client can go to the ordering system, choose from a list of website packages, for example:

• Joomla with no frills
• Joomla with a directory
• Joomla with Virtuemart
• CRE Loaded
• WordPress
• Joomla AND WordPress together
• Magento
• Or just about anything you want to offer them.

When the client purchases the site structure, the system identifies the one that was chosen, and automatically installs it. Instant website.

Our coder was truly brilliant about how he created the functionality. It is so flexible you can even make it personalize an install for the client.

We love this, we’ve been using it in our own business, in one form or another, for about 6 months. It allows us to pre-configure the install packages, which saves us so much time on the installations we do most often. It has also allowed us to tap into some fairly lucrative vertical markets (targeting a website service for a specific industry).

It went live today, at http://www.dynamicsiteinstaller.com, complete with affiliate program.

I really didn’t even want to sell this. It is such an advantage for our business, and such a powerful tool, I wasn’t sure I wanted to let to go to empower my competition. I sort of wanted to keep it just for our students and our own business. People keep asking for it though. And I guess I want to share my knowledge and tools more than I want to hoard them.

If you’ve been researching this very much, by now you are probably thinking, “When is someone going to just give me a straight answer about what I need to do?” Ok, that’s exactly what I’ll try do.

For small business owners that accept payments online, there are special considerations, and some limitations that you must observe in order to be PCI Compliant. I’m assuming that if you read this, you know that you DO have to be compliant if you accept payments online. If you don’t know that yet, then take my word for it.

There are two basic things you need to do:

1. Make sure the WAY you take payments is compliant.

2. Make sure your policies regarding your site management, site access, and site software are compliant.

We’ll tackle the first item first.

The big thing about accepting payments online, is HOW you accept payments. And small business owners are prone to taking shortcuts here, thinking that there are shortcuts that will save them money. The issues are not simple – there’s a lot of technical stuff going on here. I’ll try to simplify it, but may not be able to simplify all of it.

There are three ways that site owners typically choose to accept payments online. I’ll list those, along with the costs, and risks.

1. Collect credit card numbers online, and then process them offline. To be PCI Compliant, you MUST NOT DO THIS! In fact, if your credit card company finds out you are doing this, they’ll slap you hard. The ONLY time you can do this is if you have a third party hosted shopping cart that is PCI Compliant (so you don’t have to bear the burden of it). Don’t assume it is!

This is NOT the least expensive way to do it, and it is terribly risky. You have to store the credit card numbers on your site, and therefore YOU are responsible for all risks associated (even if you use a third party hosted shopping cart). It is expressly forbidden by the PCI Compliance rules unless you meet VERY stringent security standards. You can’t. They are too expensive. Think a couple hundred thousand dollars.

If you are collecting credit card numbers online, and processing them (or handing them to someone else for processing, such as a direct sales parent company), STOP. Immediately. To continue to do so is an unacceptable risk, with potential civil, or even criminal penalties if someone else gets hold of those numbers.

If you have a website where numbers are passed to a gateway (Authorize.net, PayPal Pro, etc), then check to make sure that a “store credit card numbers on server” setting is NOT set to ON, ANYWHERE in the site configuration, because if it is, you may be accidentally doing this when you did not mean to.

2. Use a standard gateway, such as Authorize.net, PayPal Pro, LinkPoint, etc. This option is less risky, and less costly than option #1, but it does have ONE major requirement to it that makes it become costly. You MUST pass quarterly security scans. And those scans will cost you at least $350 per year. This option will not be affordable for most small businesses, in part because of the cost of the scans, in part because of the security enhancements that the scans will tell you that you need.

This option requires PCI Compliant Hosting, a PCI Compliant shopping cart (no, CRE 6.4 does not qualify), and PCI Compliant SSL. These enhancements will prove too expensive for most small businesses.

In this option, credit card numbers are COLLECTED by your cart, then PASSED to the gateway where they are processed. So you are responsible to ensure that the COLLECTION and PASSING processes are secure.

3. Use a hosted gateway service to process payments. This is similar to Option 2, in that it plugs into your shopping cart to accept payments, with one HUGE difference. That is, ALL collection, and processing, take place on the service provider’s site. Your cart is then required to meet reasonable security standards (to keep someone from diverting the traffic to a fraudulent site), but that is all. And MOST carts already have the goal of maintaining that kind of standard security measure.

In this kind of setup, the visitor adds items to the cart, hits checkout, and after reviewing shipping information, is taken to the processor website to finish the transaction. Only the CART CONTENTS are passed to the processor, NOT the financial data, presenting MUCH lower risks.

This kind of system includes the following processors:

• PayPal Standard – when the order is placed, the shopper leaves your site, and goes to PayPal’s website to complete the transaction.
• Authorize.net SIM – Be careful here! Authorize.net has TWO ways that it can be set up – one that falls under the process of option #2, and one that qualifies here. The shopper MUST leave your site before entering in ANY credit card data to fit in this category of risk and cost.
• YourPay Connect – Again, be careful! This service can be set up more than one way. But it CAN be set up to accept payments on THEIR site instead of yours.
• Google Checkout – Takes the visitor to Google’s site to make the payments.
• 2CheckOut – Also takes the shopper off of your site to make the payments.
• Any other system that takes the shopper OFF your website before any credit card information is entered in.
• This is what CRE 6.4 does, and the category it falls into.
  

Basically, what you are doing here, is OUTSOURCING the PCI Compliance. You are taking the worst of the headache and letting someone else handle it. Not a bad option. Credit card companies will then typically remove the requirement for quarterly scans, and require only that you fill out a form each year. If you use only PayPal Standard, or 2Checkout (or a few other all in one systems), you won’t even be required to fill that out.

Drawbacks may be that the site feel changes when they go to the payment processor. This is a common thing though, and generally does not significantly impact sales for small businesses (the equation may be different for big ones). Most systems of this kind (including PayPal) have the ability for you to brand your processor pages with your logo, and to choose between two or more layout options.

If you use this option, we recommend turning it to your advantage – state in your Privacy Policy that payments are not processed on your website, and that it is to protect the sensitive financial information of the shopper. Turn the disadvantage to an advantage.

So, those are your three options, and the rough idea of what is involved in achieving PCI compliance with your shopping cart. There are several other factors which you must also be aware of, to be fully compliant, and they involve things besides just how your cart is set up.

1. Choose software that is updated regularly, and that is not inherently risky. Avoid Resale Rights software (TERRIBLY risky!), and avoid creating a shopping cart in FrontPage (it is outdated, and the code it produces is vulnerable). The more popular Open Source carts are usually acceptable.

2. You must ensure that security updates are done for your software. Generally this means having a policy to check for and install updates, or contracting this out.

3. You must have a policy for your business that minimizes risks. This policy should include two important elements:

• Avoid sharing site or financial data access with anyone unless there is truly a need, and they are trusted. In other words, don’t be careless with passwords and information.
• Don’t share passwords. Set up individual accounts for anyone who does need access to private information or to the site structure. This allows you to delete users if they leave your employ – very important if they leave with less than positive feelings.

It comes down to minimizing the risks where you can minimize the risks.

Much of it is common sense. Meeting the requirements need not be hard. The simplest strategy is this:

• Choose website software that is reasonably safe.
  
• Use PayPal Standard (or Authorize.net SIM or YourPay Connect if you are in a high end market that does not respond well to PayPal).
• Keep your website software up to date.
• Don’t share passwords, and limit site or hosting access to necessary personnel.

Those four items will pretty much address the need for very small businesses to be PCI Compliant.

If you have needs that dictate functioning beyond those payment options, then you will require a fairly high budget to meet them. That is the reality.

But by following these standards, and simplifying your processes, you can meet the need for compliance without additional expense. The expense and demands will only become prohibitive if you move outside the simpler payment options.

DISCLAIMER: This is my interpretation of the basic requirements. There are those who may disagree with my interpretation of it. Your merchant account provider is the final arbiter of precisely what is acceptable and what is not. If I have made any errors in my interpretations, I invite those with superior knowledge to correct me. I will correct and print any validated information which is other than what I have printed here.

This has many applications for Small Business Webmasters. It applies to everything from design principles, to site organization, to site features, to bells and whistles, to the services you offer as a webmaster.

We have a rule for this:

If it doesn’t increase revenue in a measurable way for the client, then more isn’t better.

In fact, if it fails to meet that test, then more is WORSE for a small business website. And more very often costs more, but returns little or nothing.

Every feature you add to a site comes with a burden of upkeep and maintenance. So adding things just because you CAN, is not a good enough reason. Showing off your latest tricks is not ever part of a wise webmaster’s game plan.

Many bells and whistles come with a price of decreased compatibility, lowered search engine friendliness, and an exponential increase in initial costs which cannot be justified by the corresponding increase in ROI – if there is one at all. In fact, the decreased compatibility and lowered search engine friendliness can completely obliterate any positive ROI for many situations. Weight it carefully in dollars and cents, inform the client of your conclusions. They may still choose to waste their money, but if they do, it will be an informed choice, and not something they wandered into because you failed to protect their interests.

The same principles apply to your own business. Often, consolidating the kind of services you offer can allow you to produce better, and more cost effective services, at a higher profit. This is one of the keys to our success. We pay attention to the things that are both a better deal for the client, and more profitable to us, and we then revise our services so more things fit that criteria.

We have reduced the site types we deal with on more than one occasion, when we did an analysis of the changing industry, and our changing skill levels, and realized that a single line of services was taking more time, and causing more unnecessary cost for the client. Since they also had better alternatives, and keeping a bad choice open just so the client could choose a bad choice, is just not a smart business decision, we have closed down service lines on mulitple occasions based on what was in our best interests, and in the best interest of the client.

We have also reduced some of the other items we work with, when we found one method that outperformed every time. There simply was no justifiable reason to continue to offer less productive options. See, for many things, you can’t charge more for an inefficient item, the market won’t bear it. So YOU take the hit in productivity. For many kinds of services, you can streamline a system with one service provider, while others will cost you in features that are not present, functions that are disabled, and processes that do not reliably work within those service environments. Hosting is a BIG one here. The same process can take 10 minutes on one host, and two hours on another, just due to fussy things that don’t work as expected. We’ve had the difference be as much as 10 hours, on a simple dynamic site install, between one host and another! It WAS a simple process on one, but anything but on the other.

Consider carefully what is NEEDED, to keep your business sustainable, and for the client, consider what they NEED, to grow their business in the most cost effective manner. Sometimes you have to give up choices, but often, when you condense to LESS, you end up with MORE, in time, earnings, predictability, and performance.

That is worth putting some thought into.

“I want a clean and simple looking website.” Another thing they say, but which means different things to different people. I’ve had dozens of clients say this, and you never quite know WHAT they mean by it. Here are some translations:

1. I want lots of white space.

2. I want a design with a white background and very simple accents.

3. I want a design with sharp edges, no shadows, no background graphics.

4. I want a design that has very little navigation.

Now, usually they mean just one of those things, sometimes more than one. But every client means something different when they say it, and if you assume they mean the same thing you do, you’ll strike out on the first attempt.

A clean design means their interpretation of order and simplicity. Sometimes that conflicts with the needs of their site – it is increasingly common to have a client who needs an incredibly complex site with multi-layers, to want only a single navigation bar, or for someone with a combination infosite and cart to want a two column layout with big boxes and large text. They simply do not realize how much space things take, and that if you want to put hundreds of things into a site, you have to have a place to put it all.

Sometimes good site organization, using multiple menus in uncluttered ways for sites with a lot of content is the key to making it appear simpler than it really is.

Achieving a “clean” look, then, becomes a blend of understanding what the client means, and working with their needs to balance what they want, with what they actually need.

It ain’t always easy… But it is usually possible to achieve a satisfactory result.