Wordpress SEO Expert

Improve your Google ranking with 24-year experienced SEO professional Peter Mahoney

Cumulative Layout Shift (CLS) for SEO & Speed

by

Right, this is an interesting one. It’s technical, but has a very simple main recommendation (in large text, below).

Google has started to include something they’re calling CLS in their ranking metrics.

Essentially it means ‘how long before elements loading on the site stop moving around’, and their target is just 0.25 seconds.

If things move around as your page loads for longer than that it’ll get a warning in their system. (This isn’t general loading time, just a very specific part of how a site loads.)

Think about when a website loads, the first thing it does is load the layout – where the menu is, where images will go, text, etc. That’s the elements they’re talking about.

It’s fine for a image to take longer to load, as long as the space it will take is already reserved for it when it DOES load. To be honest most of this happens so quickly you can’t even see it.

But there is one very common thing lots of sites have turned on that means layout changes happen long after a page is loaded – and that’s “lazy load” for images.

Lazy Load was a great technique when it became popular a decade ago. It meant images didn’t load on a page until the browser needed to se them. If an image was at the bottom of a page, and the user wouldn’t see it in the browser until they scrolled down, it waited until it needed to load it to do so.

But when that happens, it moves elements on the page around accordingly to make space for the image – and therefore will always fail the CLS test Google does for all sites and pages.

So ironically something that used to be recommended to help a page load faster is now a problem for passing loading time tests!

Personally I’ve not used Lazy load for years (in most cases it was unclear if the speed enhancement it brought was actually better than the extra Javascript it needed to work) – but now my recommendation to all website owners is clear:

If you use Lazy Load, turn it off.

Reminder, JPGs are for photos

by

Please remember when saving images to upload to the web – photos should be saved as JPGs.

PNG is another popular format for the web but it works best on images like logos, with large blocks of the same colour.

Anything like a photograph that is made up of 1000s of different colours will always be best as a JPG – and usually about one 10th the filesize.

Of the clients that ask me to speed up their WordPress websites (in addition to their SEO work) perhaps the most improvement comes from simply converting their photos they’ve saved as PNGs into JPGs. If a site has several photos that are saved as the wrong file type it’s easy to shave several megabytes off the page size, and therefore speed up the site’s loading time.

Part of the problem is a lot of software for editing images will default to PNG when you use their “Save for web” function. Which is fine for icons and logos, charts and even text saved as an image.

So many websites these days focus on really high quality imagery (understandably – people love photographs!) but don’t know that not all file types are created equally, they all have different purposes and use cases and those wonderful product shots should always be saved as JPGs.

It’s good to get in the habit of doing this right away – after an image is uploaded into WordPress there’s no simply way to convert it to JPG and change all the references in the code to use the different filename. So try to get it right from the outset!

Using WordPress as a static site generator

by

My WordPress site is so fast, I’m not even sure I can call it WordPress anymore.

Static site generators are awesome.

They create blindingly fast sites, with very few drawbacks (more on those later).

But I’ve been using WordPress since it was a small blogging platform call b2. I’m used to it, I like it, and already have a swag of sites built on it for myself; not just my clients.

Because I work in SEO speed is really crucial to what I do. I do a lot of caching and optimisation work for people, but wanted to see what would happen if I really pushed the envelope out.

Initially I was keen to make a front-end that pulled data out of a basic WordPress install using JSON. I set up a proof-of-concept successfully, but wasn’t so keen on remaking all my layouts and front-end design from scratch for it. Besides, basic things like the WordPress menu editor, text widgets etc. are something I very much enjoy using.

I did some research, and came across a plugin called WP2Static. It’s a slick plugin that basically does just what I wanted – it packages up WordPress sites as static sites you can deploy anywhere. With a bit of configuring you can actually use it to output to a folder on the same server, and use some basic .htaccess rules so that becomes the public facing side of things.

Which is cool, but I wanted to go for MAXIMUM SPEED. My end goal was to get the site hosted on GitHub Pages, and then use Cloudflare to CDN it around the world.

(WP2Static does actually have a system to deploy to GitHub Pages built-in, but I found the deployment process just too slow.)

So when I considered everything I was trying to achieve, which included keeping the live site on the same URL it was already on, I opted to do the following:

  • move the WordPress install of my site off its current server, onto my localhost machine (it’s fast and I back it up regularly)
  • use WP2Static to output the site to a local folder
  • use git via the terminal to publish the site

In theory, for a nerd, it seems fairly straightforward. And on the whole it worked much more easily than I anticipated. The main glitches to overcome were that a number of font files weren’t being picked up by the plugin for inclusion in the static site. But it has a configuration option to force it to include certain file paths, so that was easily overcome.

I did need to create a manual 404.html page (GitHub Pages looks for that in the top directory of a site) but that’s neither here nor there.

There were a few other tiny things that were really specific to my own WordPress setup – like realising my sitemap.xml file needed to be a flat XML file rather than an index linking to other XML files – because they weren’t going to be wrapped up by the plugin.

The thing you really lose with any static site system though is (logically) user interaction. In my case that was just forms, but I was happy to replace my contact form with a simple email address – anything else I might need in the future I can do by embedding forms directly from another system like Google Forms.

I used to sell a couple of SEO packages directly through my site, but Woocommerce was always overkill for that anyway. In the future I’ll just use a combination of Paypal buttons to replicate the same functionality – and in fact it’ll be simpler for the end user because I don’t need to know all their billing address information to start an SEO job with them.

The really big day-to-day drawback is that clicking ‘Publish’ in WordPress doesn’t publish anything anymore. The process to run a new export with WP2Static and then send it to GitHub Pages takes about two minutes. But considering how often I blog or change anything on the site that’s not a major issue. Like with anything, you need to weigh up the processes, pros and cons against how you actually use something to determine if it’s right for you.

The site I did all this too, fyi, is the one you’re on right now. This is a static site, hosted for free on GitHub Pages and replicated on servers around the world using Cloudflare.

Google PageSpeed Insights gives a 99% speed rating for Desktop. And the missing 1% is simply because I include an external file that I can’t set an expiration header for – ironically that file is the script for Google Analytics.

Pingdom (my preferred speed testing system, because you can choose a server location for the real-world load-time to be tested against – so if your clients are predominantly in London then choose that server to get an idea of the speed as they’ll see it) gives the homepage a 0.212 second loading time. For something ultimately based on WordPress as a content management system, that’s impressive.

How best to tag your images for SEO on WordPress

by

The correct approach to image tags may surprise you.

Here’s a reminder about why they are best optimised using a plugin.

Because of the way WordPress evolved over time from a simple blogging tool to an advanced content management system, traditionally people have set alt & title tags per image, using the media manager.

But that’s not best for SEO. Images should reinforce what the page is about, not just what the image is of.

To give an example, if you have one image that’s used on two pages, you might not want them to both have the same alt tags. So the systems I set up does an excellent job of setting those tags in the live code whenever a page is visited. It mixes the page title with the name of your site to make sure both your branding and (most importantly) what the page is actually about is being reinforced.

It’s the best approach for image tags and search engines.

(My favourite plugin for this is PB SEO Friendly Images.)

Fill in your social media profiles

by

Far too many WordPress sites end up with empty social links

I see this all the time; in the header or footer of WordPress sites, a series of little social media icons that links to – nothing.

A lot of WordPress themes have sections for you to fill out your social profiles, so those little buttons can link to them correctly. But a lot of those themes will show them regardless of whether or not you’ve entered proper URLs. Some go a step further, and by default will have a link entered as #. That just means it links back to the page you’re on, but it’s enough to get the buttons showing and essentially linking to nothing.

It’s an easy enough oversight to make. But it means you have dead links which isn’t great for your SEO, and if visitors notice then it just seems wildly unprofessional.

If you have social buttons, they really need to link to social sites. It’s not hard to do – these sorts of WordPress themes are intended to make everything as simple as possible – but at the very least have a quick check of your own site and make sure your social button links, well, link.

In all honesty I see this in perhaps a third of WordPress sites overall, so there’s a good chance it affects your’s.

Problems with Google PageSpeed Insights

by

Google PageSpeed Insights has become a tad problematic of late.

Firstly, Google PageSpeed is just a list of code changes that might improve your website’s speed. In most cases trying to do everything they list would simple break a WordPress website – it’s usually a matter of having to try lots or permutations of speed settings to see which scores best. So for example with a lot of themes if you minify javascript and defer scripts it it’ll break things, so we have to choose between those.

It’s also true that when Google actually uses speed as a metric for your SEO ranking, they’re looking at the actual load time for the site as opposed to how it measures on the PageSpeed metric.

To give you an idea of why the % scores aren’t a great measure, let’s consider browser caching. We can’t change whether other domains have it or not. So if you reference any other scripts in your site, for example Facebook, we can’t affect that. And you’ll still fail for the ‘browser caching’ section – even though it might already be applied to all your own scripts.

It’s a great irony of PageSpeed that having Google Analytics installed on a site always costs it a few % points, for the same reason. You’d think Google could do better with their own systems.

Google also changed the way they display results recently and it’s made their reports far less useful for the majority of sites out there. They recommend you ‘Serve images in next-gen formats’, even though there’s a lack of cross-browser compatibility for them. (Yes, you can set things up with a fall back so if a visitor’s browser doesn’t support JPG 2000 it will show another image instead – but as yet this isn’t something you’ll find commonly in WordPress themes. In fact I’m not sure it’s in any.)

So suddenly this testing tool is giving biased advice – guess which browser has full compatibility with next generation image formats? Google Chrome.

Like most Google reporting, PageSpeed does give a good idea of possible things to investigate but it’s not worth getting so hung up on you stop focusing on your content creation.

RSS

Peter Mahoney, WordPress SEO expert blog