Website Development Guidelines

Guidelines For Website/CMS Development
Created By : Amit Kute (Quality Analyst)

1. Page Title & Favicon
2. Navigability
3. Accessibility
4. Conventionality
5. Basic Code Structure
6. SEO standards for Front-End Coders
7. SEO standards for Back-End Coders
8. CMS Features that help with SEO
9. Consistency
10. HOW TO IMPROVE PAGE LOAD TIME
11. Keywords in URLs
12. Mailto Link
13. Summary of All points
Index

Page Title and Favicon Should present on page
For Ex.: Domain Name- Page Title or Page title only
Page Title & Favicon

 Keep the structure of your primary navigation simple (and near the top of your page).
 Include navigation in the footer of your site.
 Use breadcrumbs on every page (except for the homepage) so people are aware of their navigation trail.
 Include a search box near the top of your site so visitors can search by keywords.
 Don't offer too many navigation options on a page.
 Don't dig too deep. In most cases, it’s best to keep your navigation to no more than three levels deep. (Check
out this article for more clarity around flat vs. deep navs.)
 Include links within your page copy, and make it clear where those links lead to.
 Another pointer: Once you've settled on what your site's main (top) navigation will be, keep it consistent. The
labels and location of your navigation should remain the same on each and every page of your site
Navigability

Accessibility

Conventionality
There are certain web design conventions which, over the years, internet users have become increasingly
familiar with. Such conventions include:
 Having the main navigation be at the top (or left side) of a page
 Having a logo at the top left (or center) of a page
 Having that logo be clickable so it always brings a visitor back to the homepage
 Having links change color/appearance when you hover over them

Add Basic Code Structure

To make it easy for front-end coders and back-end developers to have a list of items to consider when doing their part of the website building
process, I've made a list of standards to go by:
•Usage of H tags and other style elements
Limit the usage of H tags (H1, H2, H3, etc) and <strong> tags to non-repetitive content. That means don’t use these HTML tags on site-wide
headings, sidebars, footers, or anything that is repeated across the website or multiple pages. Instead, use a regular div. Reserve these tags for
unique content on every page.
•Fonts
As much as possible, use machine-readable fonts. An alternative is to use font-replacement such as @font-face. As a last resort, use an image to
display text. Place the image in an image tag (rather than using CSS) with alt text that repeats what is written in the image, word-for-word.
•Images
For images that are stylistic elements, using CSS background images is fine, but for content elements, found within a body of text that is unique to a
page, use a regular image tag. For logos, use an image tag rather than using text replacement, as seen here. http://css-tricks.com/rethinking-css-
image-replacement/ (see “The New Way”). Alt tags should contain the words seen in the image.
•Site speed
A web page should not take more than 3 seconds to load on a 10Mb connection. The front-end coder is not responsible for the entirety of what
makes a page fast or slow, but they do have a role to play. That means consolidating CSS and javascript files, loading javascript at the end of the
page, creating sprites and seeking other size-cutting opportunities.
•Making content readable
Search engines have trouble reading content that is within <script> tags or that loads dynamically (such as AJAX). Anything that does not come
loaded as the page loads will most likely not get picked up by search engines. Do not use dynamically loading content unless it is explicitly stated in
the website specification document.
SEO standards for Front-End Coders

Canonicalization
A canonical URL is the version of any given web page’s URL that we want indexed by search engines. Canonicalization is the process by which we
achieve that result. Every page on a website should only be accessible from one URL. Additional URL parameters can be added, if handled using
techniques described here.
•Dealing with www and index pages.
By default, all of the following URLs should redirect to www.example.com
example.com
example.com/index.(.*)
www.example.com/index.(.*)
There may be cases where a website owner prefers to use the non-www version or a subdomain as their root domain. That is fine as long as all
other versions redirect to that chosen version.
•Dealing with trailing slashes
URLs may have a trailing slash “/” at the end. Sometimes they do not. The server should always redirect to one or the other. Ideally, the version with
the slash is preferred.
Example:
www.example.com/blue-widget should 301 redirect to www.example.com/blue-widget/
Note that this is not an issue with root URLs, such as www.example.com. A slash will never appear at the end of that URL.
•Canonicalizing subpages
A product page on an e-commerce website that is accessible at 3 different URLs is not a good idea. The example demonstrates a problem stemming
from the CMS architecture. Ideally, there should only be one URL.
/product/reebok-black-crossfit-shoe/ET256/
/shoes/product/reebok-black-crossfit-shoe/ET256/
/shoes/fitness/product/reebok-black-crossfit-shoe/ET256/
SEO standards for Back-End Coders

In this case, where categories and subcategories appear to be constantly changing, the best URL to use is /product/reebok-black-crossfit-
shoe/ET256/. No other URLs should open this page. It’s okay to add parameters to the URL. For example, the existence of the following URLs
is okay if the canonical link tag is used.
/product/reebok-black-crossfit-shoe/ET256/
/product/reebok-black-crossfit-shoe/ET256/?cat=shoes
/product/reebok-black-crossfit-shoe/ET256/?cat=shoes&subcat=fitness
For each of the URLs above, what’s called the canonical link tag should be added to the <head> section of the page. The purpose of the
canonical link tag is to tell search engines which version of a URL to index. As mentioned earlier, the version of the URL that we want to index
is /product/reebok-black-crossfit-shoe/ET256/. In this case, the canonical link tag should look like this on all 3 of the above URLs:
<link href="http://www.example.com/product/reebok-black-crossfit-shoe/ET256/" rel="canonical" >
Side note: for tracking purposes, marketers need to add additional parameters to a URL. Those parameters should not be overridden and they
should not cause the page to give a 404 error.

CMS Features that help with SEO
Since most websites use some sort of content management system, it means that the SEO specialist will need to rely on the CMS to help them modify
website content to reach their objectives. Here are CMS capabilities that help with SEO:
•Ability to modify title tags and key meta data on all pages. That means the content that goes into the following areas:
<title>{CONTENT}</title>
(by default, use this: {Page Name} | {Company Name})
<meta name="description" content="{CONTENT}" >
(by default, leave this empty)
<meta name="robots" content="{CONTENT}" >
(by default, use index,follow)
<link href="{CONTENT}" rel="canonical" >
(by default, match the URL of the page. So if the URL of the page is http://www.example.com/product/reebok-black-crossfit-shoe/ET256/ then the
canonical link tag should look like: <link href="http://www.example.com/product/reebok-black-crossfit-shoe/ET256/ " rel="canonical" >
CMS Features that help with SEO

•Updating of the sitemap.xml file:
The CMS should be able to generate a sitemap.xml file and place it in the root folder of the website (www.example.com/sitemap.xml). It should contain all
main pages of the website and auto-update when new pages are added or some are removed. This is the format to follow:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>http://www.example.com/</loc>
<lastmod>2005-01-01</lastmod>
</url>
</urlset>
When a website contains multiple sections, for example a WordPress-controlled blog, and some other self-contained sections, it may be easier to generate a
separate sitemap for each section. These can be linked to using a sitemap index file, as seen in this
example: https://www.bluefountainmedia.com/sitemap.xml
•Updating of the robots.txt file
The robots.txt file controls where search engine crawlers are allowed to go. This file should be editable via the CMS. Magneto has a list of subdirectories that
should be disallowed by default that should be included from the start.
•Editable page sections
Although it is not an SEO requirement, it is beneficial for tracking purposes to be able to edit various parts of all web pages on the website. These include:
Immediately after the opening <head> tag.
Immediately before the closing </head> tag.
Immediately after the opening <body> tag.
Immediately before the closing </body> tag.
There are various tracking scripts that help in obtaining information about user behavior that need to be added to any of these areas. There should be a way
to add a tag to all pages as well as each page individually.

•Image uploads
When images are uploaded via the CMS, file names should be editable rather than being rewritten to a random string by the CMS. Image titles and alt
tags should be editable (they usually are in most content management systems).
•Page speed
To optimize page load time, various back-end load time cutting techniques should be employed, a long list of which can be found
here: http://gtmetrix.com/recommendations.html. Pages should not take more than 3 seconds to load.
•404 configuration
When a random URL is accessed, the server should return a 404 response - not a 302, 200 or any other.

In addition to keeping your sites navigation consistent, the overall look and feel throughout your website pages should be consistent. These include
elements such as background, color scheme and even the font type and size. These are the general areas where consistency can have a positive impact
on your usability and UX.
Consistency

HOW TO IMPROVE PAGE LOAD TIME
There are many ways to improve this metric, but here are some of the most common:
File Compression: Reduces the size of the CSS, HTML, JavaScript, images, and other web elements. (Check out ImageOptim for Mac to compress images).
Magnification: Optimizes the code by removing unused code, white spaces, comments, etc. (Here are some cool tips/tools you can use to minify JavaScript
and CSS.)
Reducing redirects: Each time a web page redirects the browser to another server, the user faces an additional time for the request-response cycle to
complete. Best to get rid of these if possible.
CDN: A content delivery network (CDN) puts content geographically closer to your users so they can receive it quicker.
HOW TO IMPROVE PAGE LOAD TIME

It's still the case that using the keywords you're targeting for rankings in your URLs is a solid idea. This is true for several reasons.
First, keywords in the URL help indicate to those who see your URL on social media, in an email, or as they hover on a link to click that they're getting
what they want and expect, as shown in the Metafilter example below (note how hovering on the link shows the URL in the bottom-left-hand corner):
Keywords in URLs: still a good thing

Second, URLs get copied and pasted regularly, and when
there's no anchor text used in a link, the URL itself serves
as that anchor text (which is still a powerful input for
rankings), e.g.:
Third, and finally, keywords in the URL show up in search
results, and research has shown that the URL is one of the
most prominent elements searchers consider when selecting
which site to click.
CreatedBy:AmitKute(QualityAnalyst)

Shorter > longer
Shorter URLs are, generally speaking, preferable. You don't need to take this to the extreme, and if your URL is already less than 50-60 characters, don't
worry about it at all. But if you have URLs pushing 100+ characters, there's probably an opportunity to rewrite them and gain value.
This isn't a direct problem with Google or Bing—the search engines can process long URLs without much trouble. The issue, instead, lies with usability
and user experience. Shorter URLs are easier to parse, to copy and paste, to share on social media, and to embed, and while these might all add up to
only a fractional improvement in sharing or amplification, every tweet, like, share, pin, email, and link matters (either directly or, often, indirectly).

This doesn't mean that if the title of your piece is "My Favorite 7 Bottles of Islay
Whisky (and how one of them cost me my entire Lego collection)" that your URL has
to be a perfect match. Something like
randswhisky.com/my-favorite-7-islay-whiskies would be just fine. So, too would
randswhisky.com/blog/favorite-7-bottles-islay-whisky
or variations on these. The matching accomplishes a mostly human-centric goal, i.e.
to imbue an excellent sense of what the web user will find on the page through the
URL and then to deliver on that expectation with the headline/title.
It's for this same reason that we strongly recommend keeping the page title (which
engines display prominently on their search results pages) and the visible headline on
the page a close match as well—one creates an expectation, and the other delivers
on it
For example, above, you'll see two URLs I shared on Facebook. In the first, it's
wholly unclear what you might find on the page. It's in the news section the BBC's
website, but beyond that, there's no way to know what you might find there. In
the second, however, Pacific Standard magazine has made it easy for the URL to
give insight into the article's content, and then the title of the piece delivers:
Match URLs to titles most of the time (when it makes sense)

The hash (or URL fragment identifier) has historically been a way to send a visitor to a specific location on a given page
(e.g. Moz's blog posts use the hash to navigate you to a particular comment, like this one from my wife). Hashes can
also be used like tracking parameters (e.g. randswhisky.com/lagavulin#src=twitter). Using URL hashes for something
other than these, such as showing unique content than what's available on the page without the hash or wholly
separate pages is generally a bad idea.
There are exceptions, like those Google enables for developers seeking to use the hashbang format for dynamic AJAX
applications, but even these aren't nearly as clean, visitor-friendly, or simple from an SEO perspective as statically
rewritten URLs. Sites from Amazon to Twitter have found tremendous benefit in simplifying their previously complex
and hash/hashbang-employing URLs. If you can avoid it, do.
Avoid hashes in URLs that create separate/unique content

CreatedBy:AmitKute(QualityAnalyst)

Website Development Guidelines

More Related Content

What's hot (17)

Similar to Website Development Guidelines (20)

Recently uploaded (20)

Website Development Guidelines