Wordpress SEO Expert

Improve your Google ranking with Peter Mahoney, 20+ years SEO & Wordpress experience

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.

Preparing for Voice Search SEO

by

41% of adults search for something using voice at least once a day, and for young adults it’s over half!

This applies to Google voice search, Alexa home devices, Siri…anything you can ask a question and expect a result.

The good news is the way we approach SEO for voice search hasn’t drastically differed.

Yes, voice searches tend to be longer and more conversational. And direct too.

Here’s an example, let’s say I want to know what the highest mountain is in the UK. Previously I might have entered highest mountain uk into a search engine.

But when asking a voice assistant, I’m more likely to say something along the lines of tell me what is the highest mountain in the uk. So it’s longer and more conversational. But despite its length it is more direct; I’m being clearer about what I want to know, which is what the highest one is.

That text search could bring up a page of results that list several high mountains, or articles that talk about a recent event or news story that took place on the highest mountain.

At this point in time search engines are taking these voice questions and dumbing them down for their own purposes. So when a voice search tool is actually working out what results to return, the example above could well be turned into that simpler 3-word version behind the scenes.

What’s really going to have an impact is when that directness starts to be factored in a lot more intuitively. Because at that point in time search will become less like looking up relevant information based on a subject (like an old encyclopedia) and more to do with answering really specific questions.

It’s very early days to think about how the approach we take to SEO might change when that happens. But the key will be in line with the major engines’ existing ethos – your website should have a clear purpose, and be written in a natural human readable way so that visitors can easily find the information they’re looking for.

And in that regard voice search is really just a continuation of the direction the search engines have been heading toward for well over a decade.

How to find your Google rank

by

Searching for yourself is a terrible idea

I still get asked a lot about discrepancies between what a client sees when they search for themselves, and either the official stats, or what their friend might see, etc.

So this is a refresher about why you shouldn’t search for yourself as a way to measure your ranking.

Google does all kinds of personalisation on your search results (based on your network’s IP address, if you’re logged into any Google accounts, even your location) and the more often you look for your own site, the more skewed those results will be.

To give an example, most people searching for “Peter Mahoney” see my site on the first page. But I see myself on the fourth. Essentially because I’ve searched for myself so often – and then not spent much time on my site or even bothered to click it – Google has “learnt” that I don’t like it and therefore ranks it down for me, uniquely.

The right place to get Google’s official rank for your site is their own monitoring systems, which is where I get my stats.

Their stats are actually an ‘average’ of your rank which is the statistically most useful approach. Because of personalisation, not everyone sees your site in the same position. Where someone is searching from geographically for example has an impact. So the average rank is the best indicator of where you rank.

There’s a commonly held belief that if you use a private browsing window somehow you’ll see the proper rankings in the search results. But all that does is prevent Google from knowing your account – they still know where you live, your IP address, in some cases the unique code for your network card – there’s *plenty* for them to skew your results with.

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.

Nonsecure Collection of Passwords will trigger warnings in Chrome 56

by

Over the past week I’ve seen more than my fair share of emails from Google regarding “Nonsecure Collection of Passwords will trigger warnings in Chrome 56″.

It’s a big change, but not exactly a surprising one.

Google has been pushing to make the web more secure for a long time. Seeing HTTPS and green padlocks all over the web has been a key direction for them – they’ve even given secure sites a ranking boost as part of their algorithms. This new change is really an extension of their general SEO ethos.

So anyone running the latest version of Google’s Chrome Browser (version 56) will see a warning when browsing any web page that asks for sensitive information. The examples they’ve given are passwords or credit card details but undoubtedly there’s other situations a user would be presented with a warning too.

I’ve been recommending web owners migrate to HTTPS for a few years, but now it’s become really important especially if you have any page users can log in through (including I expect WordPress Dashboard login pages like wp-login.php) or e-commerce.

These things may well be frustrating when they first crop up, requiring immediate changes to your website. But bear in mind Google has been open about their general desires for the web (that it be easy to find useful information, that it be secure, mobile friendly and fast) for a long time. So as long as you apply those same concepts to your own site as soon as you can then changes like this will actually put you ahead of the curve.

In case you know this impacts you but haven’t yet had the email from Google about it (or don’t use Google Search Console in which case you’d never get one) here is the text of their message:

Nonsecure Collection of Passwords will trigger warnings in Chrome 56 for http://www.domain.com/

To: owner of http://www.domain.com/

Beginning in January 2017, Chrome (version 56 and later) will mark pages that collect passwords or credit card details as “Not Secure” unless the pages are served over HTTPS.

The following URLs include input fields for passwords or credit card details that will trigger the new Chrome warning. Review these examples to see where these warnings will appear, and so you can take action to help protect users’ data. The list is not exhaustive.

{examples are given here}

The new warning is the first stage of a long-term plan to mark all pages served over the non-encrypted HTTP protocol as “Not Secure”.

 

Google Apps is now called G Suite

by

Google Apps (used for business email, file sharing, calendaring etc.) is now rebranded as G Suite.

Which sounds like a bad mid-90s R&B group. (Try as I might, I can’t forget “Rappin’ 4-Tay”.)*

In their official blog post, Google said this is more in keeping more with their mission to provide a series of tools businesses use to further their own purposes. Basically rather than a series of individual applications coming together they see it as a stock set of tools within one Google system.

Fair enough.

Google Apps proved to be an invaluable tools for companies, schools and universities, and I do hope G Suite continues to build on and improve those systems.

But I do have one niggling concern in the back of my mind. Google Apps used to be free for small firms, then overnight all new accounts were subject to a subscription fee. Existing free accounts continued to run with charge – but any change to Apps brings a fear they might start to charge for those grandfathered accounts.

And with a change this big, well – Google Apps keep free accounts, but will G Suite?

Read the original Google blog post
*Although I thought of making this joke myself, I wasn’t the first, so credit goes here

Prices are quoted exclusive of VAT unless expressly stated.

RSS

Peter Mahoney, WordPress SEO expert blog