How to Use Server Logs to Improve Your WordPress Site

We all want to find ways to improve the performance of our WordPress sites so that our end users have the best experience possible and continue to interact with our content.

But what are server logs, and how can they help to realize that goal?

What are Server Logs?

At the most basic level, server logs are records of events that happen on a site, on the server. These events could be anything which occurs in the day-to-day functioning of your site, but the two most common are access logs and error logs.

As a general rule of thumb, all of these logs will be able to answer these two questions:

• When did an event happen?
• What happened during the event?

Yep. That’s pretty vague, and I’ll get into more concrete examples later on, but before I do that, you might be wondering why you should review the server logs in the first place.

Why it’s Important to Review Server Logs

It’s important to note that the information contained in server logs is similar but different than the information you can get from other analytics services like Google Analytics.

The two tools are answering different things, and I recommend making use of both!

A tool like Google Analytics goes to great lengths to distill information about the actual users that are interacting with your site. So if you’re trying to ask a question like “How does a user travel through my site?” or “What’s the average viewing time of a user on the site?” you should turn to Google Analytics.

But if your questions are more along the lines of “Can the server physically handle the traffic that is going to it?” then you should turn to your server logs.

Remember that server logs are records of events happening on the site, and they can be analyzed to answer complicated questions.

I often will turn to a site’s server logs when I want answers to questions like:

• How many, and what kinds of requests are being made of the site?
• Are there specific plugins that are negatively impacting the performance of the site?
• Are there pages that are causing performance issues and contributing to bad user experience?

Being able to answer these questions will allow you to make informed decisions about where you apply development time, and how you spend money to improve the functioning of your site.

How to View Your Server Logs

Most hosting companies keep server logs for a set timeframe, and should provide you access.

Here at WP Engine, we keep three types of logs for seven days:

• Access logs
• PHP error logs
• Slow error logs

You can download these logs by selecting the “Export Logs” button from the “Advanced” tab of your WP Engine dashboard.

These logs contain information in plain text, so you can open them with any text editor to view them.

Reading a Log Entry

“Ok great, but how do you read these logs, and aren’t they meant for developers?”

Sure, if you’ve never seen a server log, then the walls of text can be intimidating and can elicit a desire knock-off for the rest of the day. But if you break them down, it’s like learning to read a new language – it’s arcane at first, but once you get used to the characters, then you can extract meaning!

Let’s start by taking a quick look at a standard log that most hosting companies can make available to you – the access.log.

Every time your site is accessed (for example, by an end user or a search engine bot), the server records a line in this log.

Here’s an example of something accessing the “Contact Us” page of a site. Note that it looks like it spans multiple lines, but in the actual log, the text, is all on one line.

183.240.92.18 - - [22/Jan/2018:06:26:06 +0000] "GET /contact-us/ HTTP/1.1" 200 7687 "http://www.google.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36"

Let’s break this down!

• 183.240.92.18 – The IP address from where the request originated.
• - - – In the early days of the internet, these dashes would have information about the user who made the request. Since these values are easily spoofed, you will rarely see servers fill in this information.
• [22/Jan/2018:06:26:06 +0000] – The timestamp of the request along with the UTC offset. Since this timestamp has +0000, it has no offset and is using the UTC timezone.
• "GET /contact-us/ HTTP/1.1" – This is the request for an actual page from the server. You can see what kind of a request (GET as opposed to a form submission like POST) as well as the page that was requested, and what version of HTTP was used.
• 200 – This is the HTTP response code. A 200 means that everything about the request was good. Other common response codes are 404, which means that the page doesn’t exist, or 301, which is a redirect to another page.
• 7687 – The size of the page returned as measured in bytes.
• "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36" – The user agent string, which is another way of saying “what the browser says it is.” Note that this can also be spoofed, so take it with a grain of salt.

Ok, I know that’s a lot. But just take it slow, and you’ll start to learn how to make sense of all this. And once you know how to review server logs, you’ll have a powerful new tool in your corner for optimizing your sites and making better client experiences!