If you have been seeing some AMP errors show up for some of your WordPress posts, compliments of the wildly popular AMP WordPress plugin, Tomo Taylor, the AMP Community Manager at Google has posted some great troubleshooting tips for publishers yesterday.

It was in response to a publisher who was still seeing hundreds of AMP errors, even with the latest version of the plugin.

1. Select some articles and run the page through the AMP HTML validator to preview and validate:

a. Open your page in your browser.
b. Add “#development=1” to the URL, for example, https://ampbyexample.com/#development=1.
c. Open the Chrome DevTools console, with mobile device mode emulation enabled, and check for validation errors.
d. Fix your validation errors.

The AMP validator using DevTools isn’t that well known, so nice to see them promoting it as a debugging tool for validation error issues.

2. Check AMP schema.org Article markup properties in the Structured Data Testing Tool.

a. Ensure that the NewsArticle, Article, or VideoObject Rich Snippet is present.
b. There should be no ‘AMP’ warnings/errors.
c. Is the logo ‘image’ attribute within 600×60?
d. Does the logo fit the UI guidelines for logos in the carousel?

This is an area where many publishers run afoul initially.  If the site’s logo doesn’t meet the guidelines, every page will throw an error.  This needs to be updated to fix it.

3. Check AMP HTML page linking:

a. Is there a rel=amphtml link on the canonical page?
b. Is there a rel=canonical on the amp html page?
c. Is there a rel=amphtml link on the mobile site page, if applicable?

I haven’t seen any plugin related errors caused by this, but if you are implementing a custom, or even manual, solution, this is worth checking.

4. Check external resources:

a. URLs of all embedded iframes, videos, custom fonts, pixels, analytics, ads, etc, and similar content need to be fetched via the HTTPS scheme.
b. Don’t use “protocol relative URLs”, this might cause problems when the article is loaded via the Google AMP Cache. When a document is served from a cache elsewhere, such as the cdn.ampproject.org, a relative URL will no longer point to your intended canonical. Instead use an absolute URL.

In my experience, after the logo issue, the plugin most often throws errors related to embedded content, especially on sites that make extensive use of embeds.

Some sites will also have issues with some of the WordPress specific coding and AMP, too.  But when you click on each individual AMP error type in Google Search Console, it will show the problematic coding, although it isn’t very intuitive for those inexperienced with coding to figure some of them out.

But it is great seeing Taylor (and others) continue to assist webmasters who are still having issues figuring out AMP implementation.