A website can appear ready for deployment while still containing broken navigation, outdated redirects, orphan pages, and links that cannot be used by search engines or assistive technology.
These problems are easier to fix before launch than after users begin reporting them.
A link audit should therefore be part of the deployment process, especially for documentation websites, online stores, SaaS applications, and websites containing hundreds of pages.
This guide provides a practical link-audit checklist developers can use before releasing a website.
Why Link Auditing Matters
Links affect several parts of the user experience.
They help visitors:
- Move between related pages
- Find documentation
- Complete registration or purchasing steps
- Return to important sections
- Discover supporting information
- Understand the structure of a website
A broken or misleading link interrupts that journey.
Link problems can also affect automated systems. Search crawlers, accessibility tools, monitoring services, and testing software all depend on predictable URLs and valid HTML.
1. Create an Inventory of Important URLs
Begin by listing the pages that must work correctly at launch.
These usually include:
- Homepage
- Main category pages
- Product or service pages
- Documentation
- Registration and login pages
- Contact page
- Privacy and policy pages
- Support resources
- Download pages
- Error pages
Do not rely entirely on the navigation menu. Some important pages may only be accessible through buttons, article links, email campaigns, or application workflows.
Compare the URL inventory with the routes defined in your application.
If a route exists but no page links to it, determine whether that route is intentionally hidden or accidentally orphaned.
2. Verify Every Navigation Link
Test the main navigation on desktop and mobile layouts.
Check:
- Logo link
- Main menu
- Dropdown menus
- Mobile menu
- Breadcrumbs
- Footer links
- Account navigation
- Pagination
- Previous and next links
Confirm that every navigation item leads to the expected destination.
A link can return a successful HTTP response while still being incorrect. For example, a pricing button may load the homepage because of an incorrect relative path.
Testing should therefore verify both the response and the destination content.
3. Check HTTP Status Codes
A working page commonly returns a successful status such as 200 OK.
You can inspect a URL from the terminal:
curl -I https://example.com/page
Review responses such as:
-
200 OK— The request succeeded. -
301 Moved Permanently— The resource has a permanent replacement. -
302 Found— The redirect is temporary. -
404 Not Found— The requested resource was not found. -
410 Gone— The resource was intentionally removed. -
500 Internal Server Error— The server encountered an error. -
503 Service Unavailable— The service is temporarily unavailable.
Do not classify every non-200 response as a defect. A redirect may be intentional, and an authentication page may return a different result depending on the current session.
Evaluate each response in context.
4. Remove Redirect Chains
A redirect chain occurs when one URL redirects to another URL, which then redirects again.
For example:
/old-guide
→ /documentation
→ /docs
→ /docs/getting-started
Visitors eventually reach the correct page, but the unnecessary steps increase complexity and create more opportunities for failure.
Update internal links so they point directly to the final destination:
/docs/getting-started
Keep required redirects for old external URLs, saved bookmarks, and previously published pages. Internal navigation should generally use the current canonical destination.
5. Find Orphan Pages
An orphan page has no meaningful internal links pointing to it.
The page may exist in the application and appear in a sitemap, but visitors cannot reach it through normal navigation.
Common causes include:
- New pages published without updating older content
- Menu changes
- Category restructuring
- Removed related-content sections
- Migration from another platform
- Incorrectly generated routes
For every orphan page, decide whether it should be:
- Linked from a relevant page
- Added to a category or documentation menu
- Combined with another resource
- Redirected
- Removed
- Kept private intentionally
Do not add random links merely to make the orphan-page report disappear. Every internal link should make sense to a reader.
6. Test Relative and Absolute URLs
Relative URLs can break when content moves to a different directory.
For example:
<a href="../setup">Setup guide</a>
The destination depends on the location of the current page.
A root-relative path is often easier to maintain within the same website:
<a href="/docs/setup">Setup guide</a>
Absolute URLs are useful when linking to another domain:
<a href="https://example.com/docs/setup">Setup guide</a>
Check that development, staging, and production URLs have not been mixed.
A common deployment mistake is publishing links that still point to:
localhost- A private IP address
- A staging subdomain
- A temporary preview URL
- An internal development hostname
Search the production build for these values before deployment.
7. Verify JavaScript-Generated Links
Single-page applications often create navigation with JavaScript components.
Make sure the final HTML uses a real link when the element is intended for navigation:
<a href="/documentation">Documentation</a>
A clickable element using only an event handler may work with a mouse but create problems for keyboards, crawlers, browser features, and assistive technology.
Buttons should normally perform actions. Links should normally navigate to locations.
Test JavaScript-generated navigation with:
- Keyboard controls
- JavaScript temporarily disabled where appropriate
- Browser developer tools
- Accessibility inspection
- Direct URL loading
- Back and forward browser buttons
Also confirm that opening a route directly does not return a server-side 404 error.
8. Review Anchor Text
Anchor text is the visible text of a link.
It should explain what the visitor will find after clicking.
Weak examples include:
- Click here
- Read more
- This page
- More information
- Learn more
These phrases may be acceptable when surrounding context is extremely clear, but descriptive anchor text is generally more useful.
Better examples include:
- API authentication guide
- Database migration checklist
- React performance documentation
- Account recovery instructions
Avoid repeating the same keyword unnaturally across every page. Anchor text should describe the destination in the context of the current sentence.
9. Check Links Inside Images and Buttons
Links are not limited to ordinary text.
Audit clickable:
- Logos
- Product cards
- Images
- Icons
- Call-to-action buttons
- Social icons
- Download buttons
- Carousel items
Confirm that the clickable area matches the visible interface.
An image used as a link should include useful alternative text when the image communicates the destination. Decorative images should not create confusing links for assistive technology.
Do not place multiple overlapping links over the same interface element.
10. Test External Links Separately
External websites can change without notice.
A page that worked when the article was published may later be deleted, redirected, or replaced with unrelated content.
Review external links for:
- Broken destinations
- Unexpected redirects
- Expired domains
- Changed ownership
- Security warnings
- Outdated documentation
- Resources requiring new authentication
- Content that no longer supports the original statement
Do not send automated requests too aggressively. Respect the destination server and apply reasonable limits when running a crawler.
Some websites block automated requests even though the page works normally in a browser. Verify suspected failures manually.
11. Check New-Tab Behavior
Opening external links in a new tab is not always necessary.
If you use target="_blank", apply the appropriate security relationship:
<a
href="https://example.com"
target="_blank"
rel="noopener noreferrer"
>
External resource
</a>
Use new tabs consistently and only when they provide a clear benefit.
Visitors should remain in control of navigation. Avoid opening multiple tabs automatically.
12. Test Download Links
Download links require additional checks.
Verify that:
- The file exists.
- The filename is understandable.
- The file type is expected.
- The file size is reasonable.
- Access permissions are correct.
- The server sends an appropriate content type.
- Old versions are clearly identified.
- Users are warned before downloading large files.
If a download requires authentication, test both authorized and unauthorized sessions.
Never publish private configuration files, database backups, environment files, credentials, or internal logs as downloadable resources.
13. Review Canonical Destinations
A website may expose the same content through several URLs.
Examples include:
- URLs with tracking parameters
- Alternate capitalization
- Trailing-slash variations
- Print views
- Filtered category pages
- HTTP and HTTPS versions
- Duplicate application routes
Choose a preferred destination and make internal links consistent.
Do not create conflicting signals by linking internally to one version while identifying another version as canonical.
14. Add Link Testing to Continuous Integration
Manual testing is valuable, but repeated automated checks can catch problems before deployment.
A continuous integration workflow can:
- Build the website.
- Start a local preview.
- Crawl internal pages.
- Collect links.
- Check response codes.
- Detect redirect chains.
- Report broken destinations.
- Fail the build when critical links break.
Not every external failure should stop a deployment because third-party websites may be temporarily unavailable.
Separate critical internal failures from external warnings.
15. Test the Custom 404 Page
Visitors will eventually request a page that does not exist.
A useful 404 page should:
- Return the correct 404 status
- Explain that the page was not found
- Provide a link to the homepage
- Offer navigation or search
- Match the website design
- Avoid automatic redirects
- Exclude misleading error messages
Do not return 200 OK for a missing page merely because a custom design is displayed. This can make automated systems believe that the missing URL contains valid content.
Pre-Deployment Link Checklist
Before releasing the website, confirm that:
- Main navigation works on desktop and mobile.
- Internal links point directly to current destinations.
- Important pages are not orphaned.
- Broken internal links have been fixed.
- Redirect chains have been reduced.
- Development URLs have been removed.
- JavaScript navigation uses appropriate link elements.
- Anchor text describes destinations clearly.
- External links have been reviewed.
- Download files and permissions are correct.
- New-tab links are implemented securely.
- Canonical destinations are consistent.
- The 404 page returns the correct status.
- Critical links are checked during continuous integration.
- Keyboard users can access every important link.
Final Thoughts
A link audit is not only an SEO task. It is part of quality assurance, accessibility, security, and user-experience testing.
Begin with important routes, inspect navigation, check status codes, remove unnecessary redirects, find orphan pages, and verify JavaScript-generated links.
Automate repeatable checks where possible, but manually review context and destination quality.
A website with dependable navigation is easier for visitors, developers, and automated systems to understand.
Top comments (1)
Nice checklist. One thing I’d add is that link health is less of a deployment task and more of a continuous maintenance task. New pages, content updates, and URL changes slowly introduce broken links over time, even if the initial release is clean.
That’s why I like treating link validation as a scheduled quality check alongside CI, rather than something that only runs before a release. It catches content drift just as effectively as deployment issues.