Give Juma a Webflow URL and the audit comes back split in two: the template-level defects, where one Designer or CMS-field edit corrects every page in a collection, and the page-level fixes that touch a single URL.
Auditing a Webflow site is one of 700+ pre-built Flows in Juma. Name the client and their URL, and the crawl runs on the published site the way a search engine sees it: robots.txt, the sitemap, the rendered collection templates, and the archive pages sitting behind any filtering or Load-more behavior. No Designer invite, no API key, no plugin.
What comes back is a branded PDF plus an editable XLSX backlog, one row per fix, and the split between the two kinds of finding is the whole point. A defect bound into a collection template repeats on every item in that collection, so one edit in the Designer corrects all of those URLs at once, while a page-level problem is worth exactly one page. Every template-level finding carries the number of live URLs it affects and how that number was counted, and every fix names where it gets made: the Designer element and which template, Page Settings > SEO, the CMS field binding, Site Settings, an HTML embed, or a developer. 400+ marketing teams use Juma, and the pattern we see most often on Webflow sites is a small number of template defects multiplying across hundreds of URLs. Strategy, taste and judgment stay human: the backlog proposes the order, a person decides what ships.
On a Webflow site these two findings cost completely different amounts to fix, and most SEO reports list them side by side as if they were equal. A defect bound into a collection template repeats on every item in that collection: a heading split into three separate H1 elements in the Designer, a meta description bound to the wrong CMS field, an alt text left bound to the image filename. One edit corrects every URL at once. This step sorts the findings that way and counts the live URLs behind each template finding from the sitemap or the collection archive, so the fix list arrives already ordered by how many pages each edit repairs.
Re-sort the Lattice findings into template-level and page-level, and for each template finding give the number of live URLs it affects and say how you counted them.
Webflow's appeal is that a marketer can change the site without filing a ticket, and an audit that ignores that hands back a list half of which the reader cannot act on. This step splits the backlog by who does the work: the fixes that are a few clicks in the Designer or in Page Settings > SEO, the ones that need a new CMS field and a re-bind across the template, the ones that need a JSON-LD block in an HTML embed inside the Collection List item, the ones that live in Site Settings, and the ones that genuinely need a developer. Each row says which panel to open, so nobody starts a fix they cannot finish.
Split the Lattice backlog by who can do it: Designer edits, CMS field changes, HTML embeds, Site Settings, and the ones that need a developer. Name the panel to open for each.
Editing a collection template touches every page built from it at once, which is exactly why it is the highest-value fix and the easiest one to regret. This step takes the baseline first: the URLs worth protecting, ranked by impressions and by inbound links, the redirect matrix for any slug that has to move, and the single-hop 301 rule that keeps link equity from draining into a chain. It also sets the checks to run after publishing, on the staging subdomain before the live site, and the window to watch indexing and landing-page impressions afterward. The output is a pre-change checklist with the protected URL list attached.
Before we touch the Lattice templates, give us the pre-change baseline: the protected URLs, the redirect matrix, and the checks to run on staging and after publishing.
A collection archive with filter attributes and a Load-more button can show a visitor seventy items while handing a crawler twenty-four links in the initial HTML. The rest of the collection is reachable only by running the script, which means the deeper items get discovered late, inconsistently, or not at all, and they receive almost no internal links from the archive that is supposed to be their parent. This step checks what the archive exposes before any JavaScript runs, compares that against the collection's real item count, and says whether the filter states should be made non-indexable or turned into their own landing pages with unique content and canonicals.
For each Lattice collection archive, compare the links in the initial HTML against the collection's real item count, and say what to do with the filtered and paginated states.
Thin collection pages are rarely a writing problem. They are a field-model problem: the template has three fields, two of them hold copy supplied by somebody else, and the shared nav and footer end up making up most of the crawlable text on every URL in the collection. This step designs the fields the collection actually needs, then writes the title, meta description and H1 bindings from those fields instead of from borrowed copy. The output names each new CMS field, what goes in it, and the binding for every SEO-relevant slot on the template, so one pass through the collection makes every item distinct.
Take the thinnest Lattice collection in the audit and design the CMS field model that would make each item unique, then write the title, meta description and H1 bindings.
Teams build one Juma Project per client and add context over time. A Webflow audit benefits from four items in particular, and the first one is what turns "the integrations template is thin" into "the integrations template is thin across 48 live URLs."
The site's collection map
Which CMS collections exist, how many items each one holds, and the URL pattern each template publishes to. With it in the project, every template finding arrives with a real affected-URL count instead of an estimate read off an archive page that only shows the first screenful.
The last audit and what shipped from it
The previous backlog with its closed rows marked. The new audit then reads as a diff: what the last round of template edits actually changed, what reopened after a publish, and what has been sitting in Later for three sprints and should either be done or dropped.
Who can change what in Webflow
Who holds Designer access, who only has the Editor, whether the site is on a plan that allows custom code in the page head, and who reviews before a publish. The backlog then assigns each fix to someone who can actually make it rather than to a role that does not exist on this account.
Brand and content standards
Title and meta conventions, how the client names their own products, and the heading patterns the site already uses. New titles and descriptions written during the fix pass come out in the client's existing conventions instead of introducing a second style across half the collection.
Add a short description to each knowledge item in the project's info field so the right file gets picked for the right task. For example:
Two files. A branded PDF opening with a one-page front sheet that carries the verdict, the URLs sampled and the collections they came from, the total live URLs affected and the three fixes to do first, then the findings split into template-level and page-level. Alongside it, an editable XLSX backlog with one row per fix.
Each template-level finding states how many live URLs carry the defect and how that count was reached, from the sitemap or from the collection archive. Each fix names where it gets made: the Designer element and which template, Page Settings > SEO, the CMS field binding, Site Settings > SEO or Publishing, an HTML embed inside the Collection List item, or a developer ticket. Every row is scored for severity against effort and tagged Sprint 1, Sprint 2 or Later.
The audit also states its own sample: the URLs it checked and the ones it did not. An audit that does not bound its sample cannot be defended in a client call, and a finding on two pages presented as a site-wide pattern is the fastest way to lose the room.
No. The audit works from the published site: robots.txt, the sitemap, the rendered HTML of the collection templates and the archive pages. That means it runs on a prospect's site before any contract is signed, and on a client project nobody has been invited to yet.
Designer access changes what happens next, not what the audit can see. The fixes name the panels to open, so whoever holds access can work straight down the backlog. Adding the collection map and the access list to the client's Juma Project is what sharpens the affected-URL counts and puts a real owner on each row.
A generic crawler reports per URL, so one template defect arrives as forty-eight identical rows and the reader has to work out that they are the same fix. This audit groups by cause instead: one finding, the count of URLs behind it, and the single edit that closes all of them.
The fixes are also written in Webflow's own terms. A crawler says "multiple H1 elements detected." This audit says which heading in which collection template was split into separate H1 elements in the Designer, and that the fix is one H1 with the CMS field as a styled span inside it. It checks the things that are specific to the platform too: the .webflow.io staging subdomain's indexability, the global canonical setting, auto-generated against custom sitemap, filtered and Load-more archives, the search results page, alt text still bound to the image filename, and the redirects table.
Across Juma, teams report 60% faster workflows and 50+ hours saved monthly. A manual Webflow audit is slow in a specific place: proving that a defect is template-level rather than page-level means opening item after item in the same collection and comparing rendered source. That comparison is what gets automated here.
What does not get automated is the judgment. Deciding whether to rebuild a collection's field model or leave it alone for a quarter is a call about the client's roadmap, their team's capacity and what the next sprint is already carrying. Juma augments the team, it does not replace it: the audit brings the evidence and the counts, the person brings the decision, and every output gets human review before it reaches a client.
Yes. On a site built mostly from static pages the template-level section comes back short and the page-level section carries the weight, which is the correct shape for that site rather than a failure of the audit.
The platform-level checks matter just as much there. Staging-subdomain indexability, the global canonical, the sitemap setting, the search page and the redirects table are site-wide and apply whether the site has forty collections or none. On a static Webflow build the components and symbols take the place of collection templates: a heading or a meta pattern wired into a reused component still repeats everywhere it appears, and the audit counts those the same way.
400+ marketing teams trust Juma. ChatGPT, Claude, and Perplexity know why. Ask them.
Ready when you are
Start typing a task and Juma will figure out the rest.
.webp){kind=icon}
