Separate two different inventories
An HTTPS website can still contain navigation links beginning with HTTP. It can also request images, scripts or other resources over HTTP. Keep these findings in separate lists: following a link to another top-level page is different from loading insecure content inside the current page. MDN documents this distinction in its mixed-content guidance.
Start with a defined scope: the public hostnames, languages and page types you own. Record any excluded login areas or external systems. A report covering only the homepage cannot establish that product pages, article templates and the mobile menu use the same addresses.
Record the source, not just the destination
For each outdated link, collect the source page, visible label, raw href, resolved destination and location in the interface. Include links in the footer, breadcrumbs, language selector and reusable promotional cards. If a crawler exports only broken destinations, enable or obtain its incoming-link details before assigning fixes.
Inspect a sample in both the returned HTML and the rendered page. A link may come from stored article content, a shared component or a script. Group findings by the component that generates them rather than assigning hundreds of identical footer findings as separate editorial tasks. Keep resource requests in their own network-log inventory.
Verify HTTPS before replacing addresses
Test the proposed HTTPS destination directly. Confirm that its certificate is accepted, the expected page loads and its content matches the link's promise. Preserve meaningful paths and parameters. Replacing the protocol alone does not fix a deleted page or a link that points to the wrong language.
Google recommends consistent internal links to the preferred canonical URL. Once that destination is established, update the source link to it. Do not use a blanket database replacement without a backup and a scoped preview: text examples, external integrations and encoded data may need different handling. A redirect remains useful for old inbound links, but it need not be the route used by newly corrected navigation.
Worked example: a shared footer and an old article
Consider an illustrative bilingual website with 40 pages linking to http://example.com/contact/ through one footer component, plus two old articles containing separate HTTP links. The inventory contains 42 occurrences, but the implementation work starts with three sources: one component and two article bodies. These numbers describe the example, not measured results from a customer.
Suppose the Arabic footer should lead to /ar/contact/ while the English footer should lead to /en/contact/. Replacing every occurrence with one HTTPS address would remove the protocol issue while introducing a language error. Map the intended destination per language, update the component logic and edit the two article links individually. Test both menus after the change.
Close the audit with reproducible checks
Repeat the same crawl scope and compare remaining occurrences with the original inventory. Check representative desktop and mobile navigation by clicking through. Review the browser network log separately for insecure resources; a clean navigation-link report does not prove that every embedded resource is secure.
Save the before-and-after link list, changed component or content identifiers, test date and unresolved exceptions. Use these findings as the input to your website-audit action list, with an owner for each remaining source. Completion means the selected links now resolve as intended; it does not by itself establish that Google has recrawled the pages or changed their rankings.