How do you stop broken links coming back?
Lock the slug so URLs stop changing when titles change, check inbound links before deleting any page, insert links with the CMS picker rather than typing them, and use root-relative paths that survive a domain change. Prevention here is a process problem rather than a technical one.
Understand where they come from
Almost all broken internal links on a small business site trace back to five causes:
Renaming a page. Someone edits the title, the CMS regenerates the slug, and every existing link to it breaks silently.
Deleting a page. Removed without checking what pointed at it.
Hand-typed links. A missing character, a wrong folder, a copied URL from a staging environment.
Changing structure. Moving a page under a new parent changes its URL in most systems.
Copying content between pages. Links copied along with the text, still pointing at whatever they pointed at originally.
Each has a preventive fix that costs nothing.
Lock the slug
The single highest-value change is to stop URLs changing when titles change. Most content systems have a setting or plugin for this. Once a page is published, its URL should be treated as fixed unless there is a real reason to change it — and if it changes, a redirect goes in at the same moment.
Never delete without checking inbound links
Before removing any page, run a search for its URL across the site. Most systems allow a search of post content; a crawl report also lists inbound internal links per URL.
If anything links to it, decide where those links should go before the page disappears, not after.
Link by selection, not by typing
CMS editors have a link picker that inserts the correct URL from a list of existing pages. Typing URLs by hand is where typos and staging-domain leftovers come from. Make the picker the standard practice for anyone editing the site.
Use relative or root-relative links internally
Root-relative links (/services/plumbing) survive a protocol change and a domain change, and cannot accidentally carry a staging hostname into production. Absolute internal links with a full domain are a common source of breakage after any migration.
Put the checks in a routine
For a Pearland business with one or two people editing the site, a light monthly rhythm is enough:
- Run a crawl, review broken links
- Check Search Console's not-found report
- Fix at source, add redirects where a page genuinely moved
- Note anything that recurs and address the habit behind it
That last step is what turns a recurring chore into a shrinking one.
Add a 404 page that does something
Some links will always break — from other sites, from printed material, from bookmarks. A useful 404 page recovers those visitors:
- Say plainly that the page does not exist
- Link to the main services and the contact page
- Include the phone number
- Return a real 404 status, not a 200 with an error message on it
That last point is worth checking, because a soft 404 is invisible in every report you would use to find the problem.
Frequently asked questions
Why do broken links keep coming back?
Five editing habits recreate them: renaming pages so the slug regenerates, deleting without checking inbound links, typing URLs by hand, restructuring pages, and copying content with its links attached.
What is the single most effective prevention?
Locking the slug so URLs stop changing when titles change. Once a page is published its URL should be fixed, and if it must change, the redirect goes in at the same moment.
Should internal links be absolute or root-relative?
Root-relative. They survive protocol and domain changes and cannot carry a staging hostname into production, which is a common source of breakage after any migration.
What should I do before deleting a page?
Search for its URL across the site or check a crawl report's inbound link list, then decide where those links should point before the page disappears rather than after.
What makes a good 404 page?
Plain wording, links to main services and contact, the phone number, and — critically — a real 404 status code. A soft 404 returning 200 is invisible in every report you would use to find the problem.