Start here — the whole guide in one page
I build websites for small businesses around Ottawa. This guide is everything I check, fix and teach — written for owners, not programmers. Read it before you buy a website, or after, to know exactly what yours should be doing for you.
The checklist walks you through all 236, one chapter at a time — Yes or Not yet — and builds your score and fix list as you go. Your progress saves on your device, to your account with Google sign-in, or as a save code you can carry anywhere.
Eleven short chapters, 236 questions — the same ones I audit by. For each one ask: is this true of my website today? Yes means you're in good shape. Not yet puts it on your fix list at the bottom. Not sure? Skip it and come back — skipped questions are never counted against you.
Chapter 1 of 11
0 of 30 answered · 0 passing
Force HTTPS everywhere with a valid TLS certificate and redirect all HTTP to HTTPS.
Unencrypted pages leak form data and browsers label them “Not Secure,” killing trust and conversion.
Enable HSTS (`Strict-Transport-Security: max-age=31536000; includeSubDomains`) only after HTTPS works on every subdomain.
HSTS stops downgrade/man-in-the-middle attacks, but enabling it on a broken subdomain locks visitors out.
My site does not let a certificate expire.
An expired cert shows a full-page browser warning that sends almost every visitor away.
The trap this avoids: Let a certificate expire; automate renewal (e.g. Let's Encrypt) and alert 30/14/7 days before expiry.
Ship a Content-Security-Policy, starting in Report-Only, then enforcing a strict/nonce-based policy.
A strict CSP can turn an exploitable XSS bug into a blocked request instead of a breach [OWASP header guides].
Set `X-Content-Type-Options: nosniff`, `X-Frame-Options`/CSP `frame-ancestors`, `Referrer-Policy: strict-origin-when-cross-origin`, and a restrictive `Permissions-Policy`.
These low-risk headers block MIME-sniffing, clickjacking, and referrer leakage for minutes of work.
My site does not set headers in two places (server + CDN + plugin) or never re-check them after a migration.
Duplicate/conflicting headers and headers silently lost in a host move are common audit failures.
The trap this avoids: Set headers in two places (server + CDN + plugin) or never re-check them after a migration.
Require MFA/passkeys for every admin, hosting, registrar, DNS, Stripe/Shopify, and email account.
Most small-site takeovers start with a reused password, and MFA blocks the Colonial-Pipeline-style single-password failure.
Enforce a password policy via a password manager: 14+ characters, unique per site, breached-password screening.
Credential stuffing succeeds because owners reuse one password across the site, email, and registrar.
My site does not share one “admin” login among staff, contractors, and the client.
Shared accounts make least-privilege, off-boarding, and audit trails impossible.
The trap this avoids: Share one “admin” login among staff, contractors, and the client.
Apply least privilege: editors edit, only administrators administer; give contractors time-limited accounts.
A compromised editor account should not be able to install plugins or change payment settings.
Remove/disable unused accounts, plugins, themes, and the default `admin` username, and hide nothing as your security strategy.
Dormant code and accounts are unpatched attack surface that scanners find automatically.
Patch CMS core, plugins, themes, and dependencies on a set cadence (critical: 24–72h; routine: weekly/monthly) and auto-update minor releases.
Unpatched known vulnerabilities — not zero-days — are how most small sites are hacked.
My site does not run end-of-life PHP/Node/WordPress versions or abandoned plugins.
EOL software receives no security fixes, so every new disclosure is a permanent hole.
The trap this avoids: Run end-of-life PHP/Node/WordPress versions or abandoned plugins.
Keep secrets (API keys, Stripe keys, SMTP passwords) in environment variables / a secrets manager, never in code, Git, screenshots, or email.
A leaked live Stripe or hosting key in a repo can be exploited within minutes by bots.
Use separate keys for staging and production, scope keys to minimum permissions, and rotate them when staff leave.
One over-privileged leaked key should not compromise payments, email, and hosting at once.
Put a WAF (e.g. Cloudflare/host WAF) and rate-limiting on login, checkout, search, and form endpoints.
Rate limits blunt credential-stuffing, scraping, and card-testing attacks before they reach the application.
Protect every public form with layered anti-spam: honeypot + time check + Turnstile/reCAPTCHA + server-side validation.
A single captcha alone is either bypassed by bots or so aggressive it blocks real customers.
My site does not rely only on client-side (browser) validation for forms, prices, or permissions.
Anything enforced only in the browser can be bypassed by sending a crafted request directly to the server.
The trap this avoids: Rely only on client-side (browser) validation for forms, prices, or permissions.
Validate and sanitize all input server-side, use parameterized queries, and encode output by context.
This is the core defence against SQL injection and XSS, still in the OWASP Top 10.
Lock down file uploads: allowlist types, re-encode images, scan for malware, store outside the web root / in object storage, serve with `nosniff` and safe Content-Disposition.
Uploads are a classic path to remote-code execution when a “photo” is actually a script.
My site does not allow SVG/zip/executable uploads from the public without sanitization and a business reason.
SVG can carry script and zips can hide anything, turning a portfolio-upload feature into a compromise.
The trap this avoids: Allow SVG/zip/executable uploads from the public without sanitization and a business reason.
Set session cookies `Secure; HttpOnly; SameSite`, rotate the session after login, expire idle sessions, and never put tokens in URLs.
These settings prevent session theft via XSS, network sniffing, and leaked links/logs.
Log authentication events, admin changes, payment/webhook failures, and permission denials — and alert on bursts of failed logins.
Without logs you cannot detect, investigate, or (in Quebec) properly register a confidentiality incident.
Keep daily automated backups following 3-2-1 (3 copies, 2 media, 1 off-site/offline or immutable), with a separate backup account/credentials.
Ransomware and a compromised host will delete backups reachable with the same credentials.
Test restores at least quarterly (full restore to staging) and record how long it took.
An untested backup is a hope, not a backup — restore testing is the industry-recommended cadence and the only proof recovery works.
My site does not keep the only backup on the same server, in the same hosting account.
Host failure, account suspension, or ransomware then destroys production and backup together.
The trap this avoids: Keep the only backup on the same server, in the same hosting account.
Maintain a one-page incident-response plan: who decides, who hosts/DNS/registrar contacts are, how to freeze admin access, who notifies clients/regulators.
In a breach the first hour is lost to “who has the login?” unless it is written down in advance.
Verify webhook signatures (Stripe/Shopify/payment, form, booking) and make webhooks idempotent.
Unsigned webhooks let attackers fake “paid” orders; non-idempotent ones create duplicate orders on retries.
Disable directory listing, XML-RPC (if unused), debug mode, and public access to `.env`, `.git`, backup files, and install scripts in production.
Scanners probe these paths continuously and they leak credentials and source code.
My site does not buy “security” as a one-time plugin install and forget it.
Security is patching + monitoring + restore drills; a plugin without a process gives false confidence.
The trap this avoids: Buy “security” as a one-time plugin install and forget it.
Your answers save themselves on this device as you go — come back on the same phone or computer and they'll be here. To keep them anywhere else, use your account or a save code.
Option 1 — Your account
Your checklist progress is stored under your account and loads on any device you sign in on. Nothing else — no emails, no marketing list.
Option 2 — A save code (no account)
0 of 236 answered on this device so far.
Every “Not yet” lands here as a fix, grouped by chapter. Print it, hand it to whoever built your site — or send it to me.
If one job fails, the others don't matter. A fast site that leaks customer data, or a secure site whose form loses leads, is still a failing site.
Locks on every door: HTTPS, strong logins with a second factor, software kept up to date, and backups that are actually tested. Most small sites don't get hacked by geniuses — they get walked into through an old password or an update nobody ran.
People decide in seconds. The targets the pros use: main content visible in 2.5 seconds or less, the page responding within 0.2 seconds of a tap, and nothing jumping around while you read. Slow is not a style choice — it's customers leaving.
Every button, form, booking and payment does what it promises — tested on a real phone, not just the designer's big screen. A beautiful website with a contact form that silently fails is a billboard in the desert.
Your customer gets an instant confirmation that says what happens next. You get the lead immediately — in your inbox and a backup system — so no enquiry ever depends on one email behaving itself.
🇨🇦 Law 25 (Quebec)
If Quebecers use your site: tracking cookies stay OFF until a visitor says yes, you must name a privacy officer, and fines run up to $25M or 4% of worldwide turnover. There is no small-business exemption.
🇨🇦 CASL (all Canada)
You need permission before marketing emails — and you have to be able to prove it. Buying a list or adding every customer who ever bought something is how businesses get fined up to $10M.
🇨🇦 AODA (Ontario)
Build to WCAG 2.2 AA accessibility — keyboard access, readable contrast, labelled forms. Ontario organizations with 20+ employees also have a compliance report due Dec 31, 2026.
🇨🇦 Tax by province
Online sales are taxed by where your customer is, not where you are: 13% HST in Ontario, 14.975% in Quebec, 5% GST in Alberta. Your checkout has to get this right on every order.
🇨🇦 French (Bill 96)
Selling into Quebec means your website needs a real French version — not a machine-translated afterthought. In Ottawa–Gatineau, bilingual is also just good business.
Why it matters
These aren't fine print — they're the difference between a website that's an asset and one that's a liability with your name on it.
Every rule I build and audit by, each with the reason in one line. Search them, filter by chapter, or flip on the Canada-only view. Do = green check. Don't = red cross.
Showing 236 of 236 rules
Force HTTPS everywhere with a valid TLS certificate and redirect all HTTP to HTTPS.
Unencrypted pages leak form data and browsers label them “Not Secure,” killing trust and conversion.
Security
Enable HSTS (`Strict-Transport-Security: max-age=31536000; includeSubDomains`) only after HTTPS works on every subdomain.
HSTS stops downgrade/man-in-the-middle attacks, but enabling it on a broken subdomain locks visitors out.
Security
Let a certificate expire; automate renewal (e.g. Let's Encrypt) and alert 30/14/7 days before expiry.
An expired cert shows a full-page browser warning that sends almost every visitor away.
Security
Ship a Content-Security-Policy, starting in Report-Only, then enforcing a strict/nonce-based policy.
A strict CSP can turn an exploitable XSS bug into a blocked request instead of a breach [OWASP header guides].
Security
Set `X-Content-Type-Options: nosniff`, `X-Frame-Options`/CSP `frame-ancestors`, `Referrer-Policy: strict-origin-when-cross-origin`, and a restrictive `Permissions-Policy`.
These low-risk headers block MIME-sniffing, clickjacking, and referrer leakage for minutes of work.
Security
Set headers in two places (server + CDN + plugin) or never re-check them after a migration.
Duplicate/conflicting headers and headers silently lost in a host move are common audit failures.
Security
Require MFA/passkeys for every admin, hosting, registrar, DNS, Stripe/Shopify, and email account.
Most small-site takeovers start with a reused password, and MFA blocks the Colonial-Pipeline-style single-password failure.
Security
Enforce a password policy via a password manager: 14+ characters, unique per site, breached-password screening.
Credential stuffing succeeds because owners reuse one password across the site, email, and registrar.
Security
Share one “admin” login among staff, contractors, and the client.
Shared accounts make least-privilege, off-boarding, and audit trails impossible.
Security
Apply least privilege: editors edit, only administrators administer; give contractors time-limited accounts.
A compromised editor account should not be able to install plugins or change payment settings.
Security
Remove/disable unused accounts, plugins, themes, and the default `admin` username, and hide nothing as your security strategy.
Dormant code and accounts are unpatched attack surface that scanners find automatically.
Security
Patch CMS core, plugins, themes, and dependencies on a set cadence (critical: 24–72h; routine: weekly/monthly) and auto-update minor releases.
Unpatched known vulnerabilities — not zero-days — are how most small sites are hacked.
Security
Run end-of-life PHP/Node/WordPress versions or abandoned plugins.
EOL software receives no security fixes, so every new disclosure is a permanent hole.
Security
Keep secrets (API keys, Stripe keys, SMTP passwords) in environment variables / a secrets manager, never in code, Git, screenshots, or email.
A leaked live Stripe or hosting key in a repo can be exploited within minutes by bots.
Security
Use separate keys for staging and production, scope keys to minimum permissions, and rotate them when staff leave.
One over-privileged leaked key should not compromise payments, email, and hosting at once.
Security
Put a WAF (e.g. Cloudflare/host WAF) and rate-limiting on login, checkout, search, and form endpoints.
Rate limits blunt credential-stuffing, scraping, and card-testing attacks before they reach the application.
Security
Protect every public form with layered anti-spam: honeypot + time check + Turnstile/reCAPTCHA + server-side validation.
A single captcha alone is either bypassed by bots or so aggressive it blocks real customers.
Security
Rely only on client-side (browser) validation for forms, prices, or permissions.
Anything enforced only in the browser can be bypassed by sending a crafted request directly to the server.
Security
Validate and sanitize all input server-side, use parameterized queries, and encode output by context.
This is the core defence against SQL injection and XSS, still in the OWASP Top 10.
Security
Lock down file uploads: allowlist types, re-encode images, scan for malware, store outside the web root / in object storage, serve with `nosniff` and safe Content-Disposition.
Uploads are a classic path to remote-code execution when a “photo” is actually a script.
Security
Allow SVG/zip/executable uploads from the public without sanitization and a business reason.
SVG can carry script and zips can hide anything, turning a portfolio-upload feature into a compromise.
Security
Set session cookies `Secure; HttpOnly; SameSite`, rotate the session after login, expire idle sessions, and never put tokens in URLs.
These settings prevent session theft via XSS, network sniffing, and leaked links/logs.
Security
Log authentication events, admin changes, payment/webhook failures, and permission denials — and alert on bursts of failed logins.
Without logs you cannot detect, investigate, or (in Quebec) properly register a confidentiality incident.
Security
Keep daily automated backups following 3-2-1 (3 copies, 2 media, 1 off-site/offline or immutable), with a separate backup account/credentials.
Ransomware and a compromised host will delete backups reachable with the same credentials.
Security
Test restores at least quarterly (full restore to staging) and record how long it took.
An untested backup is a hope, not a backup — restore testing is the industry-recommended cadence and the only proof recovery works.
Security
Keep the only backup on the same server, in the same hosting account.
Host failure, account suspension, or ransomware then destroys production and backup together.
Security
Maintain a one-page incident-response plan: who decides, who hosts/DNS/registrar contacts are, how to freeze admin access, who notifies clients/regulators.
In a breach the first hour is lost to “who has the login?” unless it is written down in advance.
Security
Verify webhook signatures (Stripe/Shopify/payment, form, booking) and make webhooks idempotent.
Unsigned webhooks let attackers fake “paid” orders; non-idempotent ones create duplicate orders on retries.
Security
Disable directory listing, XML-RPC (if unused), debug mode, and public access to `.env`, `.git`, backup files, and install scripts in production.
Scanners probe these paths continuously and they leak credentials and source code.
Security
Buy “security” as a one-time plugin install and forget it.
Security is patching + monitoring + restore drills; a plugin without a process gives false confidence.
Security
Comply with PIPEDA federally and the applicable provincial law (Quebec Law 25, BC/Alberta PIPA) where it applies. 🇨🇦
PIPEDA is the federal baseline for commercial activity, but substantially-similar provincial laws govern intra-provincial activity and Law 25 is stricter in almost every material respect.
Privacy & Legal — Canada
Name a Privacy Officer / person responsible for personal information and publish their contact in the privacy policy. 🇨🇦
Law 25 requires it and defaults the role to the highest authority if no one is designated; PIPEDA also requires an accountable individual.
Privacy & Legal — Canada
Publish a plain-language privacy policy (EN, and FR for Quebec-facing sites) stating what is collected, why, who it is shared with, where it is stored, retention, and how to exercise rights. 🇨🇦
Generic US templates miss Law 25 rights (erasure, portability, de-indexation) and Quebec transfer rules.
Privacy & Legal — Canada
Default non-essential cookies/trackers OFF and get explicit opt-in consent before firing analytics, ads pixels, or embedded trackers in Quebec; make withdrawal as easy as consent. 🇨🇦
Law 25 requires opt-in, granular, revocable consent — “continued browsing = consent” and pre-ticked boxes do not comply.
Privacy & Legal — Canada
Load Google Analytics/Meta Pixel before consent on a Quebec-facing site.
Firing trackers first and asking later is exactly the sequence Law 25 prohibits for tracking technologies.
Privacy & Legal — Canada
Keep a confidentiality-incident register (all incidents, retained at least 5 years under Law 25) and assess “real risk of significant harm” for PIPEDA breach reporting to the Privacy Commissioner and affected individuals. 🇨🇦
Both regimes require records; Law 25 also requires notice to the CAI and affected persons where there is a risk of serious injury.
Privacy & Legal — Canada
Run a Privacy Impact Assessment before sending Quebec residents' data outside Quebec (including to a US host/CRM) and document adequate protection in a written agreement. 🇨🇦
A PIA before cross-border transfer is mandatory under Law 25, not optional paperwork.
Privacy & Legal — Canada
Collect the minimum personal data each form actually needs and delete/anonymize it on a retention schedule.
Data you never collected or already deleted cannot be breached, subpoenaed, or misused.
Privacy & Legal — Canada
Honour access, correction, deletion, portability (Quebec, since 22 Sept 2024) and de-indexation requests within the statutory window (~30 days) after identity verification.
Missing a rights request is a complaint and penalty risk even for a sole proprietor — Law 25 has no small-business size exemption.
Privacy & Legal — Canada
Assume Law 25 fines are theoretical: administrative penalties up to $10M or 2% of worldwide turnover, penal fines up to $25M or 4%, whichever is higher. 🇨🇦
The scale means even a small firm's realistic penalty, plus mandatory notification costs, can exceed the value of the website contract many times over.
Privacy & Legal — Canada
For every commercial electronic message, satisfy CASL: prior express (or valid implied) consent, sender identification with mailing address/contact, and a working unsubscribe honoured within 10 business days. 🇨🇦
CASL is opt-in, the sender bears the burden of proving consent, and penalties reach $1M (individuals) / $10M (organizations) per violation.
Privacy & Legal — Canada
Add a contact-form submitter, purchaser, or scraped address to a marketing list without CASL-valid consent, or use a pre-checked marketing box. 🇨🇦
A transactional relationship gives only time-limited implied consent (generally 2 years after a purchase, 6 months after an inquiry) — it is not a lifetime marketing permission.
Privacy & Legal — Canada
Keep consent records (who, when, how, what wording, source IP/form) for every subscriber. 🇨🇦
Under CASL, if you cannot prove consent, you effectively do not have it.
Privacy & Legal — Canada
Put Terms of Service / Terms of Sale, shipping, returns, warranty, and cancellation terms where a buyer sees them *before* paying, in the same language as the checkout.
Hidden or post-purchase terms create chargebacks, consumer-protection complaints, and unenforceable clauses.
Privacy & Legal — Canada
Build to WCAG 2.2 AA as the build standard, even though Ontario's AODA legal minimum is WCAG 2.0 AA. 🇨🇦
AODA requires WCAG 2.0 AA for designated public-sector and Ontario organizations with 50+ employees (content since 2012), and 2.2 includes 2.0 plus mobile/cognitive criteria — building to 2.2 satisfies today's law and avoids a second remediation.
Privacy & Legal — Canada
Warn Ontario clients with 20+ employees about the AODA accessibility compliance report (next deadline 31 Dec 2026) and clients with 50+ about the website duty. 🇨🇦
The agency that flags the deadline sells the audit/remediation; the agency that misses it shares the client's problem.
Privacy & Legal — Canada
Meet WCAG in practice: full keyboard access, visible focus, labelled controls, alt text, captions/transcripts, 4.5:1 body-text contrast (3:1 large text), no information by colour alone, and errors identified in text.
Accessibility failures exclude customers directly and the Ontario Human Rights Code risk applies even below AODA's 50-employee web threshold.
Privacy & Legal — Canada
Sell an “accessibility overlay widget” as compliance.
Widgets do not fix keyboard traps, unlabelled forms, bad heading order, or PDF problems and are not accepted as conformance.
Privacy & Legal — Canada
Add an accessibility statement/feedback route and test with keyboard only + a screen reader + 200% zoom on the top flows.
Real assistive-technology testing finds blockers automated scans miss (scans catch only a subset of issues).
Privacy & Legal — Canada
Disclose material AI/chatbot use, sponsored content, affiliate links, and review incentives, and never publish fake reviews/testimonials.
Fake social proof violates competition/consumer-protection law and Google review policy, and destroys trust when discovered.
Privacy & Legal — Canada
Licence every image, font, video, and track, and keep the licence records with the project files.
A single unlicensed hero photo can cost the client more in a demand letter than the site cost to build.
Privacy & Legal — Canada
Store full card numbers, CVVs, health details, or SINs in a website, form, email, or CRM note — ever.
Those data types trigger PCI/forensic and privacy consequences completely out of proportion to any convenience.
Privacy & Legal — Canada
Meet Core Web Vitals at the 75th percentile, mobile and desktop separately: LCP ≤2.5s, INP ≤200ms, CLS ≤0.1.
These are Google's “good” thresholds; INP replaced FID on 12 March 2024, so any report still quoting FID is out of date.
Performance & Reliability
Judge speed only by a Lighthouse run on office Wi-Fi.
Google grades real-user field data (CrUX); a mid-range phone on 4G in the client's neighbourhood is the real test.
Performance & Reliability
Optimize the LCP element: compress/preload the hero image or headline block, use modern formats (WebP/AVIF), and set explicit width/height on all media.
The hero is usually the LCP element, and missing dimensions are the top cause of CLS.
Performance & Reliability
Serve responsive images (`srcset`/sizes), lazy-load below-the-fold images/embeds, and never upload a 4,000px camera photo into a 400px slot.
Oversized images are routinely the largest payload on small-business sites.
Performance & Reliability
Compress and caption video, host it on a streaming platform/CDN, use a poster image, and never autoplay video with sound.
Self-hosted uncompressed video destroys mobile LCP and data plans.
Performance & Reliability
Cache aggressively: browser cache headers, page cache, object cache where needed, and a CDN (especially for Canada-wide/e-commerce traffic).
Caching/CDN cuts time-to-first-byte — target TTFB under ~0.8s — which drags every other metric with it.
Performance & Reliability
Minify/defer non-critical JS and CSS, remove unused plugins/tags, and break up long main-thread tasks.
Heavy JavaScript is the usual cause of failing INP; every tag must earn its performance cost.
Performance & Reliability
Stack popups, chat widgets, review widgets, cookie banners, and promo bars all firing on load.
Each adds JS, layout shift, and cognitive friction; together they can halve mobile conversion.
Performance & Reliability
Load fonts efficiently: self-host or preload the one or two weights used, use `font-display: swap`, and limit font families.
Font loading causes both CLS (swap shift) and invisible-text delays.
Performance & Reliability
Monitor uptime externally (1-minute checks) with alerts to the owner *and* the agency, plus a public/internal status note process.
You should learn the site is down from monitoring, not from a customer on Instagram.
Performance & Reliability
Monitor SSL expiry, domain expiry, Core Web Vitals (Search Console), 5xx errors, and cron/webhook failures as first-class alerts.
“Up” but with an expired cert, broken checkout webhook, or failed form cron is functionally down.
Performance & Reliability
Use a custom, helpful 404 (branded, search, top links, contact) and soft-404 discipline, plus custom 500/maintenance pages.
A dead-end error page loses a visitor who was one click from converting.
Performance & Reliability
Plan DNS properly: reputable registrar/DNS, low TTL before a migration (then raise it), SPF/DKIM/DMARC/CAA records documented, and DNSSEC where supported.
DNS mistakes take down the website *and* email at once, and undocumented records get deleted in migrations.
Performance & Reliability
Put domain, DNS, hosting, and website all in one person's personal account with no recovery access.
Account lockout or a dispute then becomes a hostage situation for the whole business (see §4 on ownership).
Performance & Reliability
Test performance and errors on real low/mid Android devices and throttled 4G, not only on a flagship phone.
Most local traffic is mobile and not on flagship hardware.
Performance & Reliability
Set a performance budget (e.g. total page weight, JS weight, LCP/INP targets) and check it at launch and monthly.
Without a budget, every later “small addition” silently taxes speed.
Performance & Reliability
Keep staging and production on comparable hosting/php versions so “it worked on staging” means something.
Environment drift is a leading cause of launch-day surprises.
Performance & Reliability
Scale-test booking/order peaks (Friday dinner rush, ticket on-sale, seasonal sale) if the business has them.
A site that works on Tuesday and collapses at the one moment it earns money is not reliable.
Performance & Reliability
Host a Canadian business's only copy on a single cheap shared server with no CDN, no staging, and no support SLA, to save $10/month.
The first outage during a promotion costs more than years of proper hosting.
Performance & Reliability
Display accurate hours — including holiday/special hours — in sync across the site, Google Business Profile, and booking system.
Wrong hours are a reliability failure users experience as “the business lied to me.”
Performance & Reliability
Use transactional infrastructure for critical messages (dedicated transactional email/API, not the web server's `mail()`).
Server mail is routinely filtered, making password resets and order confirmations vanish.
Performance & Reliability
Keep an error log review in the monthly routine: top 404s, 5xx, failed payments, failed form deliveries.
Unreviewed logs hide revenue leaks for months.
Performance & Reliability
Redirect-chain everything (301→301→301) or redirect all old URLs to the homepage.
Chains waste speed/crawl budget and homepage redirects tell Google the content vanished.
Performance & Reliability
Give every launch a rollback plan: pre-launch backup, DNS TTL lowered, old site preserved until the new one is verified.
“No rollback” turns a fixable launch bug into an extended outage.
Performance & Reliability
Test every form end-to-end in production after launch: submit, confirm the owner receives it, the visitor gets a confirmation, and it lands in the CRM/spreadsheet.
“Form displayed” is not “form works” — silent delivery failure is the #1 lost-lead cause on small sites.
Functionality & QA
Test booking/ordering/payment with real (or processor test-mode + one live low-value) transactions, refunds, cancellations, and confirmation emails.
The happy path is 20% of a transaction system; refunds and edge cases are where trust is won or lost.
Functionality & QA
Launch on a Friday afternoon, holiday eve, or the client's busiest day without support coverage.
Most launch bugs surface in the first hours, when no one is available to fix them.
Functionality & QA
Run broken-link and crawl checks (Screaming Frog/site crawler) before launch and monthly; fix or 301 every internal 404.
Broken links waste crawl budget and strand visitors mid-journey.
Functionality & QA
Test on real browsers/devices the audience uses: current Chrome, Safari iOS, Edge, Firefox; small phone, large phone, tablet, desktop.
Safari iOS alone breaks enough payment/date-picker/100vh behaviour to justify a real device.
Functionality & QA
Build and sign off on staging, then freeze content/code, migrate, and re-test on production — never build directly on live.
Staging prevents the public (and Google) from seeing half-finished pages.
Functionality & QA
Leave staging indexable, unpassworded, or with test orders/testimonials visible.
Indexed staging duplicates the site in Google and leaks unfinished copy.
Functionality & QA
QA the money flows field by field: tax 🇨🇦, shipping, discounts, gift cards, tips, deposits, and totals in every province/state served.
A one-cent or wrong-province tax error repeated on every order becomes a reassessment and a support flood.
Functionality & QA
Test error states deliberately: wrong card, declined card, sold-out item, double-submit, session timeout, back button mid-checkout.
Users judge a business by how it fails, not only by how it succeeds.
Functionality & QA
Validate phone numbers, postal codes 🇨🇦 (A1A 1A1, not ZIP), dates/times with time zone, and addresses with forgiving formatting and inline errors next to the field.
Rigid or US-format validation rejects real Canadian customers who then phone a competitor — or just leave.
Functionality & QA
Check every tap target (≥44px), sticky header, menu, filter, search, and pagination on mobile with one thumb.
Desktop-perfect navigation that cannot be operated one-handed fails the majority use case.
Functionality & QA
Test with JavaScript disabled / a script blocked, ad-blockers, and slow connections for the critical path (menu, phone link, form).
A single blocked third-party script should not take down ordering.
Functionality & QA
Proof the transactional emails and PDFs (receipts, invoices with GST/HST numbers 🇨🇦, tickets, gift cards) as carefully as web pages.
Customers keep and forward these; errors there look like fraud or incompetence.
Functionality & QA
Run a pre-launch content freeze checklist: no lorem ipsum, no placeholder prices/hours/photos, no “coming soon” pages linked from navigation.
Placeholder content at launch is surprisingly common and instantly destroys credibility.
Functionality & QA
Go live with search that returns nothing, filters that return zero results with no explanation, or a “no results” dead end.
Every zero-result page needs suggestions, popular alternatives, and a contact route.
Functionality & QA
Test accessibility QA alongside functional QA (see #47–49) on the actual templates, not only the homepage.
A checkout or booking widget that is mouse-only is a functional failure for keyboard users.
Functionality & QA
Load-test forms/payments against double-clicks and refreshes so one action cannot create two charges/bookings.
Duplicate charges generate chargebacks and 1-star reviews out of proportion to the bug.
Functionality & QA
Document known limitations at handover (“booking system does not sync X”) in writing, signed by the client.
Undocumented limitations become disputed “bugs” and free support forever.
Functionality & QA
Keep a regression checklist and re-run it after every major update/plugin change.
Updates most often break the flow nobody re-tested — usually checkout or the contact form.
Functionality & QA
Give a client a site with no test evidence and call it “QA'd.”
A dated checklist with who tested what, on which device, is both quality control and liability protection.
Functionality & QA
Put one primary call to action per page, in the business's words (“Book a table,” “Get a quote,” “Book a cut”), repeated after each value block.
Pages with five competing CTAs convert worse than pages with one clear next step.
UX, Design & Conversion
Answer above the fold: what you do, where/for whom, proof, and the CTA — without requiring a scroll or a carousel rotation.
Visitors decide in seconds; a vague hero (“Welcome to our website”) wastes the only guaranteed view.
UX, Design & Conversion
Use auto-rotating hero carousels, splash/intro pages, or autoplay promotional modals on entry.
Carousels hide the offer from most visitors and entry popups tax the exact moment of highest intent.
UX, Design & Conversion
Make the phone number tappable (`tel:`), address linked to maps, and hours visible from every page on mobile (sticky call/book bar where appropriate).
For local services, a call *is* the conversion; hiding the number behind a form loses urgent jobs.
UX, Design & Conversion
Keep main navigation to ~5–7 labelled items in the user's language (“Tattoos,” “Piercing,” “Aftercare”), with a shallow structure and a visible search for larger catalogues.
Invented/clever labels and deep menus force visitors to guess where things live.
UX, Design & Conversion
Place social proof *next to the decision*: recent Google reviews/testimonials with names/photos near CTAs, pricing, and checkout — not only on a testimonials page.
Trust signals work at the moment of hesitation; LogRocket/Airbnb-style analysis shows reviews, badges, and guarantees mapped to the drop-off point outperform a distant proof page.
UX, Design & Conversion
Show real photos of the premises, team, work, and products; label stock photos honestly where used.
Airbnb's early growth lesson was that poor/untrustworthy listing photos suppressed bookings — professional, accurate photos lifted them.
UX, Design & Conversion
Fabricate scarcity, countdown timers, “only 2 left,” or review counts.
Fake urgency is deceptive under consumer law, is penalized by platforms, and collapses trust when noticed.
UX, Design & Conversion
Publish prices, price ranges, or “from” pricing and what is included, unless there is a genuine reason to quote — and then publish the quoting process and response time.
Hidden pricing is the top reason qualified local visitors leave to find a competitor who shows it.
UX, Design & Conversion
Reduce every form to the minimum fields needed to follow up (name + one contact method + the request to start).
Each extra field costs completions; benchmarks consistently show 3–5 fields as the lead-gen sweet spot and large gains from cutting 11 fields to 4.
UX, Design & Conversion
Use multi-step forms for long requests (quote builders, intake) with a progress indicator and one topic per step.
The same number of fields feels shorter in steps and lets you save partial leads.
UX, Design & Conversion
Design checkout/booking as the highest-priority flow: guest option, wallets (Apple/Google/Shop Pay), autofill, inline validation, progress, and a clear review step.
See §J; checkout friction is the single largest recoverable revenue leak in e-commerce.
UX, Design & Conversion
Show the total cost early — product + shipping + tax 🇨🇦 estimate — before the payment step.
Surprise costs are Baymard's #1 fixable abandonment reason (39–48% depending on the cut).
UX, Design & Conversion
Make trust concrete at payment: secure-checkout wording, payment marks, returns guarantee, real address, and support contact on the checkout page.
19% of abandoners in Baymard's data say they did not trust the site with card information.
UX, Design & Conversion
Force account creation before a first purchase/booking; offer the account *after*, from the order data, in one click.
Forced account creation accounts for ~19% of abandonment.
UX, Design & Conversion
Write button text as the outcome (“Book my table — no card required”) and state what happens next on every confirmation screen.
Uncertainty about the next step generates duplicate submissions and “did it work?” phone calls.
UX, Design & Conversion
Design mobile-first: content order, CTA placement, and form keyboards (`type=tel/email`, autocomplete) for phones first, then enhance for desktop.
Google indexes the mobile render and most local searches start on mobile — desktop-first design buries the conversion on the device that matters.
UX, Design & Conversion
Keep a consistent design system (type scale, spacing, button/input styles, image ratios) across site, emails, invoices, and social templates.
Consistency is learnability — Airbnb and Booking.com both scale on a design language system, not page-by-page improvisation.
UX, Design & Conversion
Chase a redesign when the problem is speed, clarity, or a broken flow.
Practitioner benchmarks warn a visual redesign alone rarely fixes conversion; fix the binding constraint (speed → clarity → trust → form friction) first and measure.
UX, Design & Conversion
Aim for realistic conversion targets and measure by intent: ~3%+ contact-form conversion for service sites, 5%+ on a quote page, 3%+ e-commerce, 8–10%+ on a focused landing page.
The all-industry median is ~2.35%, so “above 3%” is already above average — set targets the client can understand.
UX, Design & Conversion
Provide self-serve answers before contact: FAQ, pricing, parking, preparation/aftercare, service area, and policies, linked from product/service pages.
Every answered objection on the page is a call the owner does not have to take and a visitor who does not leave to search.
UX, Design & Conversion
Make search forgiving: typo tolerance, synonyms (“balayage” / “highlights”), popular searches, and useful zero-results handling (see #91).
Local catalogues lose sales when search demands the exact word the owner used.
UX, Design & Conversion
Use breadcrumbs, clear headings hierarchy (one H1, logical H2/H3), and scannable layouts with short paragraphs and lists.
Hierarchy serves sighted scanners, screen-reader users, and Google simultaneously.
UX, Design & Conversion
Put critical content only in images, PDFs, hover menus, or desktop-only sections.
It will be invisible to mobile users, screen readers, and Google's mobile index at once.
UX, Design & Conversion
Showing the first 120 matches — narrow the search or pick a chapter to see the rest.
A website has two conversations going at all times. Both have to work, every time, without you watching.
A CRM sounds corporate. For a small business it's just this: a list that remembers every enquiry so a human can follow up before a competitor does.
Speed of first reply is the single biggest lever a small business controls: the goal is a first touch within 5 minutes during working hours, and always the same business day. After that: a short, set follow-up rhythm (day 1, 3, 7, 14) instead of “I think I emailed them once.” Targets like these are goals to aim for — labelled as targets, not guarantees.
Nobody gets contacted twice by accident, and nobody who said no gets chased. Your CRM keeps a do-not-contact list and a record of every touch — that's what separates follow-up from spam, legally (CASL 🇨🇦) and reputationally.
You don't need to be technical. You need these eight things true about your business, whoever built your site. Ask your builder about every one.
Website, domain, hosting, email, payments, socials — 14+ characters, never reused.
Turn it on for every admin, hosting, registrar, banking and email account. Most takeovers start with one reused password.
You — the owner — hold the domain and main accounts in your name. A builder should be a guest with their own login, never the owner.
Outdated software is how most small sites get hacked. Critical fixes within days, routine updates monthly.
Daily, stored somewhere separate, and a restore actually rehearsed at least every quarter. An untested backup is a hope, not a backup.
Who to call, where the logins are, how to freeze access. Written before you need it, not during a crisis.
Spam filters on every form; if visitors can upload files, only safe types, scanned and stored safely.
Uptime, certificate-expiry and failed-login alerts to a human — you should hear your site is down from a monitor, not a customer.
And the one rule under all of them: never store card numbers, health details or SINs in a website form, email or spreadsheet — ever. Payments go through a proper processor (Stripe, Shopify) so the card never touches your site.
This is the actual journey when I build a site: what happens, when, and how you know each step is done.
We map your customers, your offers, and what 'success' looks like in numbers — calls, bookings, orders — before any design starts.
Words, photos, prices, hours. Real photos of your real work — never stock stand-ins. Content late is the #1 cause of late launches, so it's scheduled, not hoped for.
Your site is built on a private staging copy: pages, forms, booking/payments wired up, French core pages if they're in scope.
Every form submitted for real, a real small payment and refund, phones and browsers tested, speed measured on a mid-range phone over 4G.
Never a Friday. Backups taken, rollback ready, old addresses redirected one-to-one, Google Business Profile updated the same day.
Indexing checked at 72 hours; traffic, leads and rankings reviewed at weeks 2 and 6. Anything broken gets found by us, not your customers.
Monthly updates, backups, checks and one small growth improvement — plus a plain-English report: what we did, what's healthy, what leads came in.
Review the numbers together. Most sites need evolution, not a rebuild — redesign when the business changes, the tech ages out, or the data says so.
A website isn't a poster you print once. Software ages, certificates expire, and small failures compound quietly. Here's what maintenance actually is — and what it should cost.
Published surveys of real providers put entry plans around $79/mo, mid-tier around $177/mo and premium around $339/mo — agency-positioned plans commonly run $150–$600/mo depending on depth. If someone offers “maintenance” for $20/mo, ask which of the list above they're skipping.
| Landing page | $1,440 |
| Full website | $3,040 |
| Full-blown build (shop, booking, admin) | $6,000+ |
The giants publish their numbers. Here's what their money says, and the specific moves worth stealing — with the honesty caveats kept in.
| Company | Period | Revenue | Growth | What it teaches |
|---|---|---|---|---|
| Shopify 🇨🇦 | Full year 2025 | US$11.56B | +30% | Gross profit ≈48%; free cash flow $2.0B. Most money comes from services attached to subscriptions — not the subscription itself. |
| Wix | Full year 2025 | ~US$1.99B | +13% | ~68–70% gross margin selling productized, software-like services. Its agency/partner channel is its fastest-growing revenue line. |
| GoDaddy | Q2 2025 (SEC filing) | US$1.22B in one quarter | +8% | Grew revenue per customer +9.5% while having 2.2% fewer customers. Renewals and add-on services are the annuity. |
| Squarespace | Last public: Q2 2024 | US$296.8M that quarter | +20% | Taken private in Oct 2024 for $7.2B — no public financials exist after that, and anyone quoting you '2025 Squarespace numbers' is making them up. |
Sources: company earnings releases & SEC filings as compiled Oct 26, 2026. Figures are the companies' reported numbers; growth/margin targets elsewhere in this guide are labelled targets, not promises.
Steal · Hosted checkout (never handle card numbers yourself) and automatic order/abandoned-cart emails as a default, not an upgrade.
Avoid · Enterprise complexity and app bloat — $20–$300/month per add-on quietly eats a small store alive.
Steal · Pricing published in the open, itemized. In Canada: 2.9% + 30¢ per sale, no mystery fees. Trust comes from showing your math.
Avoid · Custom payment engineering on a small budget — use the hosted checkout paths the pros built.
Steal · Photography is a conversion lever. Their bookings jumped when listings got professional photos — same law for tattoo portfolios, menus and finished renos.
Avoid · Marketplace machinery (dynamic pricing, host dashboards) for a one-location business.
Steal · Let customers change or cancel themselves, and build a system that asks every happy customer for a review.
Avoid · Fake urgency — 'only 1 left!' pressure tactics. Regulators have sanctioned exactly that, and customers can smell it.
Steal · Show the total cost and delivery date before checkout, and send a proactive update at every status change. Certainty sells.
Avoid · Trying to out-Amazon Amazon. A local business wins on curation, service and being five minutes away.
Steal · Renewal systems and follow-up rhythms — nothing important should ever expire silently.
Avoid · Confusing renewal pricing and holding a client's domain hostage. In a local market, reputation is the whole business.
Menu as a real web page with prices (not a PDF), today's hours, one-tap ordering, real food photos.
Sticky call button, service-area page, licence & insurance proof up front, a response-time promise you keep.
Artist portfolios of real, healed work; deposit and cancellation terms in writing before booking — clarity is the conversion trick.
The owner's version of my launch gate, and the monthly rhythm that keeps a site healthy. Print this page and tick them off.
Yes — always. Your domain, hosting account and website belong to you, in your name. I work as a guest with my own login. Any builder who registers your domain in their name is holding your business hostage, politely.