Why Embedded Gists Are Probably Not SEO-Friendly, and What Can We Do About It

marketing luck technology letter

While embedded gists solve the native Code block’s lack of readability, they introduce SEO issues. Read for a couple of possible solutions.

Gists are beautiful, but their SEO-friendliness is questionable

Embedded gists are beautiful and readable. In this respect, they are better than the native Code block.

But embedded gists seem to lack SEO-friendliness. They are rendered by JavaScript, and on AMP pages they are also using an iframe. There aren’t definitive answers for how Google treats embedded gists specifically, and JavaScript rendered content and iframes in general. So, it seems that for being on the safe side of SEO there is a need to do something extra.


One option could have been copying the snippet into a <noscript> tag. The official AMP documentation allows the use of <noscript> and defines it to behave regularly. But still, the official AMP WordPress plugin strips <noscript> tags, even when JavaScript is enabled. I’ve opened a support thread on the subject. A following ticket was opened in the AMP WordPress plugin GitHub project for providing a way to preseve <noscript> tags. As a workaround, you can directly use <amp-gist> element, instead of Jetpack embedding functionality, and then nest <noscript> tag in it. But this involves more manual work and doesn’t cover the non-AMP version of the page.

Anyway, the <noscript> solution isn’t perfect – it is a manual duplication, that needs to be manually maintained in case the gist itself is changed.

There is one more non-perfect solution…

An exception in favor of a plugin?

For better chances of future-proofness, I usually strongly prefer official solutions over non-official ones, especially if the non-official solution is a solo-developer plugin with few active installs. But maybe there is room for reception here. Weston Ruter has a Syntax-highlighting Code Block (with Server-side Rendering) plugin, which enhances the native Code block, rather than introducing a new one. Besides an auto-detect syntax highlighting, the plugin adds to the native Code block the option to highlight specific lines, show line numbers, and wrap lines.

graphical user interface, text, application, email
The new options added to the native Code block by the Syntax-highlighting Code Block plugin

And this is how it looks like, with a custom font size of 12px, and Show Line Numbers and Wrap Lines options enabled:

<?php $query_args = array( 'foo' => 'bar', 'apple' => 'orange', 'posts_per_page' => 50, 'offset' => 0, ); $some_posts = new WP_Query( $query_args ); while ( $some_posts->have_posts() ) { /* * Do some stuff here */ // Get more posts $query_args['offset'] = $query_args['offset'] + $query_args['posts_per_page']; $some_posts = new WP_Query( $query_args ); }
Code language: HTML, XML (xml)

It is a solo-developer plugin, without many active installs, but Weston is a “Googler working on AMP, PWA, & open web; WordPress core team”. So – not just any solo-developer. The plugin does beautiful work, and one can hope it will be integrated to core somehow, someday, for future-proofness.

Another option for non-AMP sites

SyntaxHighlighter Evolved is a more popular plugin for syntax-highlighted code blocks. The plugin is even semi-official, as it has Automattic listed as a contributor. But it doesn’t support AMP as of now.


Apparently, there isn’t a code-embedding solution that enjoys readability, SEO-friendliness, AMP-friendliness, and future-proofness. Weston Ruter’s plugin might be the best gamble, or compromise, in this case – maybe with a chance to be merged to WordPress core eventually?

External links

Was the post helpful?

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: