Reading a redirect access log

Reading a redirect access log turns redirects from a set-and-forget configuration into something you can actually evaluate. A redirect may have been created months or years ago, but without usage data you cannot easily tell whether visitors still reach the old URL, where those visits come from or whether the rule is still doing useful work.

A redirect access log provides that missing context.

Instead of showing only that /old-page/ redirects to /new-page/, a useful log can tell you when the redirect fired, how often it has been used, what page referred the visitor and whether multiple requests appear to come from the same source.

This guide explains how to read a WordPress redirect access log, what hit counts and timestamps actually tell you, how to interpret referers and user agents, what repeated hashed IP values mean, how logs help after URL migrations and when an old redirect may finally be safe to remove.

What is a redirect access log?

A redirect access log is a record created when a visitor or automated client requests a URL that matches a redirect rule.

Imagine that your site contains this permanent redirect:

/old-services/
    → /services/

Every time something requests /old-services/, the redirect fires and sends the request to the new destination.

Without logging, you know the rule exists but not whether anyone still uses it.

With logging, you can answer questions such as:

• is the old URL still receiving traffic?
• when was it last requested?
• did traffic increase after a migration?
• are visitors arriving from an old internal link?
• is another website still linking to the old address?
• does the traffic appear to come from browsers, crawlers or automated tools?
• are the same sources returning repeatedly?

TheOneWP Redirect Manager combines redirect rules with hit counts, last-hit timestamps and a per-redirect access log so these questions can be investigated from the same interface.

A redirect rule and a redirect log are different things

The redirect rule defines what should happen.

For example:

From: /old-product/
To:   /new-product/
Type: 301

The access log describes what actually happened after that rule was created.

A simplified log might look like:

2026-08-20 09:12
Referer: https://example.com/category/products/
User agent: Mozilla/5.0...
Visitor hash: e814a7c291e6b120

2026-08-20 09:44
Referer: https://google.com/
User agent: Mozilla/5.0...
Visitor hash: 82ab1294ef570441

The first part is configuration. The second is evidence.

Start with the redirect’s total hit count

The simplest metric is the total number of times the redirect has fired.

If a redirect shows:

Hits: 8,421

that tells you the old URL has remained relevant enough to receive thousands of requests.

A count of:

Hits: 0

means something very different.

However, total hits should never be interpreted without context.

A redirect created yesterday with 20 hits may be extremely active. A redirect created ten years ago with 200 total hits may now receive almost no traffic.

That is why hit count and last-hit time should be read together.

Check the last-hit timestamp

The last-hit timestamp tells you when the redirect was most recently used.

Consider these two rules:

/old-page-a/
Hits: 12,450
Last hit: today

/old-page-b/
Hits: 12,450
Last hit: 18 months ago

The total counts are identical, but their current relevance is completely different.

The first redirect is clearly still catching traffic.

The second may be a candidate for review, although its age alone still does not automatically mean it should be deleted.

Redirect Manager keeps both the running hit count and the last-hit timestamp on each redirect so you can distinguish historical popularity from current use.

Recent activity matters more than lifetime totals

Lifetime hit counts can become misleading on old sites.

Imagine a redirect created five years ago:

Total hits: 38,214
Hits during the last year: almost none

The large total tells you the rule was important historically, but not necessarily that it remains important today.

This is one reason access logs are more informative than counters alone.

A detailed log lets you inspect the recent pattern rather than relying entirely on an accumulated number.

What does the referer tell you?

The HTTP Referer header can indicate which page initiated a request.

The official MDN Referer documentation explains that this header may contain the address of the page from which a request originated.

In a redirect log, the referer can be extremely useful.

For example:

Referer:
https://example.com/blog/wordpress-performance/

could indicate that one of your own pages still contains an outdated internal link.

Instead of leaving the redirect to compensate forever, you can update that internal link so it points directly to the final destination.

Internal referers often reveal links you forgot to update

Suppose you migrated:

/services/web-design/
→
/web-design/

but the redirect log repeatedly shows:

Referer:
https://example.com/about/

That strongly suggests the About page may still contain a link to the old URL.

The redirect protects visitors from the broken link, but the better long-term solution is:

1. keep the redirect;
2. update the internal link;
3. confirm new visitors reach the destination directly.

Redirects should preserve old URLs, not become a substitute for maintaining your own internal links.

External referers can reveal valuable old backlinks

A referer from another domain can tell you that an external site still points to the old URL.

For example:

Referer:
https://some-industry-site.com/resources/

This is valuable information.

The redirect may still be preserving traffic from a backlink that would otherwise lead to a 404.

In this situation, removing the redirect simply because it is old would be a poor decision.

If the external link is important, you might even contact the referring site and ask them to update the destination, while keeping the redirect as protection for other old links.

A missing referer does not mean the visit is suspicious

Redirect logs frequently contain requests with no referer.

This can happen for perfectly normal reasons.

The visitor may have:

• typed the URL directly;
• used a bookmark;
• clicked a link from an application;
• come from a privacy-restricted context;
• followed a link governed by a restrictive referrer policy;
• used software that does not send the header.

The Referrer-Policy documentation explains how websites and browsers can control how much referrer information is transmitted.

Therefore:

Referer: empty

does not mean:

Visitor: bot

Humans remain annoyingly capable of being ambiguous.

What does the user agent tell you?

The User-Agent header provides information about the client making the request.

The official MDN User-Agent documentation explains the structure and purpose of the header.

A user agent may suggest that the request came from:

• a normal web browser;
• a mobile browser;
• a search crawler;
• a command-line client;
• an automated monitoring service;
• another software tool.

For example:

Mozilla/5.0 ... Chrome/...

looks like ordinary browser traffic, while something such as:

curl/8.x

suggests a command-line HTTP client.

Do not use user agents as proof of identity

User-agent strings are useful hints, not authentication.

A client can send almost any user-agent value it wants.

A bot can claim to be a browser.

A browser extension or privacy feature may modify the value.

Modern browsers may also reduce the amount of identifying information exposed through user-agent strings.

Use the field to understand patterns, not to prove who made a request.

What does the hashed IP tell you?

A privacy-conscious redirect log does not necessarily need to store raw IP addresses.

TheOneWP hashes the visitor IP before storing it in the Redirect Manager access log.

The result may look something like:

e814a7c291e6b120

That value is not intended to tell you the visitor’s real IP.

Instead, its practical value is comparison.

If several log entries contain the same hash, you can infer that they came from the same IP value as seen by WordPress at the time of logging.

Repeated hashes can reveal request patterns

Imagine this sequence:

10:01  hash: a14f91c12345
10:02  hash: a14f91c12345
10:03  hash: a14f91c12345
10:04  hash: a14f91c12345

That repeated value suggests the same source address requested the redirected URL several times.

Now compare it with:

10:01  hash: a14f91c12345
10:03  hash: 91bd821acf24
10:07  hash: 39f17c028bd1
10:12  hash: 82c4b2217ae5

The second pattern suggests multiple source addresses.

Neither pattern proves whether the traffic is human or automated, but it provides useful context when combined with timestamps, user agents and referers.

A hashed IP is not a user identifier

Do not treat the same hash as proof that the same human returned.

Several people can share one public IP address.

A user’s IP can change.

Mobile networks, corporate networks, VPNs, proxies and NAT can all complicate the relationship between an address and a real person.

The hash is therefore useful for identifying repeated network-level patterns, not individual identities.

Look at timestamp clusters

Timestamps can reveal patterns that a total hit count hides.

For example:

14:01:02
14:01:03
14:01:04
14:01:05
14:01:06

looks very different from:

09:14
11:48
15:22
19:05

The first pattern may indicate automated requests, testing, crawling or repeated retries.

The second looks more like naturally distributed traffic.

Again, context matters. A popular URL shared in a newsletter can legitimately generate a sudden burst.

Read the fields together

The most useful interpretation comes from combining fields.

Consider:

Timestamp:
2026-08-20 10:21

Referer:
https://example.com/old-navigation-page/

User agent:
Mozilla/5.0 ... Safari/...

Visitor hash:
831bf00912f74aa8

This could reasonably suggest that a visitor using a browser followed an outdated internal link.

Now compare:

Timestamp:
2026-08-20 10:21:01
2026-08-20 10:21:02
2026-08-20 10:21:03

Referer:
empty

User agent:
curl/8.x

Visitor hash:
same value every time

That looks much more like an automated or scripted request pattern.

The point is not to label every visit. The point is to understand what kind of traffic keeps the redirect alive.

Redirect logs are especially useful after URL migrations

A major URL restructure is one of the best times to watch access logs closely.

If you change:

/blog/category/article/
→
/guides/article/

the old address may exist in:

• Google’s index;
• other search engines;
• external backlinks;
• old emails;
• social posts;
• bookmarks;
• browser history;
• your own internal links.

How to migrate WordPress URLs safely covers the migration process itself. The redirect access log becomes useful afterward because it shows which legacy URLs continue to receive traffic.

A post type migration can produce the same problem

Changing a WordPress post type can change the final permalink.

For example:

/blog/security-guide/
→
/guides/security-guide/

TheOneWP Post Type Converter can create a redirect through Redirect Manager when a conversion changes the permalink.

After the conversion, the redirect log provides evidence that the old address is still being requested.

For the wider SEO implications of changing custom post type URLs, see WordPress custom post types and SEO.

Check redirect activity immediately after migration

After a major URL change, a sudden increase in redirect hits is usually expected.

It can actually be reassuring.

For example:

Day before migration:
0 hits

Migration day:
1,842 hits

Next day:
1,103 hits

This suggests that old URLs are being requested and the redirect layer is catching them.

A migration followed by absolutely no redirect activity may deserve investigation if you expected substantial existing traffic.

Redirect logs can reveal URLs you underestimated

You may assume one old URL was insignificant and another was important.

The log may disagree.

For example:

/old-category/
43,821 hits

/old-product-page/
17 hits

The first redirect clearly continues to protect significant traffic.

Logs replace assumptions with actual usage data, which is a surprisingly useful innovation in web administration.

Understand the redirect status code before interpreting the log

The meaning of activity depends partly on what kind of response the rule sends.

301 vs. 302 vs. 410: which one to use covers these differences in detail.

In short:

• 301 means the resource has moved permanently;
• 302 represents a temporary redirect;
• 410 means the resource is intentionally gone and has no replacement destination.

Google’s Redirects and Google Search documentation explains the distinction between permanent and temporary redirect signals.

How should you interpret a heavily used 301?

A heavily used 301 usually means an old permanent URL still exists somewhere in the ecosystem around your site.

Possible sources include:

• external backlinks;
• old indexed results;
• bookmarks;
• internal links that were never updated;
• historic marketing material.

The redirect is doing precisely what it was created to do.

If the referers reveal outdated internal links, update them.

If external links still drive traffic, keeping the redirect is normally useful.

How should you interpret a heavily used 302?

A 302 should normally represent a temporary situation.

If a temporary redirect has remained heavily used for months or years, review whether the underlying situation is genuinely still temporary.

You may discover that what started as:

Temporary campaign redirect

quietly became:

Permanent site architecture

At that point, the redirect strategy may deserve reconsideration.

What about 410 activity?

A 410 does not redirect the visitor to another URL.

It tells the client that the requested resource has been intentionally removed.

A 410 access log can still be useful because it shows whether requests continue arriving for the removed resource.

If an old 410 URL receives repeated traffic from one of your own pages, that may reveal a broken internal link that needs correction.

Do not redirect every removed URL to the homepage

A redirect access log is also useful for spotting questionable redirect architecture.

If hundreds of unrelated retired pages all point to the homepage, the redirect system may technically avoid a 404 while giving visitors a poor destination.

A redirect should ideally lead to a relevant replacement.

If no relevant replacement exists, a proper removed-resource response can be more appropriate than pretending the homepage is somehow the spiritual successor to every page ever deleted.

Look for redirect chains

A redirect chain occurs when one redirect points to another redirected URL.

For example:

/page-a/
→ /page-b/
→ /page-c/

The better structure is usually:

/page-a/
→ /page-c/

/page-b/
→ /page-c/

This removes an unnecessary intermediate request.

How to migrate WordPress URLs safely is particularly relevant when several generations of old URLs have accumulated during repeated restructures.

Access logs can help expose old redirect chains indirectly

Suppose the access log shows large numbers of requests for an old URL even though you believed every internal reference had already been updated.

Trace the complete redirect path.

You may discover:

/2019-page/
→ /2022-page/
→ /current-page/

The oldest redirect should normally point directly to the current destination.

Watch for redirect loops

A redirect loop occurs when requests are sent in circles.

For example:

/page-a/
→ /page-b/

/page-b/
→ /page-a/

This prevents the browser from reaching a final page.

Redirect Manager includes protection against saving a redirect that directly points the source back to the same on-site location.

More complex loops involving several systems can still require investigation, especially when redirects also exist at the server, CDN, theme or plugin level.

Remember that WordPress also performs canonical redirects

Not every redirect on a WordPress site necessarily comes from your manually configured redirect list.

WordPress core contains its own redirect_canonical() logic, which attempts to redirect certain requests to their canonical WordPress URL.

This distinction matters when debugging.

If a URL redirects but does not appear in your Redirect Manager log, another layer may be responsible.

Redirects can exist at several layers

A WordPress request can potentially be redirected by:

• the web server;
• a reverse proxy;
• a CDN;
• WordPress core;
• a plugin;
• the theme;
• custom PHP;
• JavaScript;
• an external service.

A Redirect Manager access log only tells you about redirects handled by that particular system.

It is not automatically a complete server access log.

Use HTTP inspection when the log and browser disagree

If the browser appears to redirect but the expected rule does not log a hit, inspect the HTTP response directly.

Browser developer tools can show:

• the status code;
• the Location header;
• the sequence of requests;
• the final destination.

You can also test with a command such as:

curl -I https://example.com/old-page/

A redirect response may include:

HTTP/2 301
location: https://example.com/new-page/

The official WordPress wp_redirect() and wp_safe_redirect() references explain the core PHP redirect functions used throughout WordPress.

Why a redirect may have hits but no useful referer

You may find a redirect with hundreds of hits but almost no referer information.

Possible explanations include:

• direct bookmarks;
• links from email clients;
• mobile applications;
• privacy settings;
• search or browser behavior that limits referrer data;
• automated clients;
• referrer policies on the originating page.

Do not conclude that the log is broken simply because the referer field is empty.

How to find outdated internal links using the log

A practical workflow is:

1. open a heavily used redirect;
2. review recent referers;
3. identify referers belonging to your own domain;
4. open those pages;
5. find links pointing to the redirected source;
6. update them to the final destination;
7. continue monitoring the redirect afterward.

This gradually reduces unnecessary internal redirect hops without sacrificing protection for old external links.

How to find old external backlinks

The workflow is similar for external referers:

1. identify frequently appearing external domains;
2. open the referring page where appropriate;
3. confirm that it still links to the old URL;
4. evaluate whether the backlink matters;
5. contact the publisher for an update if worthwhile;
6. keep the redirect as a fallback.

The log therefore becomes more than a debugging tool. It can contribute to ongoing URL maintenance and SEO cleanup.

Should you delete a redirect with zero hits?

Not immediately.

Zero recorded hits can mean:

• the redirect really is unused;
• it was created recently;
• the log retention window no longer contains older traffic;
• the old URL is seasonal;
• an important external link simply has not been clicked recently;
• the redirect predates logging.

Use zero hits as a reason to investigate, not as an automatic deletion rule.

Should you delete a redirect that has not fired for months?

Again, context matters.

A redirect for an old marketing campaign may eventually become unnecessary.

A redirect preserving a historical permalink with valuable backlinks may deserve to remain indefinitely.

Before removing it, check:

• recent access-log activity;
• historical hit count;
• external backlinks;
• internal references;
• search visibility;
• whether the source URL could still exist in bookmarks or documents.

Remember the log retention window

TheOneWP Redirect Manager retains access-log entries for approximately 90 days.

This means the detailed log is primarily a picture of recent traffic.

The lifetime hit counter and last-hit timestamp remain important because a 90-day detailed log cannot tell the entire history of a redirect that has existed for years.

If you require longer-term historical analysis, export or record the relevant data before the retention window removes older entries.

Do not confuse the redirect log with analytics

A redirect access log answers a narrow set of questions very well.

It is not intended to replace full analytics.

The log can tell you that an old URL was requested.

It does not necessarily tell you:

• whether the visitor converted;
• how long they stayed on the destination;
• what they did afterward;
• which marketing campaign produced the visit;
• which real person made the request.

Use the redirect log to understand redirect usage, not to turn four HTTP fields into an imaginary customer-data platform.

Privacy matters in redirect logging

Logs can become unnecessarily invasive if they store more visitor information than the task requires.

TheOneWP Redirect Manager avoids storing the raw visitor IP address. Instead, it stores a salted hash that can help distinguish repeated network sources without retaining the original address.

The stored user-agent and referer values are also truncated.

This provides useful operational context while limiting the amount of raw visitor information retained.

A practical redirect-log review workflow

A useful periodic review looks like this:

1. sort or identify redirects with the highest hit counts;
2. check which ones were hit recently;
3. inspect their recent access logs;
4. look for your own domain in referers;
5. update outdated internal links;
6. identify important external referers;
7. look for repeated user-agent or visitor-hash patterns;
8. check whether temporary redirects are still genuinely temporary;
9. look for redirect chains;
10. review low-use redirects before removing anything.

Example: reading a real redirect pattern

Imagine this rule:

/wordpress-security/
→
/guides/wordpress-security/

301 Permanent

Total hits: 6,842
Last hit: today

The recent log contains:

08:12
Referer: https://example.com/blog/
UA: Mozilla/5.0 ...
Hash: 8172a...

08:45
Referer: https://google.com/
UA: Mozilla/5.0 ...
Hash: 92ac1...

09:04
Referer: https://external-site.com/resources/
UA: Mozilla/5.0 ...
Hash: 71bd4...

You can draw several practical conclusions.

The redirect is still actively used.

Your own blog may contain an outdated internal link that should be fixed.

Search traffic is still reaching the old address.

An external backlink is still pointing to the old URL.

Deleting this redirect would clearly be premature.

Example: a redirect that may be ready for retirement

Now consider:

/summer-sale-2022/
→
/offers/

302 Temporary

Total hits: 47
Last hit: 14 months ago
Recent log: empty

This deserves review for a different reason.

The redirect was temporary, the campaign is years old and no recent traffic is visible.

Before deleting it, confirm that:

• no important backlinks point to the source;
• no internal links remain;
• the campaign will not return at the same URL;
• the destination strategy still makes sense.

Only then decide whether the rule has outlived its purpose.

Common mistakes when reading a redirect access log

Looking only at total hits

A large lifetime number does not tell you whether the redirect is still active today.

Assuming an empty referer means a bot

Many legitimate requests arrive without referer information.

Treating a user agent as verified identity

User-agent strings can be modified or spoofed.

Treating the IP hash as one individual person

The same network address can represent multiple users, and one user can appear under different addresses.

Deleting a redirect because recent logs are empty

Always consider retention, seasonality, backlinks and historical use.

Ignoring internal referers

Your own site repeatedly hitting old URLs usually means you have internal links worth updating.

Keeping temporary redirects forever

A 302 that has effectively become permanent should be reviewed.

Assuming every redirect is controlled by one plugin

WordPress, the server, CDN and other plugins can all create redirects independently.

Redirect access log checklist

For every important redirect, review:

• redirect source;
• destination;
• status code;
• total hit count;
• last-hit timestamp;
• recent hit frequency;
• internal referers;
• external referers;
• empty-referer patterns;
• user-agent patterns;
• repeated visitor hashes;
• possible redirect chains;
• whether the destination still exists;
• whether the rule is still appropriate;
• whether internal links can bypass the redirect entirely.

Related WordPress redirect guides

For a broader redirect and URL-maintenance strategy, continue with:

• 301 vs. 302 vs. 410: which one to use
• How to migrate WordPress URLs safely
• WordPress custom post types and SEO
• Redirect Manager
• Post Type Converter

Final thoughts

A redirect access log answers a question that redirect configuration alone cannot: is this rule actually being used?

Total hits show historical volume. Last-hit timestamps show current relevance. Referers can expose outdated internal links and valuable external backlinks. User agents provide clues about the software making requests, while privacy-conscious visitor hashes help reveal repeated network patterns without storing raw IP addresses.

TheOneWP Redirect Manager brings those signals together with 301, 302 and 410 handling, per-rule counters and recent access history.

The useful outcome is not simply having more log data. It is using that data to improve the URL structure itself: update internal links, preserve valuable old backlinks, identify redirects that remain important, review temporary rules that became permanent and remove only those redirects whose purpose has genuinely disappeared.

A redirect should not survive forever merely because nobody remembers why it exists. It should survive because the evidence says it is still doing useful work.