How do you find broken links hidden inside PDFs and JavaScript menus?

Why a normal crawl misses these links

A conventional crawler fetches the HTML of a page and extracts links from anchor tags, link elements, image maps, and source attributes. Anything that is not present in that raw response is invisible to it. Menus built by JavaScript after the page loads, content pulled in by a script when a tab is opened or the visitor scrolls, links stored in click handlers or data attributes, and every URL inside a PDF, a word processing document, or a spreadsheet fall outside that view. So do links in email templates, in embedded help content, and inside iframes hosted on another domain.

The consequence is a report that can show zero errors while real failures sit in plain sight for visitors. A download-our-guide PDF may contain links to a domain the company abandoned years ago. A footer assembled by a script may still reference pages deleted in the last redesign. A product page's tabbed specifications may link to a discontinued support page. Nobody notices until a customer does, and the audit, having never seen those links, has nothing to say about them. Related: A Pre Launch Link Checklist

Keep reading: When to Run a Full Link Audit, How a Site Crawl Actually Works, Reading a Redirect Chain Map. See how DeadLinkr helps you on demand link and redirect audits for seo.

Getting the JavaScript-built links

The tool for script-driven navigation is a rendered crawl, where a headless browser executes the page's JavaScript before links are extracted. Rendering is slow and resource heavy, so use it deliberately rather than everywhere. Crawl a sample of each template type both raw and rendered and compare the link counts. If the rendered version of a template finds substantially more links, that template needs rendering in the audit; if the counts match, the raw crawl is fine for it. Then extract URLs from click handlers and data attributes by scanning the rendered DOM, since those never appear as anchors even after rendering. Related: When to Run a Full Link Audit

Two variables trip people up here. Some menus depend on state, such as a logged-in user or a dismissed cookie banner, and some depend on viewport, with a mobile menu that contains different links from the desktop one. Run the rendered crawl with a mobile viewport as well as a desktop one where the menus differ, and take a rendered screenshot of a few pages to confirm the crawler actually saw the expanded menu rather than a collapsed placeholder. Related: How a Site Crawl Actually Works

Extracting links from PDFs and other documents

PDFs carry links in two forms: link annotations that are clickable objects, and plain-text URLs that most viewers turn into clickable links automatically. An audit needs both. Parse the annotation objects to get the explicit links, then run a URL pattern over the extracted text to catch the plain ones. Common open source libraries and command line utilities handle each step. Word processing files and spreadsheets store their hyperlinks in internal relationship files that can be read the same way. The resulting URL list is then checked like any other list, with the source document recorded next to each URL.

Prioritize by what people actually open. Download events in analytics or requests in server logs tell you which documents are live in practice. A brochure from years ago that nobody downloads may be better removed than repaired. Be aware that search engines index PDFs and follow their links, so a document pointing at a domain that has since been taken over by someone else is a real problem, not a cosmetic one, even if the document seems forgotten.

Fixing the sources and keeping them in scope

For script-built navigation, fix the data source rather than the rendered output: the menu configuration, the JSON file, or the CMS menu builder that the script reads. For PDFs, regenerate the document from its original source file with the links corrected. If the source is lost, PDF editors can rewrite links, but the process is fragile and easy to get wrong, and an HTML page is frequently a better replacement than a patched document. For links hardcoded in templates or in application code, search the codebase for absolute URLs and fix them at the source before redeploying.

Then make these sources permanent parts of the audit rather than a one-time effort. Collect every PDF the crawl discovers by extension or content type and check its links on the same schedule as pages. Rerun the rendered crawl on the identified templates each quarter. Keep a scan of the codebase for hardcoded URLs as part of the release checklist. And when the site renames or removes pages, remember that old links inside documents still point at the old addresses, so the redirect rules must protect those paths too. Related: How Broken Links Waste Crawl Budget