Everyone repeats it: if the form says “Thank you,” the lead arrived. That’s wrong. The page said thanks. It never promised the message went anywhere. We’ve taken the early-morning call from an owner asking why the phone went quiet for weeks while the form kept confirming every submission.
For a local home improvement company such as A&L home improvement CO, the most valuable moment on the site is a homeowner who has read about replacement windows and finally reaches out. We take apart five myths about what happens next: mail delivery, photo weight, backups, scheduled tasks and monitoring. Each one costs somebody a client or a night’s sleep. Usually the agency.
Myth: A thank-you message means the lead arrived
Reality: A thank-you message only proves the form was submitted; delivery is a separate step, and it fails without a sound.
The myth survives because the form plugin reports success the moment it hands the message to the server. What happens after that depends on the server’s mail setup and the inbox provider at the other end. Providers distrust mail that claims to come from your domain but leaves from a machine your domain never vouched for. So they bin it, or file it under junk.
Here’s the usual failure. The site moves to a new server on a Friday. The mail settings stay behind. The form keeps saying thanks all weekend, then all month. A homeowner who wanted windows quoted waits a few days, assumes nobody cares, and calls someone else. Nobody ever hears about that job.
What to do instead
- Send form mail through an authenticated mail service or SMTP account, not the server’s default
wp_mail()hand-off. - Add the SPF and DKIM records your mail provider gives you to the domain’s DNS. Those records tell receiving servers the sender is legitimate. Add a DMARC policy too.
- Turn on entry storage in the form plugin, so the lead exists in the dashboard even when the email doesn’t.
- Once a month, submit a test from a webmail address and check the inbox and the junk folder.
Run the check today. Submit your own contact form from a personal webmail account and find the message. If you have to look in junk, the setup is already failing.
No-bull verdict: A form without stored entries and authenticated mail is a suggestion box nobody empties.
Myth: Photos should go up at full camera size so they stay sharp
Reality: Sharp comes from the right dimensions for the screen, not from the biggest file on the server.
A contractor’s site runs on project photos: a finished window, a repaired stretch of siding, a new door in place. The crew shoots them on a phone and sends them over. The agency uploads them untouched because they look great. They look great because they are enormous.
WordPress makes smaller copies of every upload, and the browser can pick one that fits. That only works when the theme or gallery asks for the right size. Plenty of sliders and page builders ask for the original. Then a homeowner on weak mobile data watches a gallery of originals crawl down while the rest of the page sits empty. They press back. Your analytics file it under “bounce” and move on.
The fix is dull. Resize photos to roughly the largest size the page really shows before they go in the media library. Use a compressed format. Let images below the fold lazy-load with loading="lazy", but never the top image. Show the best handful of jobs and keep the rest on a second page.
Check it today. Open your heaviest gallery page, open the browser’s network panel, sort by size and read the top three files. If one is a straight camera original, you’ve found the problem.
No-bull verdict: The photo that wins the job is the one that loads; the camera original belongs in the archive, not the media library.
Myth: If backups run every night, you’re covered
Reality: A backup nobody has restored is a rumor.
The call comes at 3 a.m. An update took the site down, or the server had a bad night. The owner is calm, because the backup runs every night. Then we open the backup folder. The newest file is months old. The job failed once, quietly, and kept failing.
Backups die in dull ways. The storage account’s login expires. The disk fills. The plugin saves the database but skips the uploads folder, and the uploads folder is where a contractor’s finished-job photos live. Or the only copy sits on the same server that just died.
Three rules, none exciting. Keep a copy somewhere other than the server. Back up the database and the files together. Read the date on the newest file every month, because nobody else will.
Then restore last night’s backup to a staging site, a private copy where nothing public can break. Click through the gallery. Submit the form. If it all works, you have a backup. If it doesn’t, you have a bill, and you’ve found out before the client did.
No-bull verdict: Untested backups are decoration: restore one to staging this week or stop calling it a backup.
Myth: WordPress runs its scheduled jobs on schedule
Reality: The built-in scheduler, WP-Cron, only wakes up when somebody loads a page, so a quiet site misses its appointments.
Backups, retries for failed mail, scheduled posts and cache cleanup all hang on that scheduler. On a busy site, visits come often enough that nobody notices. A local contractor’s site on a slow Tuesday night can go hours with nobody visiting. Jobs run late, or all at once when the next visitor shows up, and that visitor may feel it.
The fix is to stop asking visitors to keep the clock. Set DISABLE_WP_CRON to true in wp-config.php, then have the host or your sysadmin schedule a real server cron job that calls wp-cron.php at a fixed interval. Do both halves. Set the constant alone and nothing runs at all, and you’ll learn that the hard way.
Check it today. Open Tools, then Site Health, and read what it says about scheduled events. If it reports late ones, the clock is visitor-driven and the backups from the last section may not be running when you think they are.
No-bull verdict: Scheduled work belongs on a real clock, so move it to a server cron job and switch the visitor-triggered one off.
Myth: The host will tell you when the site goes down
Reality: Hosts watch their servers, not your site, and a site can be broken while the server is perfectly happy.
The server is up. The status page is green. Meanwhile an update has turned the homepage into a blank white page, or the contact form throws an error nobody sees, or the security certificate expired overnight and every browser now warns homeowners away. The host sees a healthy machine. The client sees nothing until a neighbor mentions it.
Put a monitor outside the server. A free external uptime service will request the homepage every few minutes and email you when it fails. Better, tell it to look for a phrase that only appears when the page renders properly, such as the company name in the footer. Add a second monitor for the form page. When you take on a site, confirm that certificate renewal is automatic, then put the expiry date in your calendar anyway.
Check it today. Load each client site in a private window on your phone, off Wi-Fi, and read the address bar for warnings before you read anything else.
No-bull verdict: Trust a monitor outside the server, because the host’s green light only means the machine is on.
Where we land
Contractor sites fail in dull ways: mail that never arrives, photos that outweigh the page, backups nobody restored, jobs waiting for a visitor to wake them, and nobody watching from outside. None of it shows on the front end, which is why the client finds out when the phone stops. This week, submit your own contact form from a webmail account and find the message. Then restore last night’s backup to staging.
The thank-you page is a greeting card. Check the mailbox.