If a site address leads somewhere else, appears in a sitemap unexpectedly, or returns an error, this map helps you decide which relationship to check first.
The URL Integrity Map connects signals that TrustyRunner observed during the scan: URLs found in acquired sitemaps, URLs encountered while exploring the site, destinations reached after redirects, canonical declarations, indexing directives, and HTTP responses.
It is not a list of “SEO errors.”
Its purpose is to surface relationships that are worth comparing with the behavior you actually want from the site.
A relationship may be entirely intentional. The useful question is: does what TrustyRunner observed match what you intended?
How to read the map
The map describes what TrustyRunner was able to observe within the limits of the Light scan.
The current version can retain up to:
- 64 URLs observed during the scan;
- another 64 URLs found in acquired sitemap data but not observed during site exploration;
- 16 cases for each type of relationship.
When TrustyRunner reports partial coverage, some relevant data may not have been included in the map.
Therefore:
- “not observed” does not automatically mean “does not exist”;
- “not found in acquired sitemap data” does not mean “absent from every sitemap on the site”;
- a relationship describes what was observed during that scan, not necessarily the entire site.
Sitemap URL redirects to a different final URL
Observed
TrustyRunner found a URL in acquired sitemap data and, when that URL was requested, the redirect led to a different final URL.
Why check
A sitemap generally lists destinations the site owner considers relevant.
If a sitemap URL goes through a redirect, it may be worth checking whether that relationship is intentional.
The redirect itself does not mean that the sitemap is wrong.
Limits
TrustyRunner cannot know which of the two URLs you intend to keep as the main reference.
The redirect may be part of a migration, URL normalization, or another deliberate technical choice.
This relationship also does not determine how a search engine will treat the two URLs.
Action
Check which URL you actually want to declare as the destination.
If the final URL is the destination you want to represent directly, consider updating the sitemap to point directly to it.
If the redirect is intentional and you have a specific reason to keep the original URL in the sitemap, simply verify that the relationship matches your intent.
Verify
After the change, a new scan should show the relationship you intended to keep between the sitemap URL and the final URL.
Sitemap URL with noindex observed
Observed
TrustyRunner observed the same URL in acquired sitemap data and with a noindex directive.
Why check
The two signals may express different intentions.
The sitemap includes the URL, while noindex expresses an indexing directive.
It is therefore worth checking whether both reflect what you actually want.
Limits
This relationship does not establish whether Google or another search engine will or will not index the page.
TrustyRunner is simply connecting the two signals it observed.
Action
Decide which intent you want to express.
If you intend to keep noindex, check whether keeping the URL in the sitemap still matches the structure you want to declare.
If you no longer want the URL to carry noindex, review the configuration that generates the directive.
Verify
A new scan should show a sitemap/noindex relationship consistent with the decision you made.
Observed canonical differs from the final URL
Observed
TrustyRunner observed a canonical pointing to a different URL from the final URL reached during the scan.
Why check
The canonical and final URL may represent different identities.
That can be intentional, but it is worth reviewing when you want to understand which URL you are declaring as the main reference.
Limits
A canonical that differs from the final URL is not automatically incorrect.
TrustyRunner cannot determine which URL a search engine will ultimately choose as canonical or whether the observed relationship matches your intended strategy.
Action
Check that the observed canonical really represents the URL you want to use as the main reference.
If the difference is intentional, there is no need to change it simply because the two URLs do not match.
If it is not intentional, review the markup or configuration that generates the canonical.
Verify
A new scan should show a canonical/final-URL relationship consistent with your intent.
Request ends with an HTTP 4xx or 5xx response
Observed
TrustyRunner observed a request ending with an HTTP response in the 4xx or 5xx range.
Why check
If the URL is expected to remain available, this type of response deserves review.
In other cases it may be entirely intentional.
Limits
The HTTP status does not automatically explain the cause or mean that the URL must be restored.
Different responses — such as 404, 403, 429, or 5xx — have different meanings and need to be interpreted in context.
Action
First determine whether the URL is supposed to remain available.
If it is, investigate the response and consider restoring the destination where appropriate.
If the URL should no longer be used, check instead whether sitemap entries, links, or other observed references should be updated.
If the status is intentional, no change may be needed.
Verify
A new scan should show a final HTTP status consistent with the decision you made.
URL encountered during the scan but not observed in acquired sitemap data
Observed
TrustyRunner requested a URL while exploring the site but did not observe it in the sitemap data acquired during the scan.
Why check
If that URL is intended to be declared in the sitemap, the relationship is worth reviewing.
In other cases its exclusion may be entirely intentional.
Limits
TrustyRunner is not stating that the URL is absent from every sitemap on the site.
The conclusion applies only to the sitemap data acquired during that scan.
Limits in sitemap discovery, document size, or the amount of data analyzed may make coverage partial.
Action
First decide whether the URL should actually be included in the sitemap.
If it should, review the sitemaps you manage and their configuration.
If you intentionally keep it out of the sitemap, the relationship may already match your intent.
Also check whether TrustyRunner reports partial coverage before making changes.
Verify
A new scan will acquire sitemap data again and can show whether the relationship has changed.
Even then, “not observed in acquired data” does not automatically mean “absent from every sitemap.”
Sitemap URL not observed during site exploration
Informational
Observed
TrustyRunner found a URL in acquired sitemap data but did not observe it among the requests made while exploring the site.
Why check
This can be useful context, particularly if you expected that URL to be discovered and reached during the scan.
Limits
This is not automatically a problem.
The difference may result from internal linking, the portion of the site covered by the scan, crawl depth, or simply the limits reached during the scan.
A URL not being requested does not mean that it is unreachable or defective.
Action
This relationship does not automatically require a fix.
If it is unexpected, you may want to check:
- how the page is linked from the rest of the site;
- whether it falls within the part of the site you expected the scan to explore;
- whether TrustyRunner reports partial coverage;
- whether you still intend to keep that URL in the sitemap.
Verify
A new scan may show a different relationship if internal linking, the portion of the site covered by the scan, or achieved coverage changes.
If the URL is still not observed during site exploration, the result remains contextual information rather than automatic evidence of a problem.
Verify with a new scan
After reviewing sitemaps, redirects, canonicals, or URL availability, run a new scan and compare the observed relationships with what you intended. If coverage is partial, a relationship that no longer appears may simply fall outside the acquired data. Check coverage as well before treating the review as complete.