Here at Web-Op we’ve acquired a LOT of domains over the years and consider domains some of our best investments. The market has changed recently though – making exact match domains less valuable. In the past – having an exact match keyword domain was a shortcut to top rankings. Today – those same domains provide seemingly less bang for the buck. This new hurdle hasn’t been unexpected – but that doesn’t make it any less painful to deal with.

Here is Google’s Matt Cutts discussing keyword rich domains:

… and the key takeaway

Some people have complained that we are giving a little too much weight for keywords in domains. So we have been thinking about adjusting that mix a little bit and sort of turning the knob down within the algorithm, so that given two different domains it wouldn’t necessarily help you as much to have a domain name with a bunch of keywords in it.

So what has changed?

A recent patent from Google entitled, “Systems and methods for detecting commercial queries”, may shed some light on the subject. (via seobythesea)

In other situations, a company may attempt to “trick” the search engine into listing the company’s web site more highly. For example, if the search engine gives greater weight in ranking results to words used in the domain name associated with web sites, a company may attempt to trick the search engine into ranking the company’s listing more highly by including desirable search terms in the domain name associated with the company’s listing.

As an example, assume that company A sells laser printers. Company A may attempt to use a domain name that includes the words “laser printers” so that a search engine may rank the company’s listing more highly. As a result, a person searching for laser printers may not be presented with an unbiased set of results.

Unbiased set of results???

Maybe it’s just the SEO in me – but that line stuck out at me. Google seems to believe that marketers leveraging keyword-rich domains for seo value are gaming the system.

Who’s Gaming the System Now?

For the time being this algorithm change has actually LOWERED the barrier to entry for competitors to break through on difficult SERPs. Industrious marketers have already found some easy workarounds using previously unregistered domains. I call the domain buying technique exact match +plus – which translates roughly to use the exact match keyword – plus some bit of useless junk. Here is a SERP for “gout treatment” that exemplifies exact match plus:

Two domains stick out right away:

• gouttreatmentz.com
• gouttreatmentss.com

Remember the pattern – exact match plus some non n-gram letters slapped in.

Here’s another SERP – this time for “cash advance online”. We have to dig in a little deeper to the second page to find exact match plus domains:

Three domains to look at here:

• cashadvanceonlinecudonie.com
• onlinecashadvancelamboto.com
• onlinecashadvancemasecca.com

You will notice all three of them use a random/non-english string.

More examples – “instant cash advance”

• instantcashadvanceholelni.com
• instantcashadvanceglubos.com

Now let’s be clear – I’m not actually advocating jumping on the spam wagon and trying to exploit this technique – as I’m sure it will get slapped down quickly – just pointing out the unintended consequences of this recent algorithm shift. I wonder if the webspam team at Google won’t someday look back on this and say, “bad idea”

There are a few reasons left to buy exact match domains:

• Reduced PPC costs – Searchers generally click more often on ads with keywords highlighted. Google Adword’s embiggens keywords in a searcher’s query – even when those keywords appear in the display url.
  
• Reduced SEO Costs – exact match domains generally cost less to push to the top. There are some caveats here – as some verticals work differently than others
• Lower Bounce Rates – In my personal experience – exact match domains tend to have a slightly lower bounce rate across all traffic types – again this is anecdotal
• Higher Organic CTR – As Google subtly emphasizes matched keywords on both paid and organic search results – exact match domains are likely to still enjoy a modest bump to click through rate in organic listings.

Unfortunately with the high cost of exact match domains – it may make sense to read the tea leaves and focus on building a brand to capture search engine traffic as opposed to shelling out big money for (currently) overpriced domains.

Nobody’s going to discount the growth of mobile. We’ve all got our collections of phones, tablets, and even the occasional netbook. However, a fortune thrown at mobile development will net you no extra revenue if it doesn’t serve a user purpose.

While users on the desktop may be willing to put up with moderately clunky architectures, and sometimes enjoy clever things which achieve more of a branding goal than a direct sale, such extravagances are lost when your hands are cramped around a tiny screen waiting for data to slowly trundle across a 3G (or semi-4G) connection. The medium, in many cases, directs the message.

Is your sales message necessarily long-form? Remember, scrolling is clumsy to the point of awkwardness even on the best smartphones, and NOBODY likes pinching and panning to read a long novel. For example, if you’re trying to show detailed illustrations of spa services and explain the staff’s experience, nobody’s going to sit through it.

A better choice may be to abandon that messaging entirely for mobile users. A quicker hit with a stronger value proposition can work instead– for example, a downloadable coupon.

It’s also important to consider that mobile users may not even be engaging you for a direct buying opportunity. If I open a brick-and-mortar retailer’s mobile site, my likely concern is less about making a purchase online, and more about finding a nearby location. Feel free to remove your shopping cart, return policy, and such, to put that location-finder front and centre.

Maybe you’re not a retailer, so that’s not the obvious answer. In that case, it’s time to reevaluate the reason someone is on your site in a mobile device.

The first likely choice: he’s trying to find your retail partners. The good old “Where to buy” link is vital. However, that can be risky. If your distribution channel isn’t “tight”– knowing not just which distributors you sell to, but even most retailers– you may not have the details on important local vendors, leading the user to give up on your product as unavailable in his neighbourhood.

The manufacturer does, however, tend to have an edge on product information. Frequently, a retailer’s displays are limited to breif summaries of products, and whatever you can read off the box itself. I can recall trying to peck out manufacturers’ websites on a BlackBerry to do feature comparisons in the store– and when I got there, ending up in large, slow-to-load pages which didn’t fit my needs at all. Honestly, if you look at a screenshot like this, you know– if the information you need is even on the page in the first place– you’re going to be pawing all over the screen to try to dig it out. A simple, appropriately scaled product photo and a table of key features, on the other hand, would close the deal your point-of-sale display already opened.

versus
Indeed, this may be a rare truly appropriate use for QR codes– since it clearly ties to a single product’s packaging, a customer could scan and arrive at full details which won’t fit on the back of the box. A further enhancement could even come by tying it to packaging version– using a different code (and thus a different page) for seasonal, region-specific, or bundled products.

People scream blue murder about Amazon using their mobile presence to aid customers in comparison shopping, but customers who are researching their purchases on mobile devices aren’t just doing so to find the lowest price– information matters. Providing those details on a well-thought-out informational mobile site can help your brick-and-mortar partners outcompete Amazon- if the customers can get their questions answered before even seeing the online price, it increases their chance of closing the deal in-store.

Of course, all these paths lead customers to a purchase– even if not directly through your site. There are retailers who have to consider “maybe my product is simply not purchased off a mobile device”, where the value proposition is primarily informational.

Any sort of transportation product fits there– yes, you might be able to build a clunky product to let me buy a bus pass with a credit card number or mobile wallet payment, but I’m probably just wanting to check the time-table.

Other likely “information only” mobile presences include products which could require emergency aid (i. e. treatment if you swallow cleanser) or field service (repairing a damaged automotive component). While it may be depressing to focus on the crisis aspects of your products, being timely and correct may be a great way to earn customer trust.

It should run on any typically configured PHP hosting environment

See it in action at Auto Glass Guru

Get the zip download at our site. A Github repository is now available

Cuba

Problem: You got cut off from the outside world in 1951. People come from far and wide to experience your unique brand of obsolescence. In a way, it’s quaint and cute.

Symptoms: ColdFusion or Perl as significant portions of your application. If you’re using PHP, it won’t run without register_globals or magic_quotes, and no chance at all of working on PHP5. The inability to port your site, without significant modifications, to commodity hosting or cloud services. The overall system may be elegant, but the costs and hassles of finding anyone who can work on it are piling up every year.

Solution: Fundamentally, you have to ask– how much longer do you want to keep patching together those ’47 Packards? A complete rewrite is the best way to pull your site into the 21st century. Then you have to follow it with a policy of engagement with the outside world– regular maintenance and support to ensure it’s easily transitionable to future needs. However, your site probably has plenty of well-thought-out specs and a working environment which can provide reference, so development can be cheaper and easier than a full from-scratch implementation.

Somalia

Problem: Nobody’s in charge, steering your investment, and the environment is too unstable to foster any long-term development. If you’re lucky, you have one or two segments of the site which are almost self-managing and work well. (And you expected a “pirated software” joke here!)

Symptoms: Off the shelf software installed and partially-configured. A typical Somalia website has a WordPress 1.x install with the default theme and three posts you put in shortly after installation, a Zen Cart install that never had its payment processing configured, and a stack of static HTML and flash pages that may not link to either.

Solution: Wipe and start anew. In this situation, there isn’t really much to salvage. If you have a functional unit which does work, you might want to grant the team behind it a bit more autonomy because they’ve clearly got a process which works.

Libya (pre-2011)

Problem: There’s no independent structure– there’s just Colonel Khadaffi.

Symptoms: Your “templating system” consists of calling the one guy in IT who assembles a new page on the fly. At best, this is because of a site which grew out of control, and at worst, it’s a deliberate design decision to ensure you can never replace that “one guy”.

Solution: Stop and scope your project, based on your experience and usage patterns. This is huge, because you can speak from it, rather than just guessing what you’ll need. Odds are, you’re asking for the same task to be done again and again (whether it’s “add a new product to checkout” or “update the calendar”) and those are the tasks which should be automated.

Democratic People’s Republic of Korea

Problem: Juche! Self-Reliance!

Symptoms: You’ve got a mountain of house-made custom software– a home-brew cart, a home-brew blogging system, and a home-brew CMS. It probably runs on a custom web server on a home-built PC too. This means you’re having to reinvent the wheel on every cool feature you see elsewhere.

Solution: Figure out which systems can be replaced by cheap, widely-supported, and maintained off-the-shelf packages. If you need a custom checkout system, fine, but if you’re spending $300,000 keeping developers on hand to replicate the feature set of $300-for-life CS-cart, you’re throwing money out the window.

Zimbabwe

Problem: Everything costs $100 trillion

Symptoms: You’ve “enterprised” the crap out of your site. No free MySQL when Oracle will do. Your hosting costs are more than your site generates in sales, because you’ve got a quad-redundant setup in a military-grade data centre capable of supporting the full wrath of Anonymous and still running smoothly.

Solution: Get over yourself. It makes sense to design to scale, but it also makes sense to wait for the system to pay for itself at the current size before you worry about scaling up. If your site does get that big, you’re going to have to refactor stuff anyway.

Disclaimer: No offense is meant to the people or leadership of these countries; it is rather meant for humourous intent.