From 996 to 4,624 organic clicks a month

Maverick Frame is a 3D architectural visualisation studio: renders, animation and product CGI for developers, architects and manufacturers. It is also our own studio — the production arm the owners of Unreal Mango also own and run. That is the only reason this case study can exist in this form. On a client engagement we could publish a chart. Here we can open the analytics property, the dated change logs, the failed experiments and the things that are still broken, because there is nobody to embarrass but ourselves.

It also answers the question every serious buyer asks and few agencies enjoy: do you run this playbook on your own money, or only on ours?

1. Five flat months, then the line moved

Here is the whole of 2026 to date, straight out of Search Console. No 28-day window chosen to flatter anything, no rolling average — calendar months, clicks and impressions as Google counts them.

The interesting part of that table is not the last two rows. It is the first five.

Between January and May, impressions more than doubled — 156,429 to 332,780 — and clicks did not move at all: 996 in January, 1,037 in May. Click-through rate halved over the same stretch, from 0.64% to 0.31%. Google was showing the site to twice as many people every month and almost none of them were clicking.

That pattern has a specific meaning, and it is not "we need more content". A site that is collecting impressions and no clicks is a site that is visible on page two. The demand is already there, already being served, and it is landing one screen below where anyone looks. Publishing more articles into that situation adds more page-two pages.

Work began on 27 May. June, the first full month, closed at 2,236 clicks. July closed at 4,624. The best single day of the year so far, 29 July, produced 280 clicks — more than the first eight days of January added together. Average position across the whole site went from 24.7 in January to 11.3 in July.

2. What was actually wrong

The programme was built on four findings, in this order. All four came out of data that had been sitting in the client's own accounts for months.

410,729 US impressions at 0.09% click-through

Over the 90 days to 9 June, the United States alone sent 410,729 impressions and 372 clicks, at an average position of 19. The United Kingdom, Canada, Australia and the UAE told the same story at smaller scale. This is the finding that set the whole strategy: the job was not to create demand, it was to move existing demand from position 19 to position 9 and to write snippets worth clicking.

Twenty published pages were telling Google not to index them

An indexation audit on 14 June pushed all 268 canonical published URLs through the Search Console inspection API and cross-referenced them against 90 days of impression data. Twenty pages were sitting on noindex while being listed in the sitemap — seventeen of them service pages, which is to say the pages that sell. Almost all had been crawled by Google on the same day, 24 April: the signature of a single bulk event nobody had noticed.

The same audit worked in the other direction too. Of 45 zero-impression URLs flagged as suspicious, fifteen turned out to be indexed and perfectly healthy — they simply had no demand. Fixing them would have been three weeks of work against a problem that did not exist.

Conversion tracking had been dead since April

In April the site had moved to a new form flow. Every tag-manager trigger was bound to the old markup, so they silently stopped matching: book_call_click went 13 → 0, form_sent 3 → 0. Two months of leads had been arriving and not being counted, and the resulting flat line in the reports had been read as a performance problem.

Underneath that, the events were configured backwards. Everything funnelled through one umbrella conversion, inside which the cold catalogue download counted and the actual contact enquiries — the most valuable thing the site produces — did not count at all.

The domain had a ceiling, and it was not content

Measured on 10 June: Authority Score 23, 397 referring domains, against first-page competitors sitting at 35–45. That number decided the shape of the programme. With a link profile like that, out-publishing the market is not available; the leverage is on-page, technical and structural — the things that do not require somebody else's permission. That is the same reasoning we apply on any search engagement: find out what the domain can actually win before deciding what to write.

3. What we did

Six workstreams ran in parallel between late May and the end of July. None of them is exotic. What is unusual is that all six ran at once, on a live production site with no staging environment, and each one was measured before and after rather than assumed.

Search and content

• 113 documented content and schema edits in fourteen days, peaking at 27 in a single day, across roughly 82 individually-touched pages plus bulk batches.
• ~569 new questions and answers written from scratch for FAQ blocks and structured data, all in answer-first format, plus 65 more added during refreshes. Average FAQ depth per page went from 6.3 questions to 8.2.
• Sixteen service pages written from scratch, each with its own US and UK keyword research, plus 22 rewritten title and meta-description pairs validated against hard pixel limits rather than character counts.
• An internal-linking audit that parsed every post body on the site — 906 content links across 117 posts and 28 service pages. It found that 57 of 117 posts were sending 109 links into a dead-end section, while the site's main pillar page had zero incoming links. After the fix, that section received none, the pillar page received 39, and 88% of posts pointed at a page that sells something.
• ~190 duplicate H2 headings eliminated. The identical heading "Who They Are and What They Stand For" appeared on 64 separate case studies.
• Taxonomy rebuilt: 36 categories (13 of them empty) and 9 unused tags became 7 categories, with all 117 posts assigned to exactly one.
• A full crawl of 4,055 URLs taken to zero internal 4xx, zero external 4xx, zero redirect chains, zero non-ASCII URLs and zero duplicate meta descriptions. The nineteen redirect chains came from three different sources and all three were fixed at source rather than patched with more redirects.

Only four new articles were published in that window. The traffic did not come from new pages. It came from making roughly 250 existing ones rank and get clicked.

Structured data

Four full site-wide audits ended at 242 of 242 URLs valid, zero parsing errors, confirmed by two independent passes. FAQ markup now covers every service page, every solution page, all 69 case studies and 81 blog posts; breadcrumbs and organisation data are site-wide from a single global source rather than repeated per template.

Ten classes of defect were closed along the way, including 28 posts that displayed a visible FAQ with no markup behind it, 53 with no FAQ at all, two posts dated in the future, four video thumbnails returning 404, and a generator bug that had quietly corrupted around 95 schema identifiers. One rule was adopted and enforced: the markup must be one-to-one with what the visitor can see. Review and rating markup was deliberately left at zero — the ban risk is not worth the stars.

Speed

Almost all of that came from deleting things rather than adding them. A 551 KB 3D library was replaced by a purpose-built 4.6 KB canvas effect. The animation library was removed entirely and its work rewritten in about thirty lines of native browser code. The carousel library, the lazy-loading library and both web fonts went the same way — the fonts alone were 44 KB and two requests on the first screen of every page, and one of the two had no font-face rule anywhere in the codebase, meaning the site had been preloading files it never used.

The stylesheet got the same treatment, with proof attached: 1,120 !important declarations removed from a single file and verified as zero declaration differences across 1,258 rules, and 3,080 unit-conversion calls replaced with plain values across 76 files, verified as byte-identical compiled output. Refactors that cannot be proven harmless do not get shipped to a site with no staging environment.

Codebase and infrastructure

Plugins went from 23 to 7. Worth being precise about this, because it is usually oversold: an audit run before the cleanup established that none of the 23 was loading front-end assets, so this was not a speed win. It was a security, maintenance and licence-cost win — a paid performance plugin cancelled, sixteen pieces of attack surface removed, and the discovery that the paid plugin had never written a single cache file on that server, because caching had been happening at the CDN edge the entire time.

Removed alongside it: the entire legacy service-page template system, which an audit showed was used by exactly zero of 62 service pages; 558 lines of dead theme code; a 91-post legacy content type, deleted with all 91 URLs covered by redirects; and 1,784 accumulated post revisions, with a cap introduced so they cannot come back.

What replaced them was built in-house and shipped with a kill switch — a URL parameter that disables the feature live, without a deploy, if it misbehaves in front of a real visitor. That list includes the deployment pipeline itself, built from scratch on 6 June and deliberately set to manual trigger so nothing reaches production by accident; a booking calendar with timezone handling and calendar invites, written instead of installing a booking plugin; and a video player written to replace a third-party embed.

Analytics and CRM

The tracking rebuild produced three semantically distinct conversions — enquiry form, call booking, catalogue download — emitted by a single dynamic tag driven by attributes on the form itself. Adding a new form or lead magnet now requires no change to the tag manager and no change to the CRM. The old umbrella event went to zero hits from 20 June.

The CRM was migrated from amoCRM to HubSpot between 8 and 23 June and the old system fully retired on 15 July. Custom forms were kept and wired to the CRM server-side rather than embedding the vendor's own forms, a decision that avoided 100–300 KB of JavaScript on every page. Tag manager moved to a first-party domain on 13 July, which recovered roughly 15% of desktop hits that ad blockers had been eating.

Email deliverability was repaired at the same time. The domain's SPF record had been broken by a single stray character — a trailing dot that made the whole mechanism invalid at strict receivers — and DMARC had no reporting address, so nobody had any visibility into who was sending mail as the company. The standing advice had been to tighten the DMARC policy first, which with a broken SPF record would have started sending legitimate company mail to junk.

Two more languages

A Spanish site of roughly 80 pages went live on 12 June. The German site was planned, built and deployed in about three days, 21–23 June — and built on German keyword research rather than a translation of the English site. That distinction changed the sitemap: the commercial-rendering page was dropped because every German phrase for it returned zero volume, while two property-visualisation terms that have no direct English equivalent got pages of their own.

Under the hood, 409 interface strings across 68 files were made trilingual in a single commit, with the English and Spanish output verified byte-identical afterwards — a multilingual refactor with zero regression on the two languages that were already live. In July the Spanish pages collected 46,348 impressions and the German pages 7,884, with a Spanish explainer page sitting at average position 9.2 on 32,837 impressions.

4. Six things that were quietly broken

Aggregate numbers are easy to publish and hard to verify. These are harder to publish and easier to verify, and for anyone technical they say more about how the work was done.

1. Every page on the site had a live duplicate. Database collation is case-insensitive, so an uppercase variant of any URL returned a healthy 200 while the canonical was lowercase. The CMS's own canonical-redirect routine only rebuilds a URL when a query returns nothing — for a page that loads successfully it never compares case at all. No setting exists for this in the platform, the SEO plugin or the multilingual plugin. Closed on 30 July with a custom hook, validated against a 31-case test harness, with the redirect proven to happen in exactly one hop.
2. The CRM was returning "200 OK" and throwing leads away. For three weeks every submission was accepted and routed to a spam queue as an unregistered domain, because the site was missing from one settings list. The code was correct the whole time. One checkbox took the spam queue from 65 to 0 and restored lead attribution.
3. Form submissions took 7.2 seconds because of a function that does not exist on that host. The "send this to the CRM in the background" guard silently evaluated false — the server runs LiteSpeed, not PHP-FPM, and the function it checked for is a PHP-FPM feature. So the visitor sat through the entire background dispatch, including a six-second wait. Adding the LiteSpeed equivalent: 7,228 ms → 176 ms.
4. A version query string was loading the JavaScript bundle twice. Module identity in the browser is the exact URL, and the CMS was appending a version parameter to the entry file while the code-splitting runtime referenced the clean one. Every top-level binding on the site was duplicated. The symptom that exposed it: one click on "load more" fired two requests and appended twelve cards instead of six.
5. The animation library was not the performance problem. The optimisation started from a browser warning that pointed straight at it. Measurement showed it accounted for about 5% of layout reads; the real culprit was an animation loop in the sticky call-to-action measuring element geometry on every single frame. Rewritten, per-frame layout reads went to zero — and a second, unrelated 47 ms read found in the header init took a further 0.4 s off largest-contentful-paint on its own.
6. Google Ads was crawling a broken URL from inside the ad account. Server logs showed 404s on a service page with a malformed tracking parameter, coming from Google's own conversion crawler — meaning a final URL in the ad account had lost a question mark. Three days had already gone into a custom logging trap that could never have caught it. The answer was one query against the host's access logs.

There is a seventh worth including because it is the least flattering. The project's own documentation instructed everyone to "test locally first". There was no local environment and no staging server — production was the only environment that had ever existed. That instruction was replaced with gates that actually exist: a build check, a syntax check, a merge-conflict check, a diff review, and an immediate anonymous verification of the live URL after every deploy.

5. How a team this size covers this much ground

The honest answer to "who did all this" is: one operator, working with modern tooling, on a live site.

We are careful about how we frame that, because the usual version of this claim is an argument about price, and it is the wrong argument. Efficiency here does not buy a discount. It buys depth — the second and third pass that normally gets cut, the audit that gets run across all 4,055 URLs instead of a sample of forty, the refactor that ships with proof attached instead of a hope.

The project's own retrospective for the first twelve days put the volume at roughly 100–130 person-days of conventional work compressed into nine calendar days, with a line-by-line breakdown behind it: sixteen service pages of copy in about two days against five to six weeks; FAQ markup across 95 pages in a day against two to three weeks; four schema audits in a day and a half against three to four weeks. The line from that retrospective we find most telling is not about speed at all: 60–70% of this volume would never have been done at all. Not done slower — not done.

The mechanism that makes it safe is boring and it matters more than the speed. Mass edits run through self-verifying pipelines rather than by hand. Every internal-link insertion carried its own guards — the phrase must appear exactly once, the link count must go from zero to one, the content length must change by the expected amount, no truncation marker may appear. Two of the stylesheet refactors were verified as byte-identical compiled output before they were allowed near production. That is what makes it responsible to do a month of work in a week on a site with no staging environment — and it is how we work on build and rebuild engagements generally, not just on our own property.

Maverick Frame is at maverickframe.com if you want to check the site this was done to.

6. Where the numbers stand today

July 2026, all live figures. The site's strongest page is an architectural-styles explainer at 843 clicks and 60,201 impressions, average position 6.5. Second is an AI-rendering-tools listicle at 605 clicks, average position 5.3. Both were existing pages that had been sitting on page two.

In GA4, organic sessions went from 2,081 in March to 6,751 in July, a factor of 3.2, and organic users from 1,145 to 5,365. On the lead side the honest statement is this: July produced 38 enquiry-form leads and 21 call bookings, against a tracking system that in May was recording zero of either. A further 28 catalogue downloads were logged, which we count separately because a download is not a lead.

One line in the July data is worth its own paragraph. A traffic channel appeared that did not exist in the March figures at all: AI assistants, 234 sessions and 3 conversions. Separately, Google's own translated-results feature delivered 15,262 impressions and 138 clicks from markets the site has never been localised for. Both are small. Both are new, and both are the direct result of the site being fast, cleanly structured and readable by something that is not a person.

7. What is still not solved

A case study that ends at the good news is a brochure. Three things are still open, and they are the current priorities.

• The United States. 250,772 impressions in July, 571 clicks, a 0.23% click-through at average position 14.6. That is the commercial market, it is still mostly on page two, and it is the single largest unrealised asset on the site.
• The link ceiling. Authority Score 23 against first-page competitors at 35–45. On-page work has now taken the site about as far as on-page work takes anything. The next constraint is authority, which is a slower and less comfortable problem.
• Mobile. The 100-across-the-board Lighthouse result is a desktop run. Mobile was measured at 88–96 in July and has not been re-measured since the last round of optimisation. We are not publishing a mobile number we have not re-run.

Frequently asked