A link can look correct in your newsletter draft and still lead to a typo, an unexpected redirect, a page that does not work well on phones, or a login screen your subscribers cannot access. Use this repeatable pre-send checklist to check the destination URLs and then verify the links in a delivered test email.
Key Takeaways
- Check every destination URL in the final draft, including links in images, buttons, and the footer.
- An HTTP status check can reveal some availability problems, but it cannot confirm that the page is the right one or works for every visitor.
- Review redirects, mobile usability, and any login or access requirements.
- Send a test email and click its links: your email platform may rewrite URLs for tracking.
A Repeatable Pre-Send Link Checklist
Run these steps after the copy and links are final. If you change a URL afterward, check that link again.
1. Collect every link from the final draft
Review the email from top to bottom and note each destination. Include links on:
- Buttons and text calls to action.
- Linked images, logos, and product photos.
- Headlines and body copy.
- Social icons, navigation, and footer text.
- Unsubscribe and preference-management links, if your platform exposes them in the test.
Record the visible link text and intended destination together. For example: “View the spring collection” should lead to the spring collection page, not just to the shop homepage. This makes it easier to spot a valid URL attached to the wrong text or button.
2. Check each web destination's HTTP response
Use an HTTP status checker to request each http or https destination. A successful response, commonly a 200 status, is a useful signal: the server responded to the checker's request. It is not proof that the destination contains the intended content, is usable in a browser, or is accessible to every subscriber.
Check the result and the final destination, not just whether the tool reports “OK.” A link can return a successful page that is an error screen, the wrong product, or a generic homepage. Some sites also treat automated requests differently from ordinary browser visits. A checker may be blocked, or its result may differ from what a subscriber sees.
A 3xx response indicates a redirect. Redirects can be intentional, but inspect where they lead. Confirm that the final page is expected, still uses HTTPS where appropriate, and has not gone through an old campaign page or unrelated domain. A redirect chain may work today and still be a sign that a destination needs updating.
For 4xx or 5xx responses, open the destination in a browser and investigate before sending. A 404 commonly means the requested page was not found; a 5xx response indicates a server-side problem. A checker can also report an error because a site blocks automated requests, so verify rather than assuming every reported failure is a broken subscriber link.
HTTP checks apply to web URLs. They do not validate mailto: or tel: links. Test those separately on a device or mail app that supports them.
3. Inspect spelling, URL details, and destination content
Compare each URL with the intended page. Look for misspelled hostnames, missing or extra characters, an incorrect path, and query parameters that were lost or altered. If a URL contains campaign or product parameters, confirm they are still present when required.
Then open the destination in a browser. Check that it shows the correct page and that the page's main action works. For example, a “Register” link should reach the intended event or registration flow, not merely a general events page. Do not treat a status check as a substitute for this content check.
4. Check mobile usability
Open key destinations on a phone or use a browser's mobile device view as an initial check. Confirm that:
- The page loads without horizontal scrolling or content covering the main action.
- Text is readable and buttons or links are practical to tap.
- The destination does not depend on a desktop-only interaction.
- A form, checkout, or sign-up flow can be completed on mobile if the email promises that action.
A page can return a normal HTTP response while being difficult to use on a small screen. Prioritize the landing pages linked from the main calls to action.
5. Confirm access and login requirements
Ask whether the expected subscriber can reach the page. If a destination requires an account, permissions, or an invitation, test it without the editor's privileged session, or use an appropriate test account. A page that opens for the newsletter owner may show a login prompt or an access-denied message to subscribers.
If the destination is intentionally private, say so clearly in the email and confirm that the intended audience has access. Do not send a test password or other credentials in the newsletter just to make a link appear usable.
6. Send and inspect a delivered test email
Send the finished draft to test inboxes, then open the received message. Click the important links from the email itself, including buttons and linked images. Check that the destination is correct and that any campaign parameters or expected action survive the click.
This step matters because email platforms may rewrite links for click tracking, security scanning, or other delivery features. The URL visible in the editor may not be the URL in the delivered message. A tracking link can be long or use a platform domain; that alone does not mean it is broken. What matters is whether clicking it reaches the intended destination without an unexpected warning, loop, or detour.
Where practical, check the test in more than one mail client or on both desktop and mobile. If your platform provides a plain-text version, review its links too. Do not rely only on clicking links inside the editing interface.
A Simple Link Log
For a repeatable review, use a small table in your campaign notes:
| Email text or element | Intended destination | HTTP check and final URL | Browser and mobile check | Delivered test checked |
|---|---|---|---|---|
| Shop the sale | Sale landing page | Pass; expected destination | Pass | Pass |
| Read the guide | Guide page | Redirect reviewed | Pass | Pass |
| Register now | Event registration | Access requirement checked | Pass | Pass |
Mark a result as unresolved if the checker is blocked or the destination cannot be tested. Follow up with the site owner or campaign contact rather than treating an uncertain result as a pass.
Common Mistakes
- Checking only the status code: A successful response does not confirm the correct page or working content.
- Ignoring redirects: A redirect may lead somewhere different from the link's promise, even if it ends on a successful page.
- Testing while logged in: Your session may hide a login requirement or access restriction that subscribers will encounter.
- Skipping the delivered email: The platform can rewrite links after they leave the editor.
- Checking only text links: Buttons, images, logos, and footer links can all point to the wrong place.
- Assuming every checker failure means the link is broken: Some sites block automated requests. Verify the result in a browser and, where appropriate, investigate with the site owner.
- Changing a URL after review: A last-minute edit can introduce a new typo or remove a needed parameter. Recheck changed links.
Best Practices
- Make link review part of the final approval process, after copy and destinations are stable.
- Prioritize the primary call to action and any time-sensitive campaign links, while still checking the entire email.
- Keep the link text specific enough to set a clear expectation about the destination.
- Test important landing-page actions, not just whether the page loads.
- Record unresolved results and who will verify them; do not silently mark them as passed.
- Repeat the delivered-email check whenever the email platform, tracking settings, or destination URLs change.
Conclusion
To test links in an email before sending, check each final destination, inspect redirects and page content, confirm mobile usability and access, and click the links in a delivered test email. The combination catches problems that a status check alone cannot.