How to export and share a website link-audit report that leads to fixes

What makes a link-audit report actionable?#

An actionable report connects evidence with the change someone needs to make. A list of 404 addresses is a starting point, but editors also need source pages, anchor text and the intended replacement. Developers need the observed behavior and enough context to reproduce a server or redirect issue.

Write the report for the person who will act on it. Group repetitive template problems and separate uncertain request failures from confirmed missing resources. Add an intended fix where you have verified it, and leave an investigation task where the cause is still unclear.

Document the audit scope before exporting#

Record the starting URL, scan date, selected page cap and important exclusions. Explain whether the crawl reached the selected cap and whether any sections were inaccessible. This information determines what the recipient can reasonably conclude from the report.

A clean report only means that no relevant issues were observed within its checked scope and conditions. It does not certify every website URL or every future request. Preserve the distinction between checked pages, discovered destinations and known gaps so the handover remains accurate.

• Starting URL and intended site section
• Date of the scan and relevant release context
• Selected page cap and whether coverage was limited
• Robots.txt or authentication exclusions
• Known issues that still need manual investigation

Export the report and keep backups separate#

Paid Linky plans include whole-site report exports. Use the export option for a completed whole-site audit when you want to hand findings to an editor, developer or client. Check the exported result before sending it so that its contents match the task you intend to delegate.

Import/export backups serve a different purpose: preserving supported local data for recovery. Do not describe a shared report as a restorable backup unless it is actually the backup output. Keep the appropriate file for each workflow and verify your expectations before clearing a browser profile.

1. Run a whole-site audit and review its coverage.
2. Verify important findings and assign sensible categories.
3. Export the report using the paid export workflow.
4. Add scope notes, owners and proposed actions to the handover.
5. Review sensitive information before sharing and confirm receipt.

Group findings by the work required#

Separate source edits from server changes. Updating a reference in an article and repairing a redirect loop have different owners. For repeated failures from a shared navigation element, create one component-level repair task with representative source examples.

Prioritize the visitor journeys affected. A broken installation document or contact link should be easy to identify in the handover. Give lower-priority archives a clear place in the queue without allowing them to obscure urgent tasks. Keep uncertainty visible when a result may reflect temporary access protection.

Protect private URLs and exported information#

A report can contain paths from authenticated pages, customer identifiers, document names or query parameters. Review these before sending the file outside the intended team. Share the minimum evidence needed to reproduce and repair the problem.

Remove access tokens and credentials from a handover. When a private destination is necessary for the task, use an approved sharing channel and describe the required access rather than distributing secrets. Treat backups with additional care because they may preserve more local context than a focused report.

Close the loop with verification evidence#

After repairs are published, test the affected source links and rerun an appropriate audit. Record what was verified and when. A task should not be closed merely because a new URL was pasted into a spreadsheet or someone reported that a server rule changed.

Keep unresolved findings in a separate section with the next investigation step. If a repair depends on an external provider, document that dependency. A concise verified result, supported by the original scope and relevant evidence, is easier to maintain than a report that mixes completed fixes and untested suggestions.

• Original finding and intended correction
• Responsible owner and publication status
• Live source and destination verification
• Follow-up scan date and scope
• Outstanding exceptions or external dependencies

Frequently asked questions#

Put this workflow into practice

Read the related Linky documentation for the product controls and limits used in this article. Contact support if a result requires further investigation.