SEO Cheat Sheet for 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 (#AlliterationFTW). In order to narrow a search bot’s 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:

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 if you don’t have to. There’s plenty of argument surrounding trailing slashes because they indeed signal whether a URL is a file or a folder, but non-trailing slash links look prettier, increase sharing, and are much easier to copy/paste when using word selection (Option+Command+ArrowKey on a Mac).
 
• Whenever possible, use absolute URLs (https://www.example.com) instead of relative links (/page-path/next-page-path). It’s not that absolute links are the fastest option; it’s that absolute links are more reliable and pattern-friendly than relative links because there’s less chance of human error causing the domino effect of broken links when trying to keep relative links + base tags consistent. I’ve said in the past to that the relative link + base tag antecedent in the header is the preferred option for linking because it enables slightly faster pagespeed and UX, makes the switch from dev to live environment seamless, and is more impervious to scraping. But in the real world, human beings are just not consistent enough in deployment. Thus, it’s better to just use absolute links, take the little speed hit, and never worry about it again.
 
• 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 current 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.
 
• noopener attribute per Google’s recommendation.
• Put assets in a single folder dedicated to each asset class, then call these files anywhere you want them to appear:
   
• PDFs in a single PDF subfolder example.com/pdf/filename.pdf
 
• Images in a single image subfolder example.com/images/filename.jpg
 
• Videos in a single video subfolder example.com/videos/filename.mpeg
 
• Files in a single file subfolder example.com/files/filename.docx

Pagespeed

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 display 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 if for nothing else but for perceived pagespeed. This means that designers ought to save it in Photoshop as “Progressive Scan” instead of interlaced ideally before the devs ever get ahold of it.
• Prioritize use of Google Webfonts within reason. There are now 848 974 996 font families and counting as of March 10, 2020. There is no reason that, for example, [REDACTED] 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. There you will find other useful recommendations for pagespeed optimization that are 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.
 
3. Validate your structured data with Google’s Structured Data Testing Tool.

Structured Data for search engines

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 Schema.org 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:

 
• Schema.org <—Preferred for websites
 
• DublinCore.org

Structured Data for social networks

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.

Open Graph Protocol

A special type of structured data markup is open graph protocol for social networks. Most social networks ingest structured data from socially shared links, then display the data in a pretty format to help 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:

 
• Supplemental Twitter Card markup
 
• Supplemental Pinterest Rich Pins

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

 
• Facebook sharing debugger
 
• Twitter card validator
 
• Pinterest rich pin validator

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

 
• Expression Engine Plugins:
   
• Recently Updated: EE social meta plugin
 
• Not updated since June 2017: EE open graph data plugin

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 client sells tangible products, we should implement additional ecommerce-heavy entity markup across their site.

Directives

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

With this noindex tag, we are saying to search bots, “Here, crawl all our pages if you want, but these particular pages won’t do your users any favors.” If we find that Googlebot/Bingbot/Yahoo/Yandex/Baidu wastes resources repeatedly crawling these pages, we will request updating the attribute to noindex, nofollow.

Filenaming Conventions:

Filenames often end up as part of a URL. The presence of keywords in a URL 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]
 
• Example: FabCom-Analytics-Measurement Model-20190131

Measuring SEO and CRO Impact on Client Business Bottom Line

So after all this work making things better, how do you know what difference you made? 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 and we show you the results daily, weekly, monthly, quarterly, and annually. Don’t rest on your laurels, though. The truth is, we can always do better. Here’s a useful quotation to keep in mind that is often misattributed to Edmund Burke:

“Applause is the spur of noble minds, the end and aim of weak ones.” —Charles C. Colton

 

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 when submitting live-environment forms for any client, it would be very helpful if you:

 
1. Use your work email address, because Yoni has filtered out our domain from appearing to clients when we submit test forms. Instead, internal test email notifications are sent to [REDACTED]@fabcomlive.com.
 
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 as a redundant method of preventing our “conversions” from appearing in client analytics reporting across ad channels, GDS, Salesforce, Tableau, Looker, Matomo, or wherever else we have them set up.

Event Naming Conventions (especially for AJAX)

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

 
• clientAcronym-productName-actionType-actionName-subName (Subnames as needed)
 
• Naming Examples:
   
• [REDACTED]-[REDACTED]-Form-FastApp-{{Product/Program}}
 
• [REDACTED]-[REDACTED]-Form-Application-{{Product/Program}}
 
• [REDACTED]-[REDACTED]-Form-RFI-{{Product/Program}}
 
• [REDACTED]-[REDACTED]-Form-Contact Rep
 
• [REDACTED]-[REDACTED]-Form-Tour
 
• [REDACTED]-[REDACTED]-Form-Newsletter
 
• [REDACTED]-[REDACTED]-Form-PDF-{{Title}}
 
• [REDACTED]-[REDACTED]-Email-{{fName lName}}
 
• [REDACTED]-[REDACTED]-Phone-{{fName lName}}
• Add dataLayer push events to successful AJAX events. Here’s an example:
   
• dataLayer.push({'event' : 'formSubmitted', 'formName' : '[REDACTED]-[REDACTED]-Form-FastApp-{{Product/Program}}’});