When starting a new SEO project or taking a fresh look at an existing project, it can be hard to know where to start. That’s why we’ve decided to share our in-house checklist to save you the trouble of making your own and to help you avoid missing the important aspects along the way.
That first resource focuses on the indexing of pages, XML sitemaps, identifying duplicate content, page load time, your site’s content and a large collection of on-page optimization strategies. It’s something you can’t afford to miss!
Now, if you’ve already gone through part one of the checklist then congratulations and please carry on…
We have used examples from the “New” version of Google Search Console where available. At this time, Google has not finished moving all features from the new to old system, so at times we will have to refer to the old reporting methods.
1. Click Depth
How many clicks is the majority of the important content from the home page?
What’s the maximum depth of content in clicks from the home page?
2. Content Structure
How many categories are there?
How many sub-categories are there?
How many product or detail pages are there? Compare to number of indexed pages earlier and review what percentage of products are indexed.
How many links are there in the main navigation?
Are there over 100 links on upper level pages? Over 100 might be getting excessive and may be spreading available Link Juice too thin.
4. Link Anchor Text Structure
Does the site utilize reasonable keywords in internal link anchor text? For example links to product and category pages linked to using appropriate keywords?
Excessive repetition of primary keyword in navigation structure can trigger a penalty or reduced ranking.
5. Are Mobile Redirects working correctly?
If the site customizes content for mobile devices, or redirects users to a m.domain.com site, verify the redirects are working correctly. Desktop site subpages should NOT redirect to the m.domain.com site’s home page. Desktop sites should not redirect to 404 error pages on m.domain.com sites either.
If a desktop user lands on the desktop site, can they navigate (or be redirected) successfully to the mobile equivalent?
If a desktop user lands on the mobile site, can they navigate successfully to the desktop page equivalent?
Does the site redirect Tablet users to a mobile site? That might not be the best solution if the desktop site works well for tablets.
6. Search Engine Friendly URLs
Does the site utilize excessive URL parameters and/or session IDs? These can cause crawling and duplicate content problems.
Shorter URLs are better for usability and are easier to link to.
Descriptive URLs can aid in ranking and increase click through rates.
7. General Usability
One sign of a high quality website is great usability. While this isn’t a full usability test, it’s important to make note of glaring issues such as –
Note any particularly annoying or hard to use features of the site.
Are there pop-ups that can’t be easily closed? Do Pop-ups cover up content on mobile devices? That can cause an interstitial penalty in some cases. Ideally they should not obscure content except under specific conditions such as age verification.
Can forms be filled out easily? Is autofill enabled?
Are there advertising links closely located to other navigation features making them difficult to avoid clicking?
1. Does the business have an Owner Verified Google My Business Page?
Is there more than one My Business Page Listing for the business?
Who is in control of the account via the listed email address?
2. External Citations and Reviews
Do external citations include keyword stuffed references describing the business such as “best plumber in Houston”? Would an editor from Google use the words in a description?
Are reviews duplicated in multiple locations? Does the website publish their Yelp, Google My Business Page, or other duplicate reviews on the site? This can cause a loss of reviews in Places when Google finds duplicates.
Are on-site reviews or ratings marked up with Schema.org/hReview tags?
Note the last review or ratings date, are new ones being posted?
3. Do Address & Phone Number on the Google My Business Page and website match exactly?
This is a factor in Local Search for Google.
4. Are City and State, and/or other location related Keywords in use within H tags and Body Text?
Use of the City and State as keywords can improve Local Search Ranking.
5. Are the Business Name, Address, Phone and Contact info listed on every page?
Business Contact info (NAP) on every page is highly recommended both from Google Quality Raters Guideline and from a local search aspect.
Ideally the NAP (Name, Address, Phone) info is marked up with Schema.org markup on either the home page, directions or contact us page, but not necessarily on every page of the website. Ideally your structured data markup represents the topic of the page, having multiple top level markup entities on a page can create confusion as to what the main entity of the page is, example having both /LocalBusiness markup and /Product markup on the same page.
Secure Server Errors / HTTPS
If the site uses a security certificate, make sure to check the following.
1. Inspect the padlock icon in the browser
Does the padlock icon show an X, slash or red label indicating the certificate is invalid?
Are there any browser security warnings when you load the page?
If the padlock icon isn’t showing, are there any mixed content errors or other errors being reported?
If you do a site:domain.com search at Google, are you finding any HTTP URLs indexed?
Are both the HTTP and HTTPS versions getting indexed?
Test the server redirect from http to https using SEN’s HTTP Header Analyzer, the redirect should generate a 301 code from http:// to https://.
4. Are internal links correct?
Do the pages rel=canonical tags point to the correct HTTPS version of the URL?
If the pages are meant to be viewed with either HTTP or HTTPS, do they use protocol relative URLs? (example <a href=”//path/page.html”>)
5. Any chained redirects present?
If you attempt to load http://domain.com, do you get redirected to http://www.domain.com then to https://www.domain.com? You can test this using SEN’s HTTP Header Analyzer. Ideally in that situation there should be only one 301 redirect, from http://domain.com to https://domain.com. You should not see multiple 301 redirects taking place.
6. Scan the site for non-secure content.
Videos and Images
1. If there is video hosted on the site, is an XML Video Sitemap used?
Video Sitemaps can enhance and improve chances on getting the video to show up in Organic Search.
2. Are XML Image Sitemaps used?
Image Sitemaps can enhance and improve ranking for Image Search, and to show in Organic Search. It’s suitable to use either a mixed HTML and image sitemap, or a dedicated sitemap for each. Using a dedicated image sitemap helps with the reporting functions and can give you better information as to what is indexed.
1. Form Testing
Test all forms to make sure they are functioning correctly. Verify form reply messages are correct and verify form data is sent to the appropriate people.
Also test email contact addresses that are listed on site.
Does the form request a password or credit card data? If so, the page needs to be HTTPS and the form submission URL or Google’s Browser may throw up a non-secure warning.
2. Review WHOIS contact data and Domain Expiration Date
Is whois domain registration information public? It should be, also verify all contact information is correct including address, email and phone. This is a Google Quality Rater Guideline.
Note renewal date for domain. Who is the contact that will be renewing the domain? Are they aware of what to do when it’s time for renewal? It’s not a bad idea to set a data in your calendar as a reminder to make certain the domain is renewed.
Note: Due to recently implemented Privacy Laws, you may see only limited Whois information in the near future, or the domain may be set to private registration. In that case consult with the domain owner to have them verify this information.
3. HTTPS Certificate Expiration
When does the HTTPS certificate expire? Do you or your client have a plan in place to renew or replace the security certificate? There are several tools available to check the expiration date, such as the SSL Checker.
4. What is the Site’s uptime?
Numerous sites offer this service to monitor and alert you when the site goes down. Such as http://host-tracker.com/ and many others. How would you know if there is a problem if you’re not monitoring it?
Some of these services will email you when the content on the site changes. How long would it take you to find out that your site has been hacked and has something embarrassing on the home page?
5. Google Analytics
Many websites make use of Google Analytics, but also many have things configured incorrectly. Do a quick review of the following;
Log into the Google Analytics account and verify the account is properly tracking hits to the site. You should be able to go to the real time traffic display, load a page and see the traffic as a hit in real time.
Verify only one instance of the same Google Analytics Tracking Script is being used on each page. Multiple instances of the tracking code can inflate site traffic.
Is Google Search Console associated with the Google Analytics account?
Is the Google Analytics setup making use of demographics, events, goals and conversion tracking?
Is the account setup for the proper protocol that the website is using (HTTP/HTTPS) ?
6. Dangerous Remote Resources
If you don’t recognize the domain name, this could be a potential source of malware or viruses. It may or may not be active when you test it! If you get zero information back from one of those, it could very likely be that the site has been hacked in the past, but the dangerous code hasn’t been activated… yet. A call to a blank resource is a good indication of a trojan horse that can be activated at any time!
Hosted libraries such as ajax.googleapis.com are a safe resource. If in doubt, do some research to make sure that off site resource is safe.
These issues can be hard to locate, close examination of your HTML code is required to find these on a compromised website. Be especially vigilant if you know the site has been hacked or compromised in some way in the past.
7. CMS / WordPress Software Out of Date
Log into the sites CMS and review the current CMS release date. Is there a notification there is a newer version available? How many versions is the software out of date? Google is now sending warnings to verified sites when it detects WordPress sites need to be updated. This may be quality signal for Google, as out of date software is often a security risk. Note: Web Hosts may shut down a site that is allowed to get too far out of date due to security risks.
Review the sites plugins to see if any need updated.
Is the theme the site uses out of date or need updated? Themes can have security problems as well and should be kept up to date.
Remember to check Forum software and other software powered resources. While Google isn’t reporting on these yet, it’s likely to happen in the near future as they expand on what they’re monitoring.
Don’t underestimate the potential for errors or compatibility problems when updating a website’s CMS, Plugins or Themes. Make certain you have a FULL working backup of the sites files and database/s before an update, and make sure you have a contingency plan should and update cause major issues or make it totally unusable.
8. ADA Compliance
The 100 lb. gorilla that nobody wants to acknowledge sitting in the corner is ADA compliance for websites. While there are no separate government guidelines for mobile devices, mobile accessibility is not likely exempt. The good news is that most anything you do to make a site ADA Compliant also makes it easier for search engines to read and interpret.
The W3C has some information on that topic at www.w3.org/WAI/mobile. It’s clear that mobile tools and test capabilities are lacking at this time. Do think through the issues involved with reduced sight and blind users with your sites mobile theme.
We can not possibly cover all the issues involved with making a site ADA compliant for both Desktop and Mobile in this checklist, however we urge you at this time to familiarize yourself with requirements and review the W3C Checklist at the minimum.
9. Video Testing
Verify no flash is used for navigation, videos or other elements on mobile pages. HTML5 is preferred for video players, or embed a popular service for video such as YouTube or Vimeo. Google has been applying ranking demotions for some sites due to the use of Flash in mobile search since 2013. Google may generate a “Uses Flash. May not work on your device. Try anyway | Learn more” notice to users in the search results to warn users of incompatible sites.
Verify all videos are responsive so they scale to fit the screen, even if you’re using an embedded video such as YouTube. The default YouTube embed code is NOT responsive. There are methods such as this one from CSS-Tricks to make YouTube embedded videos responsive – use them.
10. User Interface Testing
Test the site’s desktop and mobile pages on a variety of popular devices. Desktop Browsers (Chrome/IE/Firebox), Android Phones, iPhones, iPads and Android Tablets ideally multiple sizes of each. If you do not have multiple devices to test with, borrow or ask a friend. Emulators are better than nothing, but typically not always accurate.
Be sure navigation is usable on each device. 30-pixel margin around links is considered minimal for touch targets.
Review any pop-ups used on pages that can be reached with mobile or tablet devices. Ideally pop-ups are to be avoided, but if they are used, be sure the user can escape or close the pop-up on a mobile device (regardless of orientation).
Google does have a “intrusive interstitial” penalty which can affect pages that have popups that cover main content either when the visitor lands on the page or when they are scrolling down through a page. Also displaying a standalone interstitial that the user has to dismiss to read content. See Google Now Demoting Mobile Pages with Popups for further details.
Dedicated Mobile Sites
Dedicated Mobile / AKA “M Dot” sites such as m.facebook.com are sites that are made specifically to fit smartphones, but do not adapt to fit desktop browsers. Typically they are used in conjunction with a desktop site, which redirects mobile users to the mobile site.
1. Test Desktop Site for Redirect & 404 Errors
It’s hyper important to check redirects from your desktop to mobile website very carefully. You need to ensure mobile visitors aren’t being all redirected to the home page of mobile, or redirected to a 404 page on the mobile site. Google is now posting a warning in search results to users if it detects an improper redirect, and they may demote the URL, or in some situations penalize the entire site for this problem.
Mobile visitors to your desktop site should be redirected to the same content on your mobile site. If there is no appropriate page on the mobile site, the visitor should not be redirected.
One way to test this is to use the Screaming Frog test spider. In the paid version, they have the ability to change the user agent that you can set to a mobile browser emulating a mobile visitor. You’ll need a full list of all your desktop URLs, which you can load into Screaming Frog and have it spider them. Review the report to look for 404’s and redirects to the home page of mobile site.
This test should also be preformed if you’re updating from a two site (desktop/mobile)setup to a single responsive site.
2. Usage of Rel=Alternate/Canonical tags
Per Google’s recommendation, your desktop pages should have a rel=”alternate” tag that links to the Mobile equivalent of the page.
<link rel="alternate" media="only screen and (max-width: 640px)"
Your Mobile site should have rel=canonical tags pointing back to the equivalent desktop version of that page.
Do NOT just point all mobile pages back to the home page of the desktop site, or all desktop pages to the mobile home page.
3. Visitor Option Available?
Do your mobile and desktop users have the ability to override the site’s redirect? For example, if a visitor arrives at your mobile site, can they choose the desktop version without getting redirected back to the mobile site? This happens a lot when someone shares a mobile URL and someone on a desktop browser clicks on it. It’s important that when someone chooses the alternative version, it’s to the same content, not just a link to the home page.
This ability is very important. Sometimes detection methods don’t work right and the visitor will want to specifically view the desktop or mobile site.
Most sites set a cookie when the visitor makes this choice that the redirect script reads to bypass the redirect that would normally occur for that user agent.
Can the user easily find this option and select it on a mobile and desktop browser?
4. XML Sitemaps
If you have your mobile site on one domain or subdomain (m.example.com) and your desktop site on another domain (www.example.com), each site should have their own XML Sitemap.
Your M Dot domain should be verified separately with Google Search Console so that you can submit the sitemaps independently.
Review indexation for all sitemaps using Google’s Search Console to spot problems.
If your mobile site is a subdirectory of your main site, (www.example.com/mobile) you would only use one sitemap for both mobile and desktop pages.
5. Check for Robots.txt and Meta No-Index Tags
Verify the dedicated Mobile site can be spidered and content is not blocked in robots.txt. Many of these sites were setup in the past to block access to spiders via robots.txt or meta no-index tags. Now that Google has a method using rel=alternate and rel=canonical blocking the robots is a BAD idea and can kill your mobile ranking.
RESS (Responsive Design with Server Side Components) are sites that are dynamically generated and typically change the template based on user-agent and/or device width. The site may or may not alter the page content based on the device, but if you do change content based on device, you should be sure you’re using the Vary:User-Agent header or Google may think you are cloaking the page and apply a penalty!
One older example of RESS is the WordPress Plugin’s that load a mobile template when the plugin detects a mobile user. Those plugins need to also be treated as an RESS enabled site, even though the content does not change.
Test for Vary: User-Agent HTTP Header
Google requires that sites that change content based on user agent notify them by using the Vary-HTTP Server Header as listed on their Dynamic Serving page.
Use of the Vary-HTTP Header can let caching servers know not to serve a mobile user desktop content at the ISP or other levels.
You should also use this header if you’re hiding content based on device, such as using CSS display:none for mobile users. That is a risky thing to do if the content is not viewable in any situation by the mobile user. Be aware that Google has stated they may “discount” or ignore text that makes use of CSS display:none or visibility: hidden text. If the user can display the text easily by activating a toggle or similar feature, that use is ok. The problem is with hidden text that the user will never see.
Accelerated Mobile Pages
AMP pages are the latest development by Google and Twitter to create a very fast mobile experience. However, we are still in the infancy of working with these simplified HTML pages. There are very specific requirements for AMP for both HTML code usage and for Schema Markup. Errors are very common for many WordPress plugins available at this point. If you’re already working with an AMP enabled site, you certainly need to review the following frequently as Google keeps changing requirements.
1. Review Google’s Search Console AMP Report
Log into Google’s Search Console and review their Search Appearance > Accelerated Mobile Pages Report. Since AMP is so new, many errors are likely going to require updates to Plugins in order to fix the problem (assuming you’re using WordPress or another CMS).