How to Audit an Inherited Webflow Site You Did Not Build

TL;DR: Auditing an inherited Webflow site is not a design review. Before quoting work on a Webflow site you did not build, the job is to find what is missing, what is irreversible, and what is not legally yours to reuse. Five checks settle most of it, and they run in this order because any one of them can end the engagement before design comes up at all.

• Access and ownership. Only a Site manager can restore a Webflow backup, so an audit run from a Content editor seat has no rollback path.
• Plan and history. The free Starter Site plan restores only the two most recent backups, so most of the site's history may already be gone.
• Irreversible decisions. A larger breakpoint, once added, cannot be removed from a Webflow site.
• Redirects and robots.txt. Webflow fires 301 redirects oldest first, and Google reads only one robots.txt group per crawler.
• Rescue or rebuild. Workspace access, class naming, template licence, redirect debt and CMS fit decide which quote the client should get.

Most of what follows is checkable from Site settings, the live site and a browser. Two of them need more than that: the template licence needs a purchase receipt from the client, and the class system needs Designer access.

What should you check first on a Webflow site you did not build?

The first check on a Webflow site you did not build is access, not code. A Webflow site lives inside a Workspace, and whoever owns that Workspace controls billing, publishing and the backups. Webflow states plainly that "Only Site managers can access site backups", so an audit run from a Content editor seat has no rollback path at all (Webflow Help Center, Save and restore backups).

When I take on a rescue project, I will not open the Designer until the client can show me a Site manager login inside a Workspace their own company controls. The reason is practical rather than legal: a developer who cannot restore a backup cannot safely change anything.

Confirm all of the following before any other work starts:

• Which Workspace the site sits in, and which company name is on that Workspace.
• Whether the client holds a Site manager seat or only a Content editor seat.
• Who pays the Site plan invoice, and on which card.
• Where the domain is registered, which is often a different company entirely.
• Whether the previous developer still has access, and by what route.

If the access chain cannot be shown in Site settings rather than described in an email, stop the audit and fix ownership before quoting anything. Ownership of the accounts, not the files, is what decides who can act, and who actually owns a website covers the registrar side of that question in detail.

How do you tell what plan an inherited Webflow site is really on?

The Site plan on an inherited Webflow site is shown in Site settings under the Plans tab, and that single screen decides how much of the site's own history you can recover. A Site manager sees the plan name directly; anyone with a lower seat has to infer it from the live site instead.

Three signals identify the plan from outside the Designer, and they narrow it quickly:

• A live custom domain rules out the free Starter Site plan, because Starter serves only a webflow.io address.
• A working 301 redirect rules out an unpaid setup, because Webflow requires a paid Site plan or a paid Workspace plan before redirects can be added (Webflow Help Center, How do I set up redirects in Webflow?).
• A live CMS Collection rules out Basic, because the Webflow CMS starts at the Premium Site plan, listed at $25 per month billed yearly against $15 for Basic (Webflow pricing).

Backup depth follows from the plan. Webflow gives paid Site plans unlimited backups that can be restored at any time, while sites on the free Starter Site plan "can only be restored from one of the two most recent backups" unless a paid Workspace plan is attached (Webflow Help Center, Save and restore backups).

If the site turns out to be on the free Starter Site plan, put the upgrade at the top of the quote, because every other remediation step depends on being able to roll back.

How far back can you roll an inherited Webflow site?

How far back an inherited Webflow site can be rolled depends on cadence, not on elapsed time. Webflow does not offer scheduled backups and instead creates restore points automatically on every 50th auto-save, so the spacing between restore points reflects how much someone was working rather than how many weeks went by (Webflow Help Center, Save and restore backups).

Restoring an old backup on an inherited site is also not a neutral act. Webflow documents four side effects that an auditor should know about before promising a client a clean rollback, all on the same Save and restore backups page:

• Bot protection is turned off on the site when a backup is restored.
• reCAPTCHA settings are refreshed, so the keys have to be re-added in Site settings before forms work again.
• Restoring a backup created before March 25, 2024 resets Collection and Collection item IDs and breaks any API call or third-party connection that used them.
• The "Published on" date on every Collection item updates to the current date and time.

On the projects I lead, the first write action on an inherited site is always a manual restore point, created with Command + Shift + S and given a description naming the date the audit began. If the site is on the free Starter plan, take that restore point before anything else, because the second-oldest recoverable version is the only safety net you have.

What can and cannot be undone on an inherited Webflow site?

On an inherited Webflow site, an added larger breakpoint and a paid marketplace template licence are the permanent findings, and the Site plan, the redirect list, the Open Graph image and robots.txt are the reversible ones. A useful audit separates the two, because a rescue quote that treats a permanent finding as fixable will be wrong by the amount of work it forces forever afterwards. The table below is the version I keep open while auditing an inherited Webflow site, with the permanent rows first.

What the audit finds	Can it be undone?	What it actually costs
A larger breakpoint (1280px, 1440px or 1920px) was added	No. Webflow states that once added, a larger breakpoint "can't be removed from your site" (Webflow)	Styles set on that breakpoint can be cleared, but every future style pass has one more view to check
The build started from a paid marketplace template	No	An audit cannot make an unlicensed build licensed, so budget for a template purchase or for rebuilding the affected sections
The site is on the free Starter Site plan	Yes, by upgrading	Until the upgrade, only the 2 most recent backups are restorable, so earlier history is already gone (Webflow)
The 301 redirect list has grown past 1,000 rules	Yes	Every rule ships in the site manifest.json, so consolidating into wildcards is manual work (Webflow)
The Open Graph image was saved as AVIF or WebP	Yes	A fresh JPG or PNG has to be uploaded, because Webflow does not accept AVIF or WebP for Open Graph (Webflow)
robots.txt has named bot groups plus a wildcard group	Yes	Disallow rules must be repeated inside each named group, because Google does not combine them (Google)

Webflow does publish a partial escape hatch for the breakpoint case: the styles set on a larger breakpoint can be cleared by switching to that view and Option-clicking or Alt-clicking the blue style labels, even though the breakpoint itself stays (Webflow Help Center, Breakpoints overview).

Price the permanent rows as ongoing overhead and the reversible rows as one-off remediation. Mixing the two is the most common way a rescue quote comes in low.

Why do some 301 redirects on an inherited Webflow site never fire?

Redirects on an inherited Webflow site fail silently more often than they fail loudly, and the usual cause is ordering rather than syntax. Webflow "executes redirects in the order they were added to the site. Older redirects are tried first, then newer redirects", which means one broad wildcard added early will catch traffic before any later, more specific rule gets a chance to fire (Webflow Help Center, How do I set up redirects in Webflow?).

Sorting the redirect table by Date created in Site settings > Publishing > 301 redirects is the fastest way to see the real execution order. What I see agencies get wrong here is auditing the redirect list alphabetically, which hides the ordering problem completely.

Three further redirect traps are documented by Webflow and worth checking on any site you inherit:

• Webflow has no hard limit on redirect count but recommends 1,000 maximum as best practice, because every rule is uploaded to the manifest.json file that visitors download (Webflow Help Center).
• A trailing slash directly before a query string is stripped before matching, so an old path written as /slug/%?param%=value silently never fires.
• Redirects are relative to the root domain and do not apply to localized slugs, so a localized site needs a separate rule per locale.

If the inherited redirect list is longer than a screen, export it to CSV, sort by creation date, and move every wildcard to the end of the list before you promise the client that old URLs still resolve.

What SEO settings break on a Webflow site nobody has maintained?

The SEO layer on a neglected Webflow site breaks in three specific places: the Open Graph image, robots.txt and the sitemap. Each one is visible from outside the Designer, which makes them the fastest wins in an audit of a site you did not build.

Open Graph images are the first. Webflow's asset compression converts JPG and PNG files to AVIF or WebP, and Webflow separately states that "AVIF and WebP images aren't supported for Open Graph images" (Webflow Help Center, Control the look of social shares with Open Graph). A previous developer who compressed the whole Assets panel in one pass will have broken every social share preview on the site without any warning appearing in Webflow.

The robots.txt file is the second. Google's own specification is explicit that "Only one group is valid for a particular crawler" and that "User agent specific groups and global groups (*) are not combined" (Google, How Google interprets the robots.txt specification). A site that names Googlebot or Bingbot in its own group is therefore exempting those crawlers from every Disallow rule written under the wildcard group, which is almost never what the person who wrote the file intended.

The sitemap is the third. Webflow regenerates sitemap.xml on publish and stamps each URL with a lastmod tag that "updates automatically each time you publish changes to that page" (Webflow Help Center, Create a sitemap in Webflow). Read the spread of those dates rather than the newest one: a sitemap where most URLs carry the same timestamp points at one bulk change, not at pages being maintained individually.

Record the live sitemap.xml and robots.txt before you start editing, because your own remediation work moves the lastmod date on every page you touch and the original spread cannot be recovered afterwards. For the wider work that follows an inherited-site audit, the Webflow QA checklist covers the build-quality side and the Webflow SEO audit covers the ranking side.

How do you tell if a Webflow site was built from a paid template?

You can tell a Webflow site was built from a paid marketplace template from four signals visible in the build itself, before anyone produces paperwork. What the Single-Use License then allows is a contract question rather than an audit question, and the Webflow developer contract guide works through those terms.

An inherited site raises two practical questions the client usually has not considered. The first is whether a template licence was ever bought at all. The second is whether the same purchase is already running on other live sites built by the same developer, which is where the contract question starts.

Signs worth checking on a site you did not build:

• Class names and section structure that match a marketplace template rather than a custom build.
• Page names or Collection names left at the template author's defaults.
• No template purchase receipt anywhere in the client's records.
• The same layout visible on another live site from the same developer.

The last sign carries the most weight, because one live site is checkable and two are a pattern. When I audit a Webflow site for this, I ask for the template receipt in writing before quoting a redesign on top of it. If no receipt exists and the build is clearly template-based, price a template purchase into the quote and send the licence question to the client's own lawyer rather than absorbing it.

What goes wrong when an agency inherits someone else's Webflow site?

Price five failure modes into a rescue quote on an inherited Webflow site: phantom ownership, class sprawl, undocumented custom code, content pasted into rich text, and silent redirect loss. Naming them in the quote is what keeps a fixed price honest, and each one below carries the consequence it produces and the fix that removes it.

• Phantom ownership. Consequence: the client cannot approve a publish because the Workspace belongs to the previous agency. Fix: resolve ownership before quoting, using the route in transferring a Webflow site to a client.
• Class sprawl. Consequence: every visual change touches unrelated pages because one-off classes were duplicated instead of reused. Fix: quote a class audit as a separate line item, never as part of a page edit.
• Undocumented custom code. Consequence: a script nobody can explain breaks when the site is republished. Fix: inventory the head and footer blocks first, as set out in the Webflow custom code guide.
• Content pasted into rich text. Consequence: structured content lives inside one rich text field and cannot be filtered, sorted or reused. Fix: price the CMS restructure separately from the visual work.
• Silent redirect loss. Consequence: old URLs return 404s and the client blames the new developer for a ranking drop that predates them. Fix: capture the redirect list and a crawl of live URLs before touching anything.

Write each failure mode you actually find into the quote by name, with its consequence next to it. A client who has seen the failure mode written down accepts the remediation line far more readily than a client presented with a single unexplained number.

Should you fix the inherited Webflow site or rebuild it?

The fix-or-rebuild decision on an inherited Webflow site turns on how much of the underlying structure survives, not on how the site looks. Access, class naming, licence status, redirect debt and CMS fit are the inputs that decide it, and scoring them makes the answer defensible to a client who wants the cheaper option.

Agencies that take on inherited Webflow sites regularly tend to run this scoring before the first client call rather than after it, which is also how the delivery side of a white label Webflow workflow stays predictable. If the score lands in the middle band, quote the remediation and the re-architecture as two separate phases so the client can stop after the first.

Want a second opinion on the Webflow site you just inherited?

Bring the site to a 15-minute call and we will run the access, plan, redirect and robots checks live, on your screen. You leave with the list of findings, which ones are permanent, and a rough remediation range you can put in front of the client the same week. Book the 15-minute audit call.