What I Check Before Taking Over Someone Else's Webflow Site

What do I check before I agree to take over someone else's Webflow site?

Five things: who owns the account and the domain, what the site is connected to, what the CMS looks like under the hood, what search traffic it already earns, and why the last person left. I check all five before I quote. Most of the risk in a takeover sits in those answers, not in the design.

Taking over a site someone else built is a different job from building one. You inherit decisions you did not make, shortcuts you cannot see, and integrations nobody documented. A takeover can look like a small project on the first call and turn into a rebuild by week two.

After six years and more than 100 projects as a Certified Webflow Partner, I have a short list of checks I run before I agree to anything. It protects the client as much as it protects me, because it turns surprises into scope before anyone signs.

Who actually owns the Webflow account and the domain?

The client should, and often they do not. Before anything else, I confirm which Workspace the site sits in, who pays for the site plan, and who controls the domain registrar and DNS. If any of those sit with a former freelancer or an old vendor, getting access is step one of the project.

This sounds administrative, and it is. It is also the step most likely to stall a project for weeks. A domain registered under someone's personal account, with a login nobody remembers, can block a launch completely.

I ask for access to everything up front, not halfway through. If the client cannot get access to the domain or the Workspace, I do not start building. I help them get access first. My checklist for domains in particular is in what to check before you point a domain at a new site.

What is the site connected to?

Everything that sends or receives data: forms, CRM, analytics, tag managers, chat widgets, scheduling tools, and any automations through Zapier, Make, or custom code. I list each connection, what it does, and who set it up. The site is rarely the fragile part. The connections are.

The most common surprise is a form that feeds a CRM through an automation nobody remembers building. Change the form field names during a redesign, and leads quietly stop reaching sales. Nobody notices until someone asks why the pipeline is empty.

I trace every form from submission to its final destination before I touch it. If an automation outlived the person who built it, treat it as part of the site and document it before you change anything around it.

What does the CMS look like under the hood?

I open every collection and look at the fields, the reference structure, and how the templates use them. A clean CMS can be extended in a day. A messy one, with duplicate fields, unused collections, and content pasted into rich text blocks, can turn every change into a manual job.

Signs of trouble include fields named "new field 2," collections with a handful of items that nothing references, and blog posts where the layout lives inside the rich text instead of the template. Each of those means more time on any future change.

I do not try to fix the CMS during the first look. I write down what I see and how it affects the work the client wants. That note goes straight into the scope.

What search traffic is the site already earning?

Before I change any URL or page structure, I look at which pages bring in search traffic and which queries they rank for. A redesign that ignores existing rankings can wipe out months of organic growth. Knowing what already works tells me what I must protect.

I ask for Search Console access on day one. If the client does not have it set up, that becomes the first task. Then I list the top pages by clicks and mark them as protected. Their URLs stay the same, or they get a clean redirect.

For a structured way to do this, I wrote about building a keyword to page map for a site you inherited. It is the single most useful document in a takeover.

Why did the last person leave?

I always ask, and I listen carefully to the answer. Sometimes the previous builder simply moved on. Sometimes the scope kept growing without a budget, or decisions kept changing. The reason tells me what kind of project this will be, and whether I am the right fit for it.

I am not looking for someone to blame. I am looking for patterns. If the client says the last person was too slow, I ask what "fast" means to them. If they say the last person did not understand the business, I ask what was missed. Those answers shape how I scope and communicate.

Occasionally the honest answer tells me to pass. If the same problems that ended the last engagement are still present, I would rather say so on the first call than three months in.

How do I turn these checks into a quote?

Every finding becomes a line in the scope with a clear cost or a clear exclusion. Access problems, undocumented integrations, and CMS cleanup either get included and priced, or written down as out of scope. My projects are fixed fee, so the checks are what make a fixed price fair for both sides.

Most of my projects fall between $1,000 and $10,000. Where a takeover lands in that range depends almost entirely on what the five checks uncover. A site with clean access, documented connections, and a tidy CMS sits at the low end. A site with none of those sits much higher.

I explain the reasoning in the proposal itself, so the client can see why the price is what it is. The structure I use is in what I put in a fixed fee proposal.

What do I do in the first week after taking over?

Nothing visible. I back up what I can, document every connection, set up monitoring for forms and key pages, and confirm that leads still arrive where they should. Only then do I change anything a visitor can see. A quiet first week prevents most takeover disasters.

It can feel slow to a client who wants to see progress. I explain it as insurance. If something breaks later, the client and I will both know whether it was already broken or broke during my work, and that saves a lot of difficult conversations.

By the end of that week, I have a written map of the site and its connections. That map stays with the client whether or not they keep working with me. The same habit starts even earlier in my process, which I explain in why I ask for access before I send a proposal.

What should you do next?

If you are about to hand your Webflow site to a new builder, gather the access first: Workspace, domain, DNS, Search Console, and every connected tool. Write down what each integration does. Then share it all on the first call. You will get a better quote and a smoother start.

If you have a Webflow site that needs a new owner and you want someone to look at it honestly before quoting, reach out. I am happy to run these checks with you and tell you what I find.