Articles

I am so happy that I develop sites with Drupal.

About a year ago we built a simple blog site for a friend of mine. As usual, we built it in Drupal, using Drupal 7 when Drupal 7 wasn’t quite ready. But I wanted the site to last long term, and who knew what tomorrow would bring, so I wanted the latest version of the most powerful Open Source Content Management System I knew.

This past week my friend wrote an article for the New York Times that linked back to her blog. The blog went viral, but I wasn’t worried. I knew that this simple Drupal site would easily be robust enough to handle the spikes in traffic that would come pouring in (of course the server was another story — but it held up as well).

When building even the smallest sites you need to fear success. If suddenly your business/organization gets popular, you need to know that your site won’t collapse under the pressure when you need it most. It is not the initial launch (unless you’re a site like grammy.com or whitehouse.gov — both Drupal sites) that will get you, it’s the sudden attention by thousands of users just taking a peek at the news.

There are many ways to protect your site from success. Using a system like Drupal is just one of them. Obviously, this isn’t enough, and server configurations are also important. Using the cloud can help with that. If you except or view a serious spike, with the cloud you can just increase the size and you’re set. But if the code itself isn’t built correctly, you’ll need more than what the could give you.

When we build sites with Drupal, we know that we have a huge community constantly checking and upgrading a good deal of our code. We know the core code has been tested in extremely trying environments, and we know that it can stand the heat.

So when nothinginmoderation.ca went viral last week, we weren’t worried.

(The following is based on actual events)

You have a fairly good idea of how you want your new website to look. You spend some time searching around for a developer, get some feedback and advise here and there, and are ready to proceed. You have someone plan your site, maybe add a few wireframes, a designer designs something that looks great on paper and the developers start working.

Your first surprise comes when they show you the first stage after uploading the site to a development server. “What’s that?” you ask, looking at the frame that has very little of what you had asked for. “Well that’s your site,” they say. “It’s coming along really well,” pausing for praise from you. “But there’s nothing here that I asked for.” You scratch your head. “It’s a work in progress — let’s get the design up and you’ll see what we mean.”

This is the start of a process that often frustrates both sides for the long weeks it takes to develop a new website. The next road block will come when you ask them to change something that really doesn’t look so good now that it’s functioning. “That wasn’t part of the design program,” they say, which is a synonym for “It will cost you extra.” After that you encounter the reality where some things don’t look quite like they did in the design and the developers will usually have a good reason for the difference, but one that you won’t really understand. It will have something to do with three-letter codes (asp, php, css) that you think they are making up.

There are many, many pitfalls to working with developers. Most have to do with expectations and communication.

What most people don’t understand is that developers work via a plan. The written website program (a site characterization) is a blueprint for the website. It includes a verbal description, the wireframes and then the design. Just as changing a blueprint of a house in mid-stride can cause problems and extra costs, so can changing a site plan of action. The site’s verbal description, if written well, will tell developers not only what needs to be done, but most importantly, why (See The Most Important Question When Creating Your Website ). Some changes are no big deal (like changing the color of a wall in your new house), but others are like moving walls after they’ve been built — not impossible, but what a pain in the ass. It’s important to understand the site plan documentation, make sure that it is clear to both you and the developer, and that you didn’t leave anything important out.

The design that developers received from the designer — the colorful one with pictures — you understand. It’s graphic. It’s worth a 1000 words. But that’s just part of the program, and often there are discrepancies between the design and the written characterization. Just a quick example: one site we worked on had a clear description of an upper menu with nine well described items that were critical for the site’s functionality and user interface. When we received the design sketch, there was only room for five items. Which do we remove? Do we change the design? Another site had lists on the left hand site of page titles. The site was in five languages. The design was only showing the English version. The German titles didn’t fit in the side bar (single words didn’t fit!).

Designs and plan documentation need to be flexible, but they are still the blueprints by which the site will be built. There are often items that look good on paper, but don’t quite work out in virtual reality. When you request changes understand that when you say, “it’s just a small change” there may be some major programming behind the scenes.

So let me give some clear tips:
1) Have a well written, detailed, clear and concise (more is not better) site description.
2) Go over the document with the developer and make sure she understands it.
3) Compare the design with the document and work out discrepancies before development starts.
4) Be flexible without compromising critical parts of your plan.
5) Understand that changes and additions mean more time and often more money.

Developers can’t always see what you’re thinking, so make sure the documents hold up.

Think you need SEO help?

Let’s try something. Google “SEO”. Then click on the “10” in the Gooooooooogle pager at the bottom. Go ahead and do it. I’ll wait…

See how many SEO companies are ranked 90 or more? Granted, SEO is an extremely competitive search term, and if every one of those companies was doing everything right with their own sites, still someone would have to be number 100, right?

But even more interestingly, there are scores of websites ranking higher than many of those SEO companies, and these sites clearly are not targeting the keyword “SEO.” I won’t supply examples, because the results constantly change, but it’s fairly consistent. Does this mean that spending hundreds of dollars on SEO is not a worthwhile investment? Not necessarily, but it does mean that SEO is a bit more complex than these companies make it out to be.

Search engine optimization is a huge and growing industry with companies investing significantly in SEO, whether it be in-house or with an SEO agency. Using an external agency, a business or organization could be expected to spend from $200 per hour, with monthly payments reaching $2,000 per month. In-house will cost even more, taking into account salaries and benefits. SEOmoz found that external agencies tend to do a better job as well, focusing more on keyword research and social media marketing than their in-house counterparts.

I have often arrogantly claimed that web developers know just as much about SEO as SEO professionals. That was because most of my contact with these professionals came from small SEO companies jumping on the SEO bandwagon and/or in-house “SEO professionals” hired because they knew what CPC was. I know that a good, well-oiled SEO company can actually help even me, the arrogant web developer, improve page ranking, search engine marketing and drive traffic to my client’s site — but not by much.

And what about non-profits? What should non-profits and NGO’s do when they have a low budget? Are the SEO steps the same from non-profits as business SEO?

Yes and no. Mostly no. Search engines really don’t differentiate between a business and a non-profit. What you do with your revenue really isn’t their business (yet). But there is a difference because the users you want on your site are not searching for the same reasons as consumers search. Like any site, you need to define your target audience, create the same backlinks and balance your keywords. But there are tools you should use that aren’t a high priority for businesses (like blogging). An SEO specialist will need to understand the organization’s goals to be able to target correctly. Generating traffic is generating traffic, but since the intended outcome is different, the work is different as well. And a good SEO should teach a non-profit how to fish.

Non-profits have causes. They need donors and the donation world has been turned on its head. Microdonating, social media outlets, vast amounts of information available to all, make getting people to hear you a far cry from the find-a-rich-donor-and-talk-his-ear-off method. To paraphrase Bill Clinton, “it’s the issue stupid.” SEO has to focus on the issue — make it loud and make it clear.

Whether you are a business or a non-profit, you need to ask any SEO professional or company some basic questions before you hire them.

• Are there guarantees? As soon as you’re finished will my site rank on page one in Google?
  If they answer yes, move on to someone else. Seniority, content, search terms, backlinks, all take time to register and raise your page ranking. If your content isn’t good enough, you may never make page one, no matter what they tell you to do. But in time, you have a fair shot.
• What are the steps to increase my site’s search results?
  Somewhere in the answer should be to examine the site structure: page titles, errors or issues, etc. And then they should say something about analyzing content and backlinks. That’s basic. The rest is icing on the cake.
• Google is never sleeping. How can you actually know what you’re doing if the algorithms are a moving target?
  There are two parts to the answer you are looking for here: Firstly, study. The SEO professional should be hooked into the SEO notifications coming out all the time. Secondly, testing. Changing SEO means that testing should be going on all the time — and not on your live site.
• I’m a quick learner, can I do SEO research on my own? What tools should I use?
  Any skirting of this question is a red flag. There are many free tools that you can use and any SEO professional should know them. The confident professional’s arsenal is being able to provide the right advise once the research is in. I know I’m shooting myself in the foot here, but for non-profits, I would strongly recommend self-help — it’s cheaper and no less effective. Maybe just pay a consultant to get you started. But SEO is not rocket science (we need a better metaphor, rocket science isn’t that difficult these days).

And those tools? Start here:
Google Trends
SeoChat
Webconfs

SEO is constantly changing, and only the best SEO professionals will be keeping up with the changes. There will also be a lot of hit and miss and what worked yesterday, won’t work tomorrow. Google already tries to look at quality, which is both subjective and very difficult to quantify for SEO.

And did I mention the Semantic Web?