SEO Cheat Sheet for Web Developers

31 Jan
January 31, 2019

Onsite and offsite search ranking results. Google patent 8,843,477 B1
US Patent No. 8,843,477 B1 Google

Note from SEO team:
This morning, our CEO just noticed that one of our web developers had a cheat sheet on his desk for search engine optimization written last week by the FabCom SEO team. He skimmed through it and told us to redact any references to our clients, and then post it on the blog for the benefit of the world. The cheat sheet isn’t Bible, however, but we treat each action item as a Useful Working SEO Generalization for web developers and even web designers. Useful Working Generalizations, or UWGs, is a term coined by the late Harvard Business School professor Martin Marshall in his OPM course taught between 1984 and 1988.

UWGs are “not principles,” according to Marshall, “but are generalizations subject to some if not many exceptions. They are regarded as ‘working’ because marketing is a dynamic subject, and what seems to be a good generalization at one period in time becomes suspect in another period.” With that disclaimer out of the way, as of January 2019, these are the SEO rules for our web developers.


Introduction to SEO for Devs

Search engine algorithms concurrently calculate considering several hundred constantly changing signals when assigning rank to domain properties and their individual internal webpages. In order to narrow the cone of uncertainty, each webpage is assigned a rank, and each domain is assigned a rank, then the two are combined and assigned an onsite score. Finally, an external global score is combined with the internal onsite score to achieve what is hoped to be the right page at the right time for every query.

Here is a diagram from a 2014 Google patent for the actual procedure:

google patent

US Patent No. 8,843,477 B1 Google
Download the full patent here

With such awareness of how the system works, it follows that a domain’s combined global and onsite ranking can be improved or optimized by improving some or all factors that influence top rankings for a trending query. Here are some useful working generalizations that affect the organic rank of our client web properties, as well as internal TTPs that facilitate and scale their execution.

SEO Ranking Signals

Some signals are explicitly known to influence onsite rank, and subsequently the global rank:

  1. User signals such as Click-through rate (CTR), (and possibly session duration, pages per session, link shares, search history, and location).
  2. Page Speed
  3. Page Reliability (also known as Page Trust)
  4. Domain Reliability (also known as Domain Trust)
  5. Domain Authority (Trusted industry expertise)

These five signals have something in common…

They are all affected by the consistency or inconsistency of URLs, which brings us to…

URL Consistency

  • Only use hyphens to separate words. Never use underscores.
  • Only use lowercase letters.
  • Use a subdirectory whenever possible over a subdomain.
  • Omit articles a/an/the whenever possible.
  • Never use a trailing slash.
  • All internal links should be relative links (omit the with a base ref tag antecedent in the header. This combination is the preferred option because it enables slightly faster pagespeed and UX, makes the switch from dev to live environment seamless, and is more impervious to scraping.
  • Every page must include a canonical link in the header:
    • Preferred Page Canonical if the page is a duplicate of a preferred version.
    • Self-canonical if the page is the preferred version.
  • All external links should include HTTPS as it is always safe to request HTTPS assets even if the external domain is HTTP.


Google increases rank for fast pages and decreases rank for slow pages. We talk about converging technology all the time, but here is where we all must work together to make fast pages happen

  • Designers: If something looks good, but the devs can’t find a way to make it load quickly, omit it from the design because few will ever see it anyway when it is deindexed.
  • Developers: If designers provide you with an element, do your best to find a way to implement it. If you can’t, let the designer know to use an alternative method of conveying the info.
  • Client Services: Don’t let clients force anything that slows a page, especially on mobile. Right now, we don’t even know how many people abandon some client pages because tracking code often fails to load before abandons occur. However, we try to implement pretty accurate new testing every chance we get to catch the true abandonment rate by device and location.
  • SEO/Analytics Team: Provide monthly analytics reports that shows pagespeed winners to emulate and losers ripe for optimization.

In addition to all the recommendations found here, here are some strong suggestions for designing and building a page that loads quickly:

  • If the page is informational in purpose, create an AMP version.
  • Keep server calls under 100.
  • Images:
    • If there is any way to use CSS instead of an image to convey the message, do that instead.
    • Try to keep images ≤100K. Sometimes this isn’t possible. At least make sure that those bigger images are served from a CDN.
    • Always make sure every image is progressive-scan. This means that designers must save it in Photoshop as “Progressive Scan” instead of interlaced before the devs ever get ahold of it.
  • Prioritize use of Google Webfonts within reason. There are 848 font families and counting. There is no reason that , for example, still flashes a degraded font before the main one loads. Consult this site for more font advice.
  • Get rid of any libraries that are not in use.
  • Read and understand this awesome post from Google’s Dev Team. You will find your own recommendations for pagespeed optimization that is a little out of my league but good for devs.

Structured Data Markup

Learn the basics of structured data

  1. First read this guest post covering basic Schema markup over on the Rush blog.
  2. Then a little more advanced would be this other guest post covering markup to achieve featured snippets.

Structured Data for search engines

Whenever we or our clients post content on social networks, each network will scrape whatever it can from the HTML of the page and we have little control over this experience. However, deploying open graph protocol markup enables much more control over the user experience within almost any social network.

A subtopic of structured data markup is open graph protocol for social networks. As far as FabCom and our clients are concerned, here’s how the world of structured data is classified. We should ideally leverage the preferred taxonomy currently on every page of all client sites whenever possible, but Dublin Core is listed here for reference since it goes beyond web taxonomy:

Structured Data for social networks

Open Graph Protocol

Most social networks ingest structured data from socially shared links, then display the data in a pretty format to retain user engagement. The Open Graph Protocol “enables any web page to become a rich object in a social graph. For instance, this is used on Facebook to allow any web page to have the same functionality as any other object on Facebook.” They are essentially “stealing” user-generated content to keep users on their site longer, but we play the game because usually the rising tide floats all boats.

Open Graph Protocol is nice and simple, but some of the social networks depend on their own additional structured data lexicon, so for the moment we must pay homage to them to keep our clients in the game:

When implementing social network structured data, validate your work using their respective validation and debugging tools:

If a client is running the Expression Engine CMS, you can use these plugins if it makes sense. Caveat emptor.

Structured data for email

We recommend wielding Schema for client emails, but y’all need to master the structured data concept (especially in JSON) before attacking email. Here is the testing portal for emails.

Implementing Structured Data Markup

Each page should include structured data markup as a standard on all new pages we launch, and ideally for all previous pages as time allows. If a clients sells actual tangible products, we should additionally plan to implement additional ecommerce-heavy entity markup across their site.


Block Indexing via Noindex tag vs. Robots.txt

Don’t worry about messing with the robots.txt file. That is whole different world we use if we need to allocate crawl budget. In lieu of editing the robots.txt file, always include a noindex tag on webpages that should not appear in SERPs. Here’s what the noindex tag looks like.

<meta name="robots" content="noindex">

These types of pages should include the noindex tag:

  • PURLs
  • Thank-you pages
  • Paginated pages
  • Search results pages

We want to say to Googlebot, “Here, crawl all our pages if you want, but these particular pages won’t do your users any favors.” If we find that Googlebot wastes resources repeatedly crawling these pages, we will request updating the attribute to nofollow.

Filenaming Conventions:

Filenames often end up as part of a URL. Keywords in URLs is its own little ranking signal, but few designers and even fewer devs carefully write them. Stop the madness and name your files according to this template:

[ClientAcronym]-[Theme/Topic/Campaign Name]-[Subtopic/Task/What Is It?/Dimensions/Unique colors or characteristics]-[ISO date]

ABC-Analytics-Measurement Model-20190104

Measuring SEO and CRO Impact on Client Business Bottom Line

All this work making things better, but what difference does it make? Over on the Fablytics team, we collect all the resulting data, analyze it, report on the Five Ws (Who, What, Where, When, Why), prescribe solutions, and predict what will happen if the client greenlights our recommendations. We call it User Behavior Tracking & Performance Analytics.

Testing Interactive Form Submit Events

In an iterative environment culture, things are constantly improving. Naturally, we must regularly test the user experience in the live environment. To prevent corrupt data by submitting live test forms online for any client, it would be very helpful if you:

  1. Use your work email address, because Yoni has set these up so that our test submission notifications won’t be delivered to clients. Instead, internal test email notifications will be sent to
  2. The first and last name fields should include the word “TEST” so that we can filter records in realtime out of the live dashboards that clients see in ROIconsole, and not trigger conversions in client analytics reporting.

AJAX Event Naming Conventions

Speaking of test form submission events, adhering to strict AJAX event naming conventions helps us consistently measure our SEO and Conversion Rate Optimization (CRO) efforts.

  • clientAcronym-productName-actionType-actionName(-subName as needed)
  • Naming Examples:
    • -Form-FastApp
    • -Form-Application
    • -Form-RFI Header
    • -Form-PDF-
    • -Form-PDF-
    • -Email-{{Published Name}}
    • -Phone-{{Published Name}}
    • -Form-Configurator
    • -Form-Visualizer
    • -General-Form-RFI
    • -General-Form-Contact Rep
    • -General-Form-Tour
    • -General-Form-Newsletter
  • Event Code Examples:
    • On this page:
      • The download gate form should contain this event:
  • dataLayer.push({‘event’ : ‘formSubmitted’, ‘formName’ : ‘ ‘});
    • On this page:
      • The download gate form should contain this event:
  • dataLayer.push({‘event’ : ‘formSubmitted’, ‘formName’ : ‘ ‘});
©2019 Fabiano Communications.