Things I Learned Building My Website

Web Design

I needed a dedicated author website (in addition to this blog).  Now, I have a computer engineering degree, but I learned HTML in the mid 90's when there was no such thing as cascading style sheets and we used Notepad to code our pages from scratch. The old search engines of the time (like Altavista or Yahoo) used header meta tags to learn your website's keywords and description and decide whether your site related to a particular user's search... but then Google came along, revolutionized web searching, and became the undisputed king of the castle ever since.  So while I was pretty sure I still knew all the basics involved with making a website, there were quite a few things I had to learn in order to appease the almighty Google-God of the interwebs.

Until recently, the main factor that drove your ranking in a Google search was the number of websites that linked back to your web address. Essentially Google let the masses determine the relevance of any given page.  If enough websites referenced your site as something worth their readers' time, then Google took that as a validation of your content and considered your site as having some degree of authority, giving you a higher ranking as a result.

But on 21 April 2016, Google make some rather important changes to their search algorithms, giving greater preference to sites that it considered to be "mobile friendly" (or able to be easily navigated and viewed on a mobile device, like a phone or tablet). Meta as it seems, (and I mean that in the Deadpool kind of way, as opposed to the HTML-tag kind of way), I've clocked countless hours devouring the search results on Google to learn how to influence the search results on Google. Some aspects of it were easy, but I admit some of it made me want to smash my head into the keyboard. Repeatedly.

So in the hopes of saving someone else some grief, I thought I'd write up the key things that I learned along the way as I got my website up and running (and acceptable to Google's standards).

NOTE: If you use something like WordPress, or some other point-and-click service provider to create your site, then some of this will likely be handled behind the scenes for you. For me, the reason I went with a custom built site, was the flexibility.  Some of the details below will only apply to those of us foolhardy enough to code from scratch, but other points will apply all around.

HTML Validator - HTML the language has evolved over the years and I really wasn't sure that I understood all the best practices for HTML 5 nowadays. https://validator.w3.org is a website that will parse through your code and spit out a list of any/all coding errors that it finds. Just because the browser you use for your testing is smart enough to display your website properly, doesn't mean that your coding is error free. It just means that your browser was smart enough to figure it out, despite your coding errors and Google may well rank your page lower in its algorithms if your page is buggy. It's far better to ensure that your code is clear and error-free. For the various errors that appeared, I was generally able to find out how to fix them by googling the error messages, or just reading the description that the tool provided.

Google Analytics - Google has a list of developer tools that allow you to test and monitor your websites. Google Analytics provides you with reports on the number of users that have accessed the various pages on your site, how long they browsed for, where they are connecting from, what browser they used, etc.  After you've created a Google Analytics account, then you have to associate your account with any websites you administer.  

Here is the how-to page for adding a website to your account: https://support.google.com/analytics/answer/1042508?hl=en

This page describes the ways you can verify the ownership of your websites with Google: https://support.google.com/webmasters/answer/35179?hl=en.  

And this reference page describes how to add a snippet of code to each of the web pages on your site that you want detailed statistics on: https://developers.google.com/analytics/devguides/collection/analyticsjs/.

Google Search Console - This site lets you see in more detail how Google's web crawlers view your page.  Again you add your sites as properties in the console (https://support.google.com/webmasters/answer/34592?hl=en), then click through the various resources to see if Google spots any issues with your site, what keywords it's picked out of your site based on its content, etc. Make sure you check out the Messages that you'll see highlighted at the top of the links on the left of the console as they will give you pointers on how to improve your search presence.

Here are some of the key areas of interest in the console:

Upload a Google Sitemap - A sitemap is the file that Google reads to ensure that it understands the hierarchy of pages on your site (ie: which is the main page vs which are subpages, etc) and what frequency you expect the contents of those pages to be updated (and therefore, how often Google should consider sending its web crawlers your way). Sitemaps can be in a variety of formats and you can write them from scratch in a program like Notepad, but it's often easiest to at least start off by using a site like https://www.xml-sitemaps.com to generate your first map for you. You download the resulting xml file, upload it to the root of your website, and then use the Search Console (Crawl > Sitemaps) to tell Google where to find the file on your site.

Fetch As Google - This option is also located under the Crawl group of tools. It allows you to see your website as Google sees it and you can use the tool to toggle between a Desktop view of your site and a Mobile view. If you choose the "Fetch and Render" option on the console, it will show you an image of how Google is interpreting your site in each of the formats.  This link gives a great overview of this tool: https://support.google.com/webmasters/answer/6066468?hl=en.

Mobile Friendly Check - This tool takes things a step further than the Fetch as Google tool.  You enter your various web pages and the site will rate the pages in terms of how efficiently it renders on mobile (and desktop) devices. It will actually give you a numerical rating. For me, when I put my new website (ALeeRipley.com) into the tool, I got a pass on the desktop side of things but a failure on the mobile friendliness. Soon thereafter, I noticed that when I Googled myself to test where my page came back in the search results, a terrifying error ("Your page is not mobile friendly.") appearing under my site URL! NOTE: this warning will only appear for you... no one else will see it.  But as mentioned above, your overall ranking if the search results (particularly when viewed from a mobile device) will be affected.  

It doesn't take much to "fail" Google's assessment. It's looking at the size of the files that you are using on your site, how efficiently you've coded things, whether your site renders differently for phones vs desktops (to better fit the screen size), etc. Each site will have its own areas of concern (or not) but here is a list of what needed to be addressed on my end - and I started with a site that was initially coded with only desktop viewing and sizing in mind:

Enabling caching for your site - This took me the longest to figure out. All the sites I went to online gave loads of complex details but none of them seemed to actually explain (from ground zero) how to do this.  Caching is when devices keep re-using the last version of a particular file instead of re-downloading it each time. It's far faster for browsers to ask your web server for the date a file was last updated (to confirm it still has the latest version) as opposed to downloading the whole file again and again. To set this up, you use a special file (.htaccess) that sits at the root of your site. It's like a configuration file for your site. This file may already exist on your site, if you've customized some other aspect of the way your site functions, or the file may not exist yet if your site only uses standard configuration settings. For me, the file did not exist. Eventually, I figured out that I needed to simply upload this file to my site, rename it .htaccess (with no file extension), and then my caching woes were corrected.

NOTE: I've left a copy of the same file titled htaccess.txt on my site so that you can see the contents for yourself and use this for your site if needed. The link earlier in this para will open that particular text file copy.

ViewPort Meta Tag - There is one meta tag in particular that I had to add to each of my web pages' header areas: <meta name="viewport" content="width=device-width, initial-scale=1.0"> This was something that the Mobile Friendly Assessment results were directly telling me do to and I didn't question it.  Here is a useful link on this subject if you want to delve in deeper as to the "why": http://www.w3schools.com/css/css_rwd_viewport.asp

NOTE: I also still have the description, keywords, and author meta tags in there as well. I have no idea if Google bothers to read them at all (I know they devise their own keywords for your site based on its actual contents) but it's possible that some of the lesser search engines still use them.

@media Tags in CSS - I won't go into any tutorials on the use of cascading style sheets (CSS) on this post (this entry is already long enough) but essentially your web pages should be set up to have their content separated from the file that tells the browsers (on various devices) how to render that content. Given that desktop monitors are dramatically larger than phone screens, in order to be mobile friendly you have to move things around and simplify things when users are accessing your site from a phone.  You can do this by having a section in your CSS file where you redefine some of your styling to better fit a phone's screen. For me, this meant sticking to one column of content in the phone version of my page (instead of having multiple columns of content across the page), resizing the width of the content and images to be width=100% instead of a set pixel size, and hiding some elements that would otherwise clutter up the screen). To do this, I used @media only screen and (max-device-width: 480px) { }  

For example (taken from my CSS file):  

.div-content {
   width: 570px;
   float: left;
   padding-left: 50px;
   padding-right: 25px;

.nav-text {
   display: inline;

@media only screen and (max-device-width: 480px) { 

  .div-content {
     width: 100%;
     margin-right: auto;
     margin-left: 5%;
     padding-left: 0px;
     padding-right: 0px;

  .nav-text {
     display: none;


In the code above, a browser would use the second set of styling instructions to overwrite the properties specified in the earlier styling, when rendering a page on a device with a screen width of less than 480 pixels (ie: a mobile phone).  Overall, in laying out your page on a phone, you want to avoid folks having to scroll from side to side and you want the text to be large enough to be easily read.

Streamlined CSS, removing duplication - With all the extra styling needed for handling small screens, the CSS files grow fairly large, and given that a number of pages generally share the same styling sheet (to maintain a common look and feel across your site) this can become a problem.  I had to go through my CSS file, remove any redundant or unneeded property specifications and group all my @media specification into one grouping (as opposed to using that handle repeatedly for each different tag).

Links too close together - If you have more than one link spaced too closely together on a page (for example one link under the other within a paragraph) then it can be difficult for a viewer to select a link in particular (using stubby fingers on a small screen).  Google will dock points from you if your links aren't spaced far enough apart.  

Gzip CSS and TTF files - My site uses a custom font for some of the titles and the True Type Font file was considered large by Google's standards.  Similarly, my CSS file was still rather large even after streamlining it as best as I could.  The fix was in compressing the two files.  Apparently (news to me!) modern browsers know how to unzip things on the fly!  So you can use Gzip to compress certain files, upload them to your website (removing the uncompressed versions and updating any references to the files to include the ".gz" extension) and your site will continue to work properly. Google will tell you what files to consider compressing.

That was it!  Once I had all that accomplished, I re-ran the Mobile Friendly Check and I passed!  I then passed out from exhaustion from the all-nighter I'd just pulled.  It still took a few days for the "Your page is not mobile friendly." warning to disappear from the search results (and I used the Google Search Console to request that Google re-crawl my site to update its records), but all is well now.  

So, after all that effort, will folks find me when they Google my name?  Well, given that my first initial looks more like the indirect article ("a") instead of a part of my name, I'm still having some issues.  Someone by the name of "Lee Ripley" still rules the roost in terms of the search results.  But I am in fact on the first page now: #5 in the returns for my Twitter handle and #8 for my actual web page.  Considering that the only external links to my site are from my Facebook profile, my Twitter account, and this blog site, I take that as a success.  I'll still need to try and find ways to get a few more back-links to my author site to bring it higher in the listings, but this is still a respectable start in my mind.

Feel free to check out the site itself (ALeeRipley.com)!  It's still a work in progress but I think it's coming along.  And if I have anything misunderstood (or unclear) in this particular post, or if you have a question on how I did something in regards to any of the points above, feel free to leave me a comment!  

Happy web building!

you can hide a dead body on the 2nd page of Google search results

[dragonfly image in header taken from 6iee.com, collage of web-related words in header taken from axaptacentral.com, and sunset "www" image used as background in the image above taken from wix.com]



Used tags: , ,

No Responses to "Things I Learned Building My Website"

(optional field)
(optional field)
This is a quick question to make sure you're not a spambot. :)
Remember personal info?
Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.