Broken links and dead buttons on your page

1. Replace placeholder href="#" and javascript:void(0) buttons

Website templates come with buttons pre-filled with href="#" so the button looks clickable in a preview. If nobody replaces the # before publishing, tapping the button simply adds # to the address bar and jumps the visitor to the top of the page.

1. Right-click the button or menu item that does nothing and click Inspect (or run our free check at kortaga.com/check, which lists every dead link on your home page).
2. Look at the <a> or <form> tag in the Elements panel. If you see any of these patterns, the button has no destination:<a href="#">Book an Appointment</a> <a href="">View Menu</a> <a href="javascript:void(0)">Call Us</a> <form action="#">...</form>
3. Point the link at a real page, phone number, or email address so it works even if third-party scripts are blocked:<a href="/book">Book an Appointment</a> <a href="tel:+19165550199">Call (916) 555-0199</a> <a href="mailto:hello@example.com">Email Us</a>
4. If the element triggers an on-page menu or modal via JavaScript rather than navigating to a URL, use a real <button type="button"> element instead of an <a href="#"> tag, and verify that its click handler actually opens the panel.

2. Repair internal links that return 404 or 500

Renaming a page in WordPress, Squarespace, Wix, or Shopify (for example, changing /services to /our-services or replacing a PDF menu file) breaks every menu item and button that still points at the old address.

1. In your CMS navigation editor (such as Appearance → Menus in WordPress or Navigation in Shopify and Squarespace), click each header and footer link and confirm that it resolves with HTTP status 200 rather than 404 Not Found.
2. Update any custom URL menu items so they select the live page directly instead of a hardcoded old slug, or add a 301 redirect from the old path to the new path.
3. Check downloadable PDF links (such as restaurant menus or price sheets): when you upload a new file into your media library, update the button's href to the new file URL so visitors do not hit a deleted attachment.

3. Clear sticky overlays and size tap targets for phones

Sometimes a link has the right URL, but a visitor on a phone still cannot tap it because an invisible container, sticky header, or chat widget is sitting on top of it, or the button has no accessible label or tap area.

1. Open your page in Chrome or Firefox Developer Tools (F12), toggle the Device Toolbar (Ctrl+Shift+M or Cmd+Shift+M), and set the screen width to 390 px.
2. Right-click the button you cannot tap on a phone and choose Inspect. If DevTools highlights a different element (such as a full-screen wrapper with position: fixed, a cookie banner, or a mobile drawer with opacity: 0 that forgot pointer-events: none or display: none), add pointer-events: none or display: none to the hidden overlay when closed:.mobile-menu[aria-hidden="true"] { display: none; pointer-events: none; }
3. Give every interactive link and button a tap area of at least 44 by 44 CSS pixels and a visible text label (or an aria-label on icon-only buttons) so phone thumbs and screen readers can activate it reliably:nav a, button, .btn { min-height: 44px; min-width: 44px; display: inline-flex; align-items: center; }

These steps follow MDN's guides on The Anchor element (<a>) and CSS pointer-events, and the W3C's WCAG 2.1 Understanding Success Criterion 2.5.5: Target Size, read 28 October 2026.

If you would rather we write it or repair it for you