Can a website provider work with my current registrar and host?

Usually, yes. A provider should first review the registrar, DNS provider, host, email records, and access already in place. Cloudflare DNS can be used without moving the domain registration or changing the web host. A full Cloudflare DNS setup does require a nameserver change at the registrar.

Should my business own the domain, hosting, and analytics accounts?

Yes. The business should hold the primary ownership, recovery methods, and billing for its domain, hosting, analytics, and advertising accounts. A provider should receive the access needed to do the work without becoming the only person who can control or recover those assets.

Is a static website always the right choice?

No. A static site is a strong fit for many service and content websites because it has fewer moving parts and can be delivered quickly. A site that needs complex logged-in features, frequent database changes, or a large editorial team may need a different architecture.

What analytics should a website provider install?

Only the tools the business will use. Google Analytics can measure acquisition and key events. PostHog can add funnels and session analysis. The provider should define the actions that matter, test them on the live site, document consent requirements, and avoid collecting data without a clear purpose.

When is a website launch actually complete?

A launch is complete when every item in scope has been checked on the production site. That includes the live domain, forms, email, search settings, security controls, analytics events, and advertising conversions. A successful upload or green deployment is not proof that the customer experience works.

Website Provider Checklist: What Good Work Looks Like

Written by Blake Mitchell from the checks Wired Builder uses on client work. Reviewed September 18, 2026.

This website provider checklist is for business owners hiring a developer, freelancer, or agency. It also works as a website launch checklist. It focuses on the parts that are easy to miss and expensive to repair. Who owns the accounts? Did DNS and email survive the launch? What was tested on the live site? Can analytics and advertising prove a real customer action happened?

Use it before work starts, again before launch, and once more at handover. Not every website needs every tool on this page. A good provider should be able to explain what applies, what does not, and what evidence closes each item.

The short version

Before you approve the final invoice, confirm these eight things.

Your business owns the domain, hosting, analytics, and advertising accounts.
The provider recorded the DNS and email setup before changing it.
The existing website was reviewed before a rebuild was recommended.
Code and content changes passed documented checks before deployment.
The provider tested the real production domain after deployment.
Security settings match the site, and higher-risk changes were approved.
Analytics record meaningful actions, not only page views.
Advertising launched only after conversion tracking, consent, and spend were approved.

1. Ownership and access: you should keep the keys

Your website may depend on a registrar, DNS provider, host, source-code repository, analytics property, advertising account, and email service. If those accounts belong to the provider, changing providers can become a negotiation over your own business assets.

The safer standard is simple. Your business owns the accounts, recovery methods, and billing. The provider receives the access required to do the work. Shared access can be removed without moving the domain or rebuilding the site.

The domain registration is in the business's name.
The owner controls the primary login, recovery email, and two-factor authentication.
Hosting, analytics, and advertising billing go directly to the business.
The agreement separates setup from optional ongoing management.
The provider documents the access it received and what can be revoked later.

Why this matters: ownership keeps a vendor change from becoming a website, email, or advertising emergency.

2. DNS and email: no silent collateral damage

DNS decides where your website and business email go. A website can look perfect in preview while a missing mail record quietly stops enquiries, invoices, or staff email after launch.

A responsible provider maps the current setup before changing nameservers or records. That includes the records serving the website and the email records in use, such as MX, SPF, DKIM, and DMARC. They should also review DNSSEC, renewal ownership, and any subdomains that point to other systems.

Export or document the current DNS records before any change.
Confirm the website, email, forms, and important subdomains that depend on them.
Explain who must approve a nameserver or registrar change.
Plan the order of work, including DNSSEC prerequisites.
Verify website resolution and email-related records again after the change.

Ask your provider: “Show me the before-and-after DNS record, and tell me how you proved email still works.”

3. Website and static website checks: test the result, not the upload

Before recommending a rebuild, the provider should inspect the site you already have. The review should cover page titles and descriptions, canonical URLs, sitemaps, structured data, mobile use, accessibility signals, forms, contact paths, performance, and security headers. The recommendation should follow the evidence, not the provider's favourite tool.

When a static website is the right fit, pages are built ahead of time instead of assembled from a database and plugins on every visit. That can reduce moving parts and improve delivery speed. It is not the right architecture for every application, and a provider should say so when logged-in features or frequent database changes require something else.

In our workflow, changes pass type checks, automated tests, and a production build before deployment. The live site is then checked again. A green upload is not enough. The correct page, forms, redirects, analytics, and required response headers must be present on the public domain.

A preview exists before the production change.
The provider can show the checks that gate a deployment.
Old URLs have a redirect plan when the site structure changes.
Forms are submitted with real test data and confirmed at their destination.
A rollback path exists if the production check fails.

Why this matters: a build can succeed while the wrong environment, missing setting, or broken form reaches customers.

4. Cloudflare and domain security: keep your digital front door under control

Your domain sits underneath your website and business email. One careless change can interrupt both. If the account belongs to a vendor, you may also need their permission to control your own address.

We can work with your existing registrar, DNS provider, and host. If the setup is secure and working well, we leave it in place.

We often recommend Cloudflare because one client-owned account brings together domain records, HTTPS certificates, faster content delivery, DDoS protection, and firewall controls. Cloudflare offers a free plan and paid plans with additional controls and support. We match the plan to the site's importance and risk. The account and billing remain in your name.

Before changing anything, we audit the setup in read-only mode. We explain risks in plain English and ask for approval before higher-risk changes. For supported Cloudflare changes, we check the setting again to confirm it landed.

The review can include HTTPS enforcement, SSL mode, modern TLS, compression, HTTP/3, HSTS, DNSSEC, and related zone settings. Each setting has prerequisites. HSTS, for example, should not be applied blindly to subdomains that cannot serve HTTPS.

For you, that means: fewer preventable outages, less vendor dependence, and clear ownership of one of your most important business assets.

Cloudflare confirms that its DNS can be used without moving your registration or changing your web host. Read the Cloudflare DNS FAQ and current plan information.

5. Google Analytics and PostHog: measure leads, not just traffic

Analytics should answer business questions. Google Analytics can show how visitors arrived and whether they completed an important action. PostHog can add funnels and session analysis that help explain where people leave a path.

The useful events are usually phone clicks, confirmed form submissions, booking clicks, purchases, and other calls to action that represent intent. Google describes these important interactions as events and key events. Page views alone do not prove the website generated an enquiry.

A provider should name each event, state what triggers it, test it on the live site, and show where it appears in reporting. PostHog should be configured only for the analysis the business needs, with privacy, consent, and page performance considered before launch. Its own product description covers product analytics and session replay.

The analytics properties and history belong to the business.
Important events have plain-English names and documented triggers.
Confirmed outcomes are distinguished from button clicks when possible.
Live test events appear in the intended property or project.
The privacy notice and consent behaviour match the tools in use.

6. Google Ads and AdRoll: do not spend before measurement works

Google Ads and AdRoll do different jobs. Google Ads can reach people searching for a service. AdRoll can support retargeting for people who have already visited the website. Neither should be treated as “installed” simply because a tag was added.

For Google Ads, the provider should connect the agreed conversion actions and confirm which actions are primary. Google explains that primary actions can be used for bidding, while secondary actions are for observation. That distinction affects what the campaign tries to produce. Read Google's primary and secondary conversion guidance.

When AdRoll is in scope, the provider should install and verify its pixel, connect the agreed conversions, and confirm that the intended website audiences begin populating. AdRoll states that its pixel supports website audiences, conversion audiences, and retargeting. It also explains that the pixel does not fire for a visitor who is shown a consent banner but does not consent. Review the AdRoll Pixel documentation and its visitor consent guidance.

Campaign creative, targeting, budgets, and ongoing management should be scoped separately. The ad accounts and billing should remain with the business, and no campaign should begin spending without explicit approval.

The business owns the Google Ads and AdRoll accounts.
The named conversion actions fire and appear in the correct account.
Primary conversions represent real business outcomes.
AdRoll audiences and consent behaviour are checked before launch.
Campaign status, budget, locations, creative, and launch authority are explicit.

7. What proof should you receive at handover?

A good handover leaves evidence another qualified provider can understand.

Area	Proof to expect
Ownership	Account list, owner, billing owner, recovery method, and provider access.
DNS and email	Before-and-after records, nameservers, DNSSEC state, and email-related records.
Website	Source-code location, deployment record, test results, redirects, and rollback path.
Live launch	Production URL, form submission proof, response headers, and smoke-test result.
Analytics	Property ownership, event list, trigger definitions, and live event confirmation.
Advertising	Account ownership, conversion status, campaign status, budget, and approval record.
Privacy	Tools collecting data, consent behaviour, and the matching privacy notice.

Red flags before you sign off

The provider owns your domain or is the only person who can recover the account.
Nobody can show what the DNS records looked like before the change.
The launch is called complete because the upload succeeded.
Forms, email delivery, redirects, or analytics were not tested on the public domain.
Advertising is active without verified conversion actions and an approved budget.
Tracking tools were installed without a consent or privacy review.
The provider promises the website cannot be hacked.
There is no written handover, rollback path, or way for another provider to take over.

The Wired Builder standard

This checklist comes from the controls we use in our own work. We audit before changing, separate read-only checks from approved writes, gate higher-risk steps for a person to review, and verify the live result after deployment. We document what was included and what still requires the account owner, registrar, ad manager, or another specialist.

We built these controls after seeing false confidence in real work. Analytics existed in local files but was missing from the production site. DNSSEC appeared active in a dashboard before public resolvers agreed. That is why our final checks happen at the live boundary.

That is not a promise that nothing can fail. It is a practical standard for reducing preventable mistakes, keeping the business in control, and making the result easier to verify.

Read more about why we audit before we build, how we hand work back to the owner, or see our small business website service.

Review your website with us Download the one-page checklist

Common questions

Can a website provider work with my current registrar and host?: Usually, yes. A provider should first review the registrar, DNS provider, host, email records, and access already in place. Cloudflare DNS can be used without moving the domain registration or changing the web host. A full Cloudflare DNS setup does require a nameserver change at the registrar.
Should my business own the domain, hosting, and analytics accounts?: Yes. The business should hold the primary ownership, recovery methods, and billing for its domain, hosting, analytics, and advertising accounts. A provider should receive the access needed to do the work without becoming the only person who can control or recover those assets.
Is a static website always the right choice?: No. A static site is a strong fit for many service and content websites because it has fewer moving parts and can be delivered quickly. A site that needs complex logged-in features, frequent database changes, or a large editorial team may need a different architecture.
What analytics should a website provider install?: Only the tools the business will use. Google Analytics can measure acquisition and key events. PostHog can add funnels and session analysis. The provider should define the actions that matter, test them on the live site, document consent requirements, and avoid collecting data without a clear purpose.
When is a website launch actually complete?: A launch is complete when every item in scope has been checked on the production site. That includes the live domain, forms, email, search settings, security controls, analytics events, and advertising conversions. A successful upload or green deployment is not proof that the customer experience works.