Sitemap Log
The Sitemap Log shows every sitemap the plugin has built, or failed to build: how many URLs it holds, how big it is, how long it took and what it cost, who triggered it and any error. It is the first place to look when a sitemap is slow, missing URLs, or shows a 503.
Available since 1.14.0.
Open it at Super Speedy > Sitemaps > Sitemap Log.
Reading the log
Each row is one build, newest first. The tab shows the latest 200 rows.
| Column | What it shows |
|---|---|
| Time | When the build finished, in your site’s timezone. |
| Sitemap | The sitemap built, linked so you can open it. |
| Result | What happened, and what the visitor received (see below). |
| URLs | How many URLs the sitemap lists. |
| Size | The size of the sitemap’s XML before compression. |
| Gzipped | The size of the cached file on disk. Empty when caching is off, because no file was written. |
| Time taken | How long the build took, in seconds. |
| Queries | Database queries the build ran. |
| Peak memory | The most memory PHP used during the request. |
| Requested by | Regenerate button, Logged-in user, Visitor or crawler, or WP-CLI for builds run by wp sssm warm. |
| Details | The error for a failed build, and any notices logged while it ran. |
Results
- Generated, new sitemap – built and served normally.
- Failed, last good copy – the build hit a database or PHP error, so the visitor got the cached copy from the last successful build instead.
- Failed, 503, retry later – the build failed and there was no cached copy, so the visitor got
503 Service Unavailablewith aRetry-Afterheader. - No items, 404 – the sitemap is enabled but has nothing in it, for example a taxonomy with no terms, so it returned 404.
How Super Speedy Sitemaps Scales explains why a failed build is never served or cached.
Problems only
Click Problems only above the table to list just the failed and empty builds, with a count. All entries returns to the full list.
For a failure, Details names the cause:
- a database error, with the error and the start of the query that failed, which usually means the database was overloaded or dropped the connection
- a PHP error such as running out of memory or time, with the file and line, which usually means the sitemap is too large for the server’s limits
- A few failures during a traffic spike or a crawl of your own site need no action: the next request after the load drops builds the sitemap again.
- The same sitemap failing every time needs its limits lowered. Troubleshooting has the steps.
- A failure that names another plugin’s file or query points at that plugin, not the sitemap.
Using the figures
Time taken, Queries and Peak memory let you compare a sitemap before and after a change. Lower Global limit or Database query limit, regenerate, and compare the new row with the old one. The figures for one sitemap vary from build to build with whatever else the server is doing, so compare a few builds rather than one.
Serving a sitemap from the cache is not logged and writes nothing to the database, so a crawler reading cached sitemaps adds no load. Each row is a real build.
How much is kept
The log keeps the last 1,000 builds in its own database table, so it never grows without limit and never fills the WordPress options table. Older rows are removed as new ones are added. On a multisite network each site has its own log.
Clear Log at the bottom of the tab empties it. Deactivating the plugin also clears it. From the command line, wp sssm log reads it and wp sssm clear-log empties it; see WP-CLI Commands.
Switching logging off
Logging is on by default. To switch it off, untick Advanced Options > Debugging > Enable message log. Nothing is recorded while it is off, including failures, so leave it on unless you have a reason not to.
Further reading
Written for Super Speedy Sitemaps 1.16.0.
Comments