Internal broken links (404s) across docs.turbodocx.com — SEO crawl errors

Summary

Ahrefs Site Audit flags a cluster of internal links on docs.turbodocx.com pointing to pages that 404. These are page slugs/paths that were likely renamed or removed without updating the linking pages or adding redirects. All verified still live as of this report.

Broken internal links (source page → dead target)

/docs/Integrations, /docs/Templates/best-practices, /docs/Templates/bulk-generation, /docs/Templates/template-management, /docs/Templates/version-control, and /docs/Webhooks/webhook-configuration account for most of the fan-out — fixing/redirecting these 6 target paths (or updating the ~9 source pages that link to them) clears the bulk of this list.

Also noted (likely not actionable, lower priority)

Several docs SDK pages (/docs/SDKs/webhooks-ruby, /docs/SDKs/deliverable-ruby, /docs/SDKs/ruby, /docs/SDKs/quote-ruby, /docs/SDKs/java) link out to rubygems.org/gems/turbodocx-sdk and search.maven.org/artifact/com.turbodocx/turbodocx-sdk, both returning 403 to the Ahrefs crawler. These look like bot-blocking on the package registries' side rather than genuinely dead links — worth a manual spot-check in a browser, but likely no action needed.

Suggested fix

1. For each dead target: either the page was renamed (add a redirect / fix the link to the new slug) or the content never existed (remove/update the link or write the missing page).
2. Check docs.turbodocx.com/api and docs.turbodocx.com/integrations/hubspot — dotcom links to these paths but no matching docs route exists; coordinate with the DotCom repo fix.

Related: #101 (Font Awesome kit 403 site-wide)

Start by locating the documentation routes and the source pages listed in the issue, then verify each dead target and determine whether it was renamed, removed, or never existed. Update the affected links or redirects, check the /api and /integrations/hubspot paths with the DotCom repository, and rerun a link crawl to confirm the listed 404s are resolved.