4 Mistakes That May Result In Your Website Being Held Hostage: Part 2

4 Mistakes That May Result In Your Website Being Held Hostage: Part 2
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /home/forge/www.websearchsocial.com/public/wp-content/plugins/fanciest-author-box/includes/ts-fab-construct-tabs.php on line 94

Last week I started a discussion on how to prevent your website from being held hostage. Here are avoidable mistakes 3 and 4.

You Can’t Control How And When Your Site Is Updated

I met with a small business owner recently who was frustrated by lack of marketing results and asked me to evaluate his website. This business owner had long since paid another developer for his website and was now paying a monthly fee for “SEO services”. The monthly fee entitled him to request two changes to the site per year.

After I took a good look at the site, I made some recommendations for improving the site but since my new client had already used up his allocated “two changes”, he was unable to implement any of my suggestions.

When I asked the developer how much it would cost to make additional changes to the site, he told me it was not possible to make any additional changes. Not even for an additional fee. When I asked for a rationale on behalf of my client, the developer said that more than two changes was bad for SEO.

If you’ve been reading this blog or know me or Carol Lynn, then you already know that updating your site more than twice a year is not bad for SEO. But just in case, let me be clear that this is a preposterous thing to say. The truth is the exact opposite. Search engines can learn more about you if you maintain and update your site with some reasonable frequency.

As it turns out, the rationale for the “two changes” policy had nothing to do with SEO and everything to do with aggressively limiting the amount of labor involved in maintaining the website. Additional changes, even ones that generated new fees, meant that the developer had to manage the customer and the freelancers doing the work behind the scenes. From his perspective, this was high labor, low profit work that simply wasn’t worth it.

This scenario is clearly and unfairly skewed to the needs of the developer. That’s the exact opposite of how any marketing professional should work. Every developer, service provider or marketing agency should always put the needs of the customer first.

It goes without saying that this level of inflexible control also means that you can’t access, move or in any way modify your website to meet emerging business needs.

You Cannot Access Your Web Stats On Your Own

I love stats. I look at the stats for this blog almost every day. In fact, if you’ve been reading this blog for a few years, you’ve probably noticed that the tone and direction have changed. We have better defined our audience and written specifically to their needs.

That didn’t happen by accident. It happened because we analyzed our stats. In fact, we’ve built custom reports inside of Google Analytics that allow us to break down data by author, category, day and time. And those are just the basic reports.

The point is, analytics are important.

But some developers do not give their customers access to analytics. Just last week, we engaged a new customer who asked us to perform an analysis of his site. I asked him for access to his stats. What I got instead was a white labeled PDF printout of the main screen of Google Analytics (GA).

I wrote back to my customer and clarified. I wanted the developer to add my customer to the GA account so that we could interactively review the stats. Instead we got another white labeled PDF and an Excel spreadsheet with some prose indicating how well the site was doing.

So what’s going on?

Many developers want to make sure that you hear the good news, and insulate you from the bad news. But practically speaking the bad news is just as important because it can inform your behavior.

For example, we used to write book reviews on this blog, but our stats showed us that those articles were universally the least trafficked. So we made the decision to drop book reviews. Overall, our traffic is now improved because we no longer have the “book review dip.”

Preventing a customer from seeing their stats allows a developer to craft the message that they want the customer to hear and that improves the chance of retaining the client. After all, who doesn’t like to hear perpetual good news? The problem is that this ruse has a short life cycle. If a customer continues to get good news about their site, but has no conversions, eventually he is going to ask questions that are going to be difficult to answer.

In keeping with the “hostage” theme, preventing a customer from seeing his own stats is a way of keeping the customer reliant on the developer. It creates the illusion that the developer knows deep secrets about the website that no one else knows. The fact that these free reports can be easily white labeled makes matter more confusing for unsuspecting customers. It’s not unreasonable for them to believe that they are getting something they can’t get anywhere else.

Ultimately, GA is free and adding a customer to an account to provide real-time, interactive access, takes less than 60 seconds. For the sake of transparency it’s the right thing to do. But if the goal is to keep the customer hostage, then a PDF is a better tactic.

The Sucker Punch

I promised you a sucker punch. So here goes.

Why does this happen? Who is to blame?

On the one hand, we could blame the developers for acting in an unethical way. They certainly bear some of the blame. But part of the blame must be assigned to…

You.

Yes, you. You, the business owner who wants to have your website developed for too-good-to-be-true low prices.

Here’s the thing: web development isn’t cheap. To do it right requires expertise and experience. A developer needs to know how to do things right and how to deal with things when they go wrong.

That comes at a cost.

But you, the customer, don’t always see it that way.

The weak economy here in the United States has resulted in a messy environment where several developers can quote the same project at wildly different rates. Developer #1 says your website will cost $5,000. Developer #2 says $1,000. And developer #3 says that they’re both nuts and will do it for $500.

Which one of them is right? It’s hard to say, but experience counts. The developer who has been in the business for years probably has a better grip on the actual cost of production than the developer who does it as a hobby or on weekends.

On a grander scale, fees associated with web development have been driven down artificially. The mistakes listed in parts 1 and 2 are likely a response to the lower fees that developers must charge in order to stay competitive. Developers may not get their cut up front, but they will get their taste eventually. At your expense.

It’s a horrible and unethical practice, but at the same time it’s also easily avoidable if you, the business owner, use good judgement and critical thinking when making purchasing decisions. Ask as many questions about your website as you would if you were buying a car or a house.

If your developer can’t answer your questions in a way that you can understand and in turn explain to someone else, they shouldn’t be your developer.

It’s just that simple.

Ralph M. Rivera
Hi, I'm Ralph! I'm a web developer at Rahvalor Interactive, a creative marketing services company that I founded in 1999 with my wife and business partner Carol Lynn. In January 2012 we created Web.Search.Social as a branded service offering that brings enterprise-level services to small businesses in an affordable way. I'm also founder and CTO of Podcaster's Toolbox, a SaaS platform designed to help podcasters plan, produce and promote their shows. I teach web development at Manhattan College in New York City. Carol Lynn and I are home based near the Jersey shore but we're currently location independent and traveling the country for a year, working and podcasting. I'm also trying to build a flux capacitor, but that's not going as well as the other stuff I do.
Ralph M. Rivera
Ralph M. Rivera