IndexLane Broken Link & Redirect Auditor

A moved page. An old staging URL in the footer. A link that loads, but lands in the wrong place. Small problems like these are easy to leave behind when a site changes.

IndexLane helps you find them, see where to edit them, and check the result. Scan the WordPress content you choose, review the links that need attention, and replace a URL from the results page or open its WordPress editor. Turn on scheduled checks when you want help keeping up with new problems.

It’s free, runs inside WordPress, and needs no account or external scanning service.

Find more than a 404

Check internal links for broken pages, redirects, and redirect chains. Add your old domains to find migration leftovers; common staging and development domains are flagged too, without contacting those sites.

A page can return a successful response and still deserve a look. IndexLane also flags a different canonical URL, noindex directives, meta-refresh redirects, missing linked sections such as #pricing, a link that uses a different scheme than the site address, and a link whose trailing slash differs from the address WordPress serves for it. These appear beside the HTTP result under Page intent, so you can judge what needs changing.

Go straight to the source

A broken footer link might live in one menu, even if visitors see it on every page. IndexLane shows the source where the link is maintained, with its link text and an editing link.

Choose from published posts, pages and public custom post types; classic menus; Navigation blocks; synced patterns; block templates and template parts; and assigned block widgets. You decide which areas to check.

Fix a URL without hunting through every page

Under Fix links, enter a replacement URL and select Preview changes. Review the affected sources and expand the full before-and-after values, then apply the repair. A redirect’s final URL may be offered as a suggestion; you choose whether to use it.

When the scan already suggests a replacement for several URLs, select Review suggested fixes, keep or clear each suggestion, and apply the ones you keep as a single batch. A source holding more than one suggested URL is written once, and one Undo restores the whole batch.

Repairs change matching stored link attributes and supported block link settings. Recent repairs keep an undo history. Undo skips sources edited since the repair, so it won’t discard your later work.

Theme-file templates, menu items whose URLs follow a WordPress page or other object, and unsupported storage need their own editors. IndexLane does not create redirects.

Check that your changes helped

Save a completed scan before making changes, then select Check fixes against saved scan. The comparison shows new, changed, resolved, and still-present issues in the same selected scope. Download it as a CSV for your records or a client handover.

Content coverage also shows which scanned pages have few incoming links from the sources you selected. It’s a useful starting point for review, not proof that a page has no links anywhere on the site.

Keep an eye on new problems

Choose an hourly, twice-daily, daily, or weekly check. After the first complete check sends a summary, later emails report newly detected or resolved problems. Acknowledge a known issue to remove it from the attention count and change notifications while keeping its evidence in reports.

Schedules use WP-Cron and depend on site visits or your server’s cron setup. If a check reaches its request limit, the result is marked partial and is not used to claim that earlier problems are fixed. Status is available on the WordPress dashboard and in Site Health.

Start with one scan

1. Open Tools -> Redirect & Internal Link Auditor and choose the areas to check.
2. Select Start scan and keep the page open. You can pause and return later, or increase the request allowance if needed.
3. Review Problem URLs and Link details. Save the results for comparison before making changes.
4. Preview a replacement under Fix links, or use an editing link to make the change yourself.
5. Run Check fixes against saved scan and review the comparison.

The illustrated walkthrough shows a broken footer link and an outdated service URL on a small demo site.

See what the reports include

These sample CSVs use fictional site data:

• Problem URLs: destinations that need attention and the sources linking to them.
• Link details: individual links, editing locations, HTTP results, and page intent.
• Content coverage: incoming and outgoing links within the selected sources.

Downloads reuse completed scan results without making another scan. You can also download or upload a saved scan as site-specific JSON.

Learn more at IndexLane. Developers can add stored-source adapters through the filter documented in the project README.

WP-CLI

Agencies and deployment scripts can run the same checks without a browser:

• wp indexlane scan --content-scope=all --format=table checks the site and lists the URLs that need attention.
• wp indexlane fix --from=OLD --to=NEW --dry-run previews an exact replacement; the same command without --dry-run applies it.
• wp indexlane fix-suggested --dry-run previews every suggested replacement as one batch; add --yes to apply it.
• wp indexlane undo restores the most recent repair, and wp indexlane repairs lists the recorded history.

Data handling

Scans run on demand from WordPress admin through authenticated AJAX batches, or from the scheduled check and WP-CLI without a browser. Each batch processes at most five stored sources and makes at most five outbound HTTP requests. The active or completed browser scan is stored in a per-user WordPress transient for up to 24 hours after its last activity. Abandoned sessions expire automatically, and completed-session downloads reuse the exact displayed results without scanning again.

An administrator may explicitly save one site-specific scan in their WordPress user options. It remains until it is replaced or deleted. Portable saved-scan JSON is limited to 20 MB and validated against the exact supported format and current site URL before upload.

A repair writes only the stored link values you confirmed, through the normal WordPress post, menu-item, and block-widget APIs, and records the previous values in a bounded site option so the repair can be undone. The history keeps up to 25 repairs within an 8 MB total budget, including before-and-after values and their metadata. Older entries are removed as the history fills up. Acknowledged URLs are stored once per site, and the scheduled check stores its configuration, its comparison set, and the last result summary.

The plugin does not create an account, call an IndexLane service, or add frontend tracking.

Limits

This is a stored-source scanner, not a rendered-site crawler. It reads only the selected built-in adapters or adapters registered by other plugins. It does not execute shortcodes, scan arbitrary metadata, render templates, inspect unsupported page-builder storage, or crawl frontend pages.

A scan can snapshot at most 100,000 stored sources. Block widgets are included only when their stored block structure is available and the widget is assigned to a widget area.

Final same-site responses are inspected up to 256 KB. Bodies are never retained and intent checks add no requests. Partial responses and bounded fragment inventories cannot prove an unseen fragment is missing. Checks inspect stored HTML targets, not JavaScript-generated content; fragment-only links within their source page are outside the scan. No canonical target or meta-refresh target is fetched.

Each AJAX batch makes at most five outbound HTTP requests. A session begins with an explicit limit of 250 actual requests, including redirect hops. When that limit is reached, the administrator can increase it by 250 and continue without losing progress or recording incomplete results.

A repair handles one linked URL at a time, including its fragment. It is limited to 500 stored sources and must fit within the 8 MB undo budget. Changes made after the preview require a fresh preview. Undo is available while the repair remains in history and the stored values still match. Keep your normal site backups.