— August 8, 2018
If you own a business, you know a lot about that business. You also have a website. You probably know less about how websites are constructed. Do you need to know? Yes – certainly enough in order to manage your vendors and keep them from ripping you off.
Because I find that business owners can be confused about the basics, I thought I’d write a Website Tech 101 article to document how it really works.
Website Tech 101: The basic elements
Sites consist of:
- Site tech platforms
- The code that creates the site
- The content in the site
We’ll go through these one at a time.
As you know, every site has its own URL, which stands for Universal Resource Locator. It’s really a number, like 168.54.324.12, but that’s not good for humans, so it gets translated into your domain name, like zhivagopartners.com. You buy your domain from a vendor like GoDaddy, for a year or multiple years.
You’re probably pretty familiar with this process, but make sure you own your domain – if one of your vendors has bought it for you, make sure you get possession of it. You should be able to log into whoever has sold you your domain and renew it as needed.
If your vendor purchased your domain on your behalf and it resides in their registrar master account, you should have the domain transferred to your own account as soon as possible. Domain transfers are cumbersome but very important to allow you to control your own domain name at all times.
Obviously, this is important.
Now that you have your domain, you need to “point” it, or direct it, to the host computer that will contain your website. The code and content of your site resides on a server somewhere. A server is really just a souped-up computer devoted to and connected to the Internet. The company that owns the server that your site sits on is the host.
Sometimes we find people confuse domains and hosts. They are not the same. You need to know exactly where your site is hosted, and how to access your site. If your website were a person, the domain name would be that person’s name, and the host would be their skeleton and muscular system.
The host, too, is really important. You should also make sure your site content is regularly backed up somewhere, somewhere other than the host’s servers, just in case something bad happens to your site hosting company, such as going out of business. “It” happens. Don’t let it happen to you.
Site tech platforms
Sites are built with tools – HTML, languages, and platforms. HTML – which stands for Hypertext Markup Language – is primarily a “tagging” language. HTML tells a web browser how to display things – basically translating code into a logical presentation. At its most basic, if you want some text to be bold, you put a <strong> before that text and a </strong> after it; all browsers will recognize that tag, or command, and display that text as bold.
It gets more complicated if you want to apply certain stylistic attributes to your whole site. In other words, you want all your paragraph text to be Arial 13 point, and all your headlines to be Arial, brown, bold, and 24-point type. For this, developers tend to use CSS, which stands for Cascading Style Sheets. CSS is largely responsible for the “look and feel” of your site, and if text and other elements of your site are not displaying properly, but in a somewhat universally broken way, this is usually a problem with the CSS code on the site.
It gets complicated further still if you want to build in certain interactive or animated aspects, such as forms that visitors can fill out, things they can download, and tools they can use, say, to determine the price of a mortgage. And, of course, e-commerce functions.
One of the most common platforms for building a site is WordPress, a content management system that currently has about 60% of the market, according to W3Techs. WordPress started out as a “build your blog” platform but has morphed into one of the most common ways to build a site.
There are a lot of templates and plug-ins for WordPress now, which has strengthened its popularity. As I mention in our previous article, there are pros and cons to using templates and plug-ins, but they have definitely made it easier to get functionality built into a site without having to resort to custom programming.
When it comes to e-commerce, WordPress does have an e-commerce plug-in, called WooCommerce. According to Barn2Media, using BuiltWith.com as their source, WooCommerce has about 41% of the market, and is “8 times more popular than Magento or Shopify.” However, if you just look at WordPress e-commerce platforms alone, it accounts for 94% of that market.
If you own a store, and you are not wedded to WordPress, you have other choices. Shopify, for example, which, according to a 2017 study by Aheadworks, has 13% of the market, is a self-contained environment (the platform includes hosting) with a lot of templates and plug-ins.
Custom code for sites
Templates and plug-ins are convenient and time-saving, but sometimes you just need a functionality for which there is no pre-built code. This is where custom programming comes in.
Personally, we tend to avoid this as much as we can, because every programmer programs differently; and some are better than others. Having a lot of custom code on your site makes things difficult if you have to leave one developer and start working with another.
The new developer will always tell you, “Oh, this wasn’t done well; he should have done it this way.” Or worse, “This is really convoluted code and we are going to have to rewrite it.” If you are going to have your developer write some custom functionality for you, it’s imperative to tell them to document their process and leave comments in the code (invisible notes to subsequent developers) so that if you move on, your custom code is clean, well-documented, and transferable.
Content for the site
Now we come to the part we are all most familiar with: the content. Content, obviously, consists of words, graphics, clickable links/items, and “CTAs” (calls to action – such as a “download” or “submit” button).
As I also mentioned in our previous blog post, you should be able to make basic changes to your own content – text and pictures – without having to beg your developer to make those changes every time. Obviously more complex things, such as building a call to action, creating a menu, or changing how something is displayed, will probably be best left to your developers.
OK, now you know the basics and can more effectively manage your own site and vendors.
Disclaimer: We have no financial or vested interest in any of the technologies or platforms mentioned in this article; we stay agnostic on purpose. We do have experience with what we mention here, of course, and continue to learn and deploy what works best for each company’s situation.