Check access, structure, and damage, in that order. Confirm you have real ownership rather than a shared login. Then read how the site is built before you judge how it looks. Most of the risk in an inherited site is invisible in the browser and obvious in the Designer.
Taking over a site somebody else built is one of the most common things we do, and it is the work most likely to go wrong on price. A site that looks tidy on the surface can hide a class structure that makes every future edit expensive.
What follows is the audit we run before quoting. It takes an hour or two and it has saved us from a lot of bad projects.
Because you inherit every decision the last team made, including the ones nobody documented. The visual design is the only part you can evaluate from outside. Naming conventions, CMS structure, redirect history, and custom code are all invisible until you are already inside and already committed.
The pattern is familiar. A client asks for what sounds like a small change. Two hours in, you find the change touches a class used on forty other elements, and the honest options are to break something or to rebuild a section that was never in scope. Neither conversation is fun to have after the quote is signed.
The fix is not to be pessimistic about inherited sites. It is to spend the first hour finding out which kind of site it is, so the quote reflects reality. We have delivered over 150 projects, and the ones that hurt were almost always the ones we priced before we looked properly.
Get owner level access to the Webflow Workspace, not a seat that someone can revoke. Confirm who controls the domain registrar, the DNS records, the analytics property, and any third party services the site depends on. A login you were handed informally is not access, it is a favor.
The registrar is the one people forget. A site can be built beautifully and still be hostage to a domain registered in a former contractor's personal account. Find out before launch day, not during it, because chasing a name on an old invoice while a client waits is a genuinely awful afternoon.
Write down who owns what while you are asking. On a handful of projects that list is the most valuable document produced in the first week. Our guide to Webflow client handoff covers the same ground from the other direction, which is a useful way to see what should have been given to you.
Open the Style panel and read the class names. That tells you more in five minutes than an hour of clicking through pages. Clear, systematic names suggest a build you can extend safely. A wall of combo classes and names like "div block 47" tells you the opposite.
We look for a consistent convention rather than a specific one. Finsweet's Client-First is the closest thing Webflow has to a shared standard, and a site built on it is usually straightforward to pick up because the logic is documented publicly. Our breakdown of Finsweet Client-First explains why that predictability matters more than any particular naming style.
Then check for style overrides on individual elements. A build where designers styled elements directly instead of through classes will look correct and behave chaotically. Every change becomes a hunt for the one element that did not get the memo, and that hunt is billable time your client will not enjoy paying for.
Look at the Collections and ask whether the structure matches the content, or whether the content has been forced into a structure that no longer fits. Check for reference fields doing real work, collections that duplicate each other, and rich text fields being used to store layout.
Rich text abuse is the most common problem we find. When a team hits a structural limit, the tempting shortcut is to paste formatted content into a rich text field and move on. It works, and it quietly ends any chance of reusing that content anywhere else, because the meaning is now trapped inside markup.
Also count the items. A collection approaching its limit is a constraint you inherit whether or not anyone mentions it, and discovering it mid project turns a content migration into a platform conversation. Check the numbers against the site's current plan before you promise anyone a scale up.
Canonical tags, meta descriptions, and redirects, in roughly that order. These are easy to set, easy to forget, and invisible until traffic moves. On a site that has changed hands once or twice already, assume all three need checking rather than assuming the last team handled them.
The web wide numbers make the point. The 2025 Web Almanac from HTTP Archive found canonical tags on only 68% of desktop pages and meta descriptions on 67.7%, even though title tags appear on 98.62%. Teams reliably do the visible part and skip the part nobody sees in the browser.
Redirects deserve their own pass. If the site has been redesigned before, there is usually a layer of old URLs mapped to new ones, and sometimes chains of them pointing at pages that no longer exist. Broken redirect history is one of the quieter ways a redesign loses traffic that the previous team never traced.
Check the head as well. That same Web Almanac report found invalid HTML inside the head element on 10.1% of desktop pages, which can silently truncate everything after the error, including your meta tags. A single stray element pasted into a custom code field can undo a whole SEO setup.
Run Lighthouse for a baseline, then check the three things it cannot see well: keyboard navigation, focus visibility, and whether form inputs have real labels. Tab through the whole site once. If you cannot reach and see every interactive element, neither can a large group of your client's users.
Focus indicators are the most common casualty of a pretty build. The 2025 Web Almanac found that 67% of sites explicitly removed default focus outlines, up 14% from 2024, while only about 25% of pages had adopted the focus-visible pseudo class that would replace them properly. Designers remove the outline because it looks untidy, and rarely put anything back.
Form labels are the second. The same report found that only around 35% of mobile inputs got their accessible name from a properly associated label element, while 53% of desktop and 55% of mobile inputs relied on placeholder text alone. Placeholders disappear the moment someone starts typing, which is exactly when a person using a screen reader needs the label most.
Color contrast is worth a quick look too, since the Web Almanac found only 30% of sites meeting sufficient contrast. If you are formally assessing a site against a standard, the WCAG guidelines themselves are worth reading closely, because they cover what actually has to be met rather than what is merely nice to have.
Repair when the structure is sound and the problems are cosmetic or additive. Rebuild when the class system is broken, because everything you add on top of a broken system inherits the problem. The test is whether a small change stays small, and you can answer that within an hour in the Designer.
We are biased against rebuilds and we say so openly, because a rebuild is the expensive option and clients are right to be suspicious of studios that always recommend it. A site that is merely unfashionable does not need replacing. A site where a button change requires touching six classes does.
Performance sits somewhere in between. Slow inherited sites are often fixable without a rebuild, since most of the weight is usually images and third party scripts rather than the build itself. We hold a PageSpeed average of 98 across our projects, and on takeover work a good share of that comes from removing things rather than rebuilding them.
Take a backup and record the current state before your first edit. Capture the existing site as it stands, note the current Core Web Vitals, and save the live HTML of key pages. Without a before, you cannot prove an after, and you cannot cleanly undo a mistake.
Webflow keeps its own version history, and knowing how it works before you need it is much better than learning during an incident. Our guide to Webflow backups and versioning covers how to use it deliberately rather than hopefully.
Record the numbers too. The 2025 Web Almanac found only 56% of desktop and 48% of mobile experiences earning a good overall Core Web Vitals assessment, so an inherited site failing them is unremarkable. What matters is having the starting figure written down, so the improvement you deliver is a fact rather than a claim.
Spend one hour in the Designer before you quote. Read the class names, open two or three Collections, tab through the homepage, and check the redirect list. That hour tells you whether this is a repair job or a rebuild, and it is the difference between a profitable project and a painful one.
The instinct to skip this is strong, especially when a client is keen and the site looks fine. We have learned to treat a client who is in a hurry to skip the audit as information rather than as urgency. Sites that were built carefully are usually easy to show off.
If you have inherited a Webflow site and you are not sure what you are looking at, we are happy to take a look with you. We do this often enough to tell fairly quickly whether it needs a rebuild or just a good week of repairs. Reach out through phoenix.studio and let's talk it through.
Tell us where you want to go. We'll tell you how we'd get you there.