The Error Log Nobody Reads

A record nobody opens

Every time something on a website fails, the server writes a line about it: a script that crashed, an image that was not there, a page requested that no longer exists.

On most small business sites, those lines pile up unread for years.

The site looks fine to its owner, who visits the same few pages that work. The failures happen to other people: visitors arriving on old links, customers pressing send on a form.

The log knew all along. Reading it takes about ten minutes a month.

Two records worth reading

The first is the error log, kept by the server, which records scripts that fail, with the time, the file involved and a short description.

The second is the record of pages not found, known as 404 errors after the code a server sends when an address leads nowhere. Search Console keeps a list of them, and Analytics can too.

What they catch

• A form handler that fails on submit while the page looks normal.
• Missing images, deleted from the media library but still used on old pages.
• Pages that moved in a redesign, still linked from other sites.
• Plugins raising warnings that will become failures after the next upgrade.
• Log files growing large enough to fill the hosting account.
• Bots probing for login pages and software you never installed.

The first costs the most, because nobody sees it happen. The visitor presses send, gets a blank page or an error, and leaves, and the only witness is a line in the log.

Where to find them

Many hosting control panels have an errors page showing the server's most recent entries. PHP often writes files called error_log into the site's folders as well.

On managed hosting, the host may keep the logs and send them on request, which is worth asking for at least once.

For pages not found, Search Console's Coverage report lists addresses that returned a 404. It takes over from the old crawl errors report, which Google said it would retire at the end of March.

Analytics can show the visitor's side, if the not-found page has its own title. Switch the All Pages report to page titles, select that one, and it lists the addresses people tried to reach.

Reading without alarm

Logs are noisy, and most lines in them are harmless. The skill is knowing what to ignore.

Requests for things that never existed on your site, such as a WordPress login page on a site that does not run WordPress, are automated probes. Every site on the internet receives them.

What matters is repetition and recency. The same line appearing every day since a particular date usually marks the day something changed.

Pay most attention to lines naming your forms, your theme or a plugin, and to anything marked fatal, which means a script stopped rather than complained.

A worked example

A catering company working from an industrial unit took most of its wedding enquiries through a quote form written for it in 2011.

In January, the host moved older accounts to PHP 7, a newer version of the language the site runs on. The site looked exactly as before.

The form, though, saved each request using database commands that PHP 7 no longer includes. Every submission now ended in a blank white page.

The error log had recorded the same fatal error, a call to an undefined function, every time anyone pressed send for eleven weeks.

It came to light when a couple phoned to ask why nobody had replied. The maintainer rewrote the form handler in a day, and a test submission joined the monthly checklist.

Treat 404s as a to-do list

Each repeated not-found address is one of four things, and each has its own fix.

A page that moved needs a permanent redirect to its new address. A broken link inside your own site needs correcting. A missing image or file needs restoring, or its reference removing.

The fourth is junk, requests for things that never existed, and it needs nothing.

Start with addresses real visitors keep requesting and those linked from other sites, since each one is somebody who meant to reach you.

What to pass on

The fix belongs with whoever maintains the site. Your part is handing over findings precise enough to act on.

Copy the line exactly, with its date and time. Add the page address involved, what you were doing if you saw the problem yourself, and how often the line appears.

Resist editing files on the server to make an error disappear. A change made on the live site to silence a warning often hides the cause, and leaves the next person less to go on.

Debug logs left switched on

One log is worth asking about specifically. WordPress can keep a debug log while somebody investigates a problem, and the setting is sometimes left on afterwards.

By default that file sits in a public folder, where anyone who knows the usual name can download it, along with the file paths and plugin names it contains.

Ask whoever maintains the site whether it is on, and if so, to switch it off or move the file somewhere private.

The counter-case

Some sites have little to log.

A small site with no forms, no shop and few changes generates few errors worth reading, and a quarterly look may be enough.

A site on a maintenance plan may already have somebody reading the logs; ask for a short monthly summary instead.

And a busy store or booking site needs alerts the day something fails, not a monthly read.

For most small business sites, though, ten minutes a month and a short note to the maintainer is the right amount.

Once a month

1. Open the error log in your hosting panel.
2. Look for lines that repeat daily.
3. Note anything naming your forms or theme.
4. Check the 404 list in Search Console.
5. Submit every form on the site yourself.
6. Send your findings to the maintainer.
7. Book next month's read in the calendar.

Step five catches what no log can. A notification that sends perfectly and lands in a junk folder leaves no error anywhere, and only a test submission reveals it.

The other check that only works if it happens before the emergency is covered in restoring a backup before you need to.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.