JavaScript issues on websites
Menus, buttons, forms, scripts, and interactive pieces that fail because browser JavaScript is broken.
Read JavaScript issue troubleshootingBroken website triage
Available for contract web work at $55/hr
Fix My Broken Website: What to Check Before You Change Anything
When the site is already broken, the useful move is to protect the current state, reproduce the symptom, identify the affected business path, and fix the smallest verified cause.
Something broke
If you are searching for fix my broken website, the site probably does not need another generic checklist. It needs a careful first move. The page may look broken, a form may be failing, checkout may be stuck, WordPress may have changed after an update, or a script may be breaking only on one device.
The mistake is treating every broken-site issue like the same problem. A page with missing CSS, a checkout that cannot submit, a lead form that says success but sends nothing, and a site that redirects in a loop all need different checks. They also carry different business risk.
This guide is the focused child of Something Broke on Your Website. Use the parent guide to understand the broad symptom buckets. Use this page when you need a practical repair order and a cleaner handoff to a website fixer.
Related symptoms worth checking alongside this guide include something broke on your website, JavaScript issues on websites and forms and modals not working because real website problems often cross visual behavior, forms, scripts, tracking, and CMS layers.
If this article describes the symptom on your site, compare Parent Broken Website Guide and Website Fixes before turning the problem into a request.
If the first fix path is not quite right, Production Debugging may be the better service or skill page. You can also use Contact once you have the URL, symptom, timeline, and what should happen instead.
| Protect the current state first | Before making changes, capture what is happening now. That does not have to be complicated: take screenshots, record the failed action, copy the exact URL, note the browser and device, and write down the time you saw the issue. If the site has backups, staging, Git, hosting snapshots, or a recent export, identify what restore points exist before editing production. | Exact URL and affected page path, Screenshot or screen recording | Parent Broken Website Guide |
| Separate public risk from annoyance | A broken website does not always mean emergency. The right response depends on what the failure affects. A slightly awkward spacing issue on a low-traffic page is not the same as a dead lead form, broken checkout, indexable SEO page returning an error, or paid campaign page with a failed CTA. | Lead form or quote request path, Checkout, cart, booking, or payment flow | Parent Broken Website Guide |
| Use the symptom to pick the first tool | The first tool depends on the symptom. A layout problem usually starts with CSS inspection, template output, builder settings, and cached assets. A button or menu that does nothing usually starts with browser console errors, JavaScript order, plugin conflicts, or blocked scripts. A form failure starts with submission testing, email or CRM destination checks, validation, redirects, spam protection, and tracking. | Layout: CSS, template, builder, image constraints, responsive rules, Interaction: console errors, failed requests, script order, plugins, third-party snippets | Parent Broken Website Guide |
| Check the change timeline | Most broken-site repairs get easier when the timeline is honest. What changed within the last day, week, or release cycle? A plugin update can change markup or scripts. A cache plugin can serve mismatched assets. A theme update can overwrite style assumptions. A third-party widget can ship a breaking change without anyone touching your site. | CMS, plugin, theme, app, or extension updates, Page content, builder, menu, or template edits | Parent Broken Website Guide |
| Fix one layer and verify the user path | A broken-site fix is not done when the first visible symptom disappears. It is done when the user path works again. If the issue was a form, submit the form and confirm the destination. If it was checkout, test the cart and order path as far as safely possible. If it was a menu, check desktop and mobile. If tracking mattered, verify the event instead of assuming it fired. | Retest the exact URL and action that failed, Check affected mobile and desktop views | Parent Broken Website Guide |
| What to send when you want help | A strong repair request is short, specific, and evidence-based. It does not need a perfect diagnosis. It needs the broken URL, expected behavior, current behavior, affected devices, timeline, recent changes, and why the issue matters. | The broken URL, What should happen | Parent Broken Website Guide |
Protect the current state first
Before making changes, capture what is happening now. That does not have to be complicated: take screenshots, record the failed action, copy the exact URL, note the browser and device, and write down the time you saw the issue. If the site has backups, staging, Git, hosting snapshots, or a recent export, identify what restore points exist before editing production.
This matters because broken websites often get worse when people try several fixes at once. A cache purge, plugin rollback, page edit, DNS change, and script removal may each be reasonable in isolation, but together they destroy the trail. When the fix fails, nobody knows which change helped or hurt.
Capture before touching the site
- Exact URL and affected page path
- Screenshot or screen recording
- Device, browser, and logged-in/logged-out state
- Time the issue started or was noticed
- Recent plugin, theme, CMS, hosting, DNS, cache, content, or script changes
- Backup, staging, deployment, or rollback options
Separate public risk from annoyance
A broken website does not always mean emergency. The right response depends on what the failure affects. A slightly awkward spacing issue on a low-traffic page is not the same as a dead lead form, broken checkout, indexable SEO page returning an error, or paid campaign page with a failed CTA.
Sort the issue by business path first. If the site can still take leads, accept orders, load important pages, and track critical actions, the repair can be calmer. If the failure blocks revenue, paid traffic, organic landing pages, customer trust, or reporting, the first fix should stabilize the path that matters most.
Prioritize broken paths
- Lead form or quote request path
- Checkout, cart, booking, or payment flow
- Homepage or high-value service page
- Paid traffic landing page
- Organic page that earns impressions or clicks
- Tracking, CRM, or reporting handoff
- Visible layout issue that harms trust
Use the symptom to pick the first tool
The first tool depends on the symptom. A layout problem usually starts with CSS inspection, template output, builder settings, and cached assets. A button or menu that does nothing usually starts with browser console errors, JavaScript order, plugin conflicts, or blocked scripts. A form failure starts with submission testing, email or CRM destination checks, validation, redirects, spam protection, and tracking.
Server-level failures need a different lane: HTTP status codes, redirect chains, SSL mode, DNS records, hosting logs, Cloudflare cache, and whether the issue changes by network or device. Pulling a WordPress plugin is not helpful if the real issue is DNS or SSL; changing DNS is not helpful if a page builder section is hiding a button on mobile.
Match symptom to diagnostic lane
- Layout: CSS, template, builder, image constraints, responsive rules
- Interaction: console errors, failed requests, script order, plugins, third-party snippets
- Forms: validation, notifications, SMTP, CRM, webhooks, redirects, thank-you state
- Checkout: cart session, payment gateway, shipping/tax, JavaScript, plugin conflicts
- Tracking: GTM preview, GA4 DebugView, duplicate scripts, event triggers
- Infrastructure: DNS, SSL, redirects, cache, hosting logs, server status
Check the change timeline
Most broken-site repairs get easier when the timeline is honest. What changed within the last day, week, or release cycle? A plugin update can change markup or scripts. A cache plugin can serve mismatched assets. A theme update can overwrite style assumptions. A third-party widget can ship a breaking change without anyone touching your site.
If there is no obvious change, still look for hidden ones: automatic updates, hosting upgrades, expired SSL certificates, browser policy changes, ad or tracking snippets, CRM form edits, DNS changes, or a page builder saving different markup after a small edit.
Timeline clues
- CMS, plugin, theme, app, or extension updates
- Page content, builder, menu, or template edits
- Cache, CDN, Cloudflare, or optimization changes
- Tracking, pixel, chat, widget, iframe, or embed changes
- Hosting, PHP, SSL, DNS, redirect, or deployment changes
- CRM, form, email, payment, shipping, or API changes
Fix one layer and verify the user path
A broken-site fix is not done when the first visible symptom disappears. It is done when the user path works again. If the issue was a form, submit the form and confirm the destination. If it was checkout, test the cart and order path as far as safely possible. If it was a menu, check desktop and mobile. If tracking mattered, verify the event instead of assuming it fired.
This is where production debugging matters. Browser console errors, network requests, logs, cache behavior, plugin output, and tracking tools can show whether the fix actually reached the live visitor path.
Verification checks
- Retest the exact URL and action that failed
- Check affected mobile and desktop views
- Confirm forms, checkout, menus, modals, or widgets work end to end
- Clear or bypass cache when stale assets are possible
- Check console and network errors after the fix
- Verify GA4, GTM, pixels, CRM, or email delivery if the business depends on it
What to send when you want help
A strong repair request is short, specific, and evidence-based. It does not need a perfect diagnosis. It needs the broken URL, expected behavior, current behavior, affected devices, timeline, recent changes, and why the issue matters.
If the site has sensitive client or customer data, avoid sending credentials in the first message. Start with the public symptom, platform context, and priority. Access can be handled once the repair path is clear enough to begin.
Best first message
- The broken URL
- What should happen
- What happens instead
- Screenshot or recording
- Device and browser
- When it started
- Recent changes
- Business impact
- Platform and known plugins/tools
- Whether staging, backups, or hosting access exist
Fix options
Turn this article into the right fix path
These links connect the symptom in the article to the service or skill path that usually handles the fix.
Parent Broken Website Guide Use the broader guide to compare visual, functional, tracking, and infrastructure symptoms.
Website Fixes Use this when the broken site needs hands-on debugging and repair.
Production Debugging Use this when console errors, network failures, live scripts, cache, or real browser behavior need inspection.
WordPress Support Use this when the broken behavior lives inside WordPress, plugins, themes, page builders, or PHP/CSS/JavaScript.
Useful next links
Where this problem usually connects
These related pages connect this article to the hands-on services, skills, and request paths that usually solve the problem on a real site.
- Related guide
Parent Broken Website Guide Use the broader guide to compare visual, functional, tracking, and infrastructure symptoms.
- Service path
Website Fixes Use Website Fixes when the broken site needs hands-on debugging and repair.
- Skill path
Production Debugging Use Production Debugging when console errors, network failures, live scripts, cache, or real browser behavior need inspection.
- Service path
WordPress Support Use WordPress Support when the broken behavior lives inside WordPress, plugins, themes, page builders, or PHP/CSS/JavaScript.
- Service path
Security, Hosting & Reliability Use Security, Hosting & Reliability when DNS, SSL, redirects, cache, Cloudflare, hosting, or server behavior may be involved.
Need a broken website fixed?
Send the broken URL, what should happen, what happens now, when it started, and what changed recently. I will trace the issue in the safest practical order.
More troubleshooting
Related broken-site notes
If the symptom is narrower than a whole broken website, these pages route the issue more precisely.
CSS and JavaScript bugs
Front-end bug notes for CSS conflicts, console errors, script order, and browser behavior.
Read CSS and JavaScript bug helpForms and modals not working
Lead forms, popups, validation, redirects, hidden fields, and thank-you states that fail.
Read forms and modals helpBroken layouts or mobile issues
Responsive layout, overlapping sections, mobile spacing, and visual breakage.
Read layout troubleshootingFAQ
Common questions
How do I fix my broken website first?
Start by capturing the exact symptom, URL, device, expected behavior, recent changes, and business impact. Then choose the diagnostic lane: layout, interaction, form, checkout, tracking, or infrastructure.
Should I update plugins to fix a broken site?
Only if the evidence points there and you know how to roll back. Updating several plugins blindly can hide the cause or create a second problem.
Should I restore a backup?
A backup can help, but only after you understand what it will overwrite. If leads, orders, content edits, or database changes happened after the backup, restoring can create new damage.
Why does my broken website work for me but not visitors?
That often points to cache, logged-in versus logged-out state, browser differences, device-specific layout, geography/CDN behavior, or a script that loads differently for visitors.
What is the fastest useful thing to send a website fixer?
Send the URL, what should happen, what happens now, when it started, recent changes, and a screenshot or recording.
Can The Web Guy fix a broken website without rebuilding it?
Often, yes. Many broken-site problems are smaller than a rebuild: CSS, JavaScript, plugin, template, form, cache, tracking, API, or hosting fixes.