Long Title But This Is About Search Rankings
Lets start off skipping the title and saying what this is actually about. Ranking on Google search for a clients site. First off the site itself is just 2 months old, studies suggest it should take about 3 to 6 months to rank well. The site languished in the 30s … or page 3 for the first month but now its presenting a commanding ranking. Of the 283 keywords I track the site ranks in 211. Page 1 rankings now reach 19 on Google, 37 on Bing and 38 on Yahoo….UPDATE…I was looking at last weekends numbers. 27 on Google, 54 on Bing and 63 on Yahoo for page one results.
SEO isn’t marketing. Onpage SEO may be, but what does a marketing course teach us about the Offpage SEO which is backlink and server performance related? Top ranking sites need both and I’d argue that Offpage SEO is more important. Granted neither of the two halves will rank a site as the top result alone, but too often people focus on Onpage SEO and neglect the technical side of ranking.
Of course the top 3 positions of search results are the next step for the site I’ve mentioned above and feeling confident in content and Onpage SEO I’ve focused recently on the server side of things. Towards that goal I am testing a WordPress High Availability deployment.
CDNs By Definition Remove Bottlenecks
This coupled with Cloudflare DNS and CDN is I think going to produce a server environment that’s obscene. For those who aren’t familiar with a CDN network here is a handy image explaining it.
I’ll update everyone on the effect of the sites rankings. The first kick in rankings which in the line graphs is where the trend really caught upward direction happened when I moved the site off of a shared hosting server to its own LAMP stack server. Essentially now I am dividing the stack across auto-scaling servers.
Here’s a the getting started guide as provided by Google.
WordPress High Availability Getting Started Guide
WordPress Deployment Overview
This document aims to provide the information necessary to maintain and perform administrative tasks on your WordPress High Availability deployment from the Google Cloud Launcher
Google Cloud Prerequisites
This solution leverages a few GCP features, which require certain APIs to be enabled in your project in order for Deployment Manager to successfully deploy these resources. The following APIs should be enabled before you deploy the solution:
- ● Google Identity and Access Management (IAM) API
- ● Cloud SQL Administration API
- ● Cloud Container Builder APIThe Google Identity and Access Management (IAM) API is required in order to create a service account who only has access to the GCS bucket that will also be created as part of the deployment.The Cloud SQL Administration API is required in order to create and interact with the Cloud SQL instances that are created as part of the deployment.The Cloud Container Builder API is required in order to delete the GCS bucket and its contents at deployment deletion time.
The solution architecture is made up of 5 main components:
- A Google Cloud SQL instance running MySQL configured with failover to handledatabase workloads
- A Google Cloud Storage bucket to act as a synchronization point for content stored in
- A Managed Instance Group for running Cloud SQL proxy tool, responsible for maintaining secure and efficient database connections
- A Managed Instance Group for the VM that will be used to perform administrative functions in WordPress
- A Managed Instance Group for the VMs that will serve the content of your blog
- An HTTP Load Balancer to distribute the traffic between the content serving nodes
Below you can see an architecture diagram of how the components relate to each other.
Key Components & Services
There are two custom services running on the deployed machines that are essential for the solution to function properly. These services are gcs-sync (running on WordPress instances – both Admin and Content) and cloudsql-proxy (running on the SQL Proxy instances).
The gcs-sync service runs a script /opt/c2d/downloads/gcs-sync that, depending on the role the VM is assigned (Content or Admin), will check in with the GCS bucket tied to the deployment and determine if content needs to be pushed to or pulled from GCS. If you need to interact with the service, you can do so via systemctl. For example:
systemctl stop gcs-sync
will kill the script checking GCS, and the node will not receive any updates that come from the Administrator Node. Conversely, if the service needs to be started you can do so with the following command:
systemctl start gcs-sync
The cloudsql-proxy service makes use of the Cloud SQL Proxy binary so you can connect to your Cloud SQL instance without having to whitelist IP addresses, which can change when instances are deleted and recreated in a Managed Instance Group. The Cloud SQL binary is located at /opt/c2d/downloads/cloud_sql_proxy and the script that executes the binary is located at /opt/c2d/downloads/cloudsql-proxy. Like the service that runs gcs-sync, it can be interacted with using systemctl. Stopping the service can be done with:
systemctl stop cloudsql-proxy
At this point your instance will not be able to communicate with the Cloud SQL instance, and the application will not function. If you needed to manually start the service for any reason you can do so with the following command:
systemctl start cloudsql-proxy