This is a record of method and engagement, not a results case study. No ranking, traffic, lead, or AI-citation outcome is claimed here, because the post-launch measurement window has not closed.
Who the client was
An established branding and design agency serving startups, SMEs and growing businesses. The business has a substantial portfolio and a public review history. It is not named here at the client’s preference, and details that would identify it have been left out.
The engagement ran for roughly four weeks. GetBorvis was engaged for SEO and GEO research, technical auditing, content direction, implementation specifications, and verification. The client’s own design and development team built the site and implemented the changes.
They brought in search input before launching, not after. That is the less common choice and the more expensive-feeling one, and it is the reason most of what follows was still cheap to change. The build itself was strong. The design work was accomplished, mobile performance was already good, and the templates were consistent. What it needed was the layer that makes a good site findable.
The launch problem
The agency was preparing a new WordPress site while an older live site already carried a substantial URL history. That combination creates two connected risks, and neither is solved by adding keywords.
Improving the new site without letting unfinished, duplicate, or low-value pages become indexable in the process.
Moving off an established URL footprint without discarding useful search history or redirecting unrelated pages carelessly.
The new site had to become the canonical search version of the business. Its content, its old URLs, its crawl controls, its business identity, its structured data, and its buyer journeys all had to be reconciled before search engines and AI systems could receive one clean, consistent version of the company.
What the audit found
The visual build was progressing well. The search layer was not yet ready.
That is the normal state of a site still in staging. Metadata, structured data, and indexation rules are usually the last layer added to a build, and often the layer nobody has been made specifically responsible for. The reason to audit at this point is precisely that none of it has hardened yet. Every finding below was cheap to fix in staging and would have been expensive to fix after launch.
What mattered was that these could not be treated as separate tasks. Metadata, structured data, page hierarchy, indexation rules, contact routing, and migration decisions all needed to be planned as one connected system before launch. Treated separately, each would have been a small fix. Treated together, they were the difference between a launch that preserved the business’s search history and one that quietly discarded it.
Two findings shaped the approach more than the rest.
The findings lived in templates, not pages
Heading gaps, repeated heading patterns, and a contact link resolving to the wrong destination were not independent faults spread across dozens of URLs. They came from a small number of shared page-builder components, which is what a consistently templated build looks like, and made the work far smaller than a page count would suggest. Grouping the findings by template turned a long list of symptoms into a much shorter set of implementation instructions, and meant a component could be fixed once rather than pages edited one at a time.
One finding was deliberately not inflated
The crawl recorded a large number of empty image alt attributes. Reported raw, that number would have looked alarming. But repeated decorative assets accounted for much of it, and a decorative image with an empty alt attribute is correct, not broken.
The issue was classified by template and image purpose instead of counting every empty value as an independent accessibility error. An inflated number would have made the audit look more impressive and sent the development team to fix things that were not wrong.
Search and AI research
Three kinds of competitor, not one
Ranking for a query does not make a site a competitor in the same sense. The market was separated into three groups, because each requires a different response:
- Commercial competitors. Agencies with comparable offers and pricing. These set the buyer’s expectations on scope and cost.
- Organic-search performers. Agencies whose pages ranked strongly for the tested service queries, whether or not they competed commercially. These show what a satisfying answer looks like to a search engine.
- Placement platforms. Directories, listicles, and marketplaces. The realistic goal is to earn inclusion on them, not to outrank them.
Collapsing these into one list is a common mistake. It leads to agencies trying to outrank a directory that will always outrank them, while ignoring the profile on that directory they could simply be listed in.
An AI answer baseline, recorded before any work
A manual baseline was recorded across four AI engine families (ChatGPT, Gemini, Google AI Mode, and Claude) using buyer-style questions about branding, startup branding, packaging design, and combined branding and web services.
Across 34 recorded answer outputs, the agency did not appear in the recommendation set. This is the ordinary starting position for almost every business we test, including well-established ones with strong portfolios and real reviews. AI systems recommend what they can retrieve and corroborate, and most businesses have never had that layer built for them. The point of recording it was not to grade the business. It was to fix a dated, repeatable reference point before anything changed.
This is a baseline, not a finding about how any engine’s ranking system works. AI answers vary by engine, date, location, account context, and individual run. The value of the record is that it was fixed, dated, and repeatable, so a later run can be compared against it.
The businesses that did appear shared a recognisable pattern: clear service-category association, relevant portfolio evidence, pages that answered the buyer’s question directly, third-party profiles and reviews corroborating their claims, and consistent business information across the web. None of that is a trick. It is the same evidence a careful human buyer would look for.
Strategy and page architecture
The problem was not that the site needed more SEO pages. It needed fewer, clearer search destinations with stronger evidence and better relationships between them.
- One meaningful buyer intent should lead to one useful primary page.
- The homepage should own the main local agency intent, while service pages answer national, service-specific intent.
- Service pages should work as complete buyer answers, not short keyword landing pages.
- Pricing, deliverables, process, timeline, audience, proof, and objections belong close to the offer they relate to.
- Real portfolio work and attributed reviews should support service claims.
- Archives, transaction pages, and in-progress records should not compete for crawl attention.
- Entity facts should stay identical across visible content, structured data, the Google Business Profile, and third-party listings.
Each priority service page was directed to answer a fixed set of buyer questions: who the service is for, what problem it solves, what is included, what the client receives, how the process works, how long it takes, what it costs, what proof supports the claims, what objections come up, and what happens next.
The implementation plan
The engagement produced 24 research, content, and implementation documents for the client and their development team. They were written to be executed directly by the development team, without needing to be translated into technical steps first.
Technical SEO and GEO foundation audit, new-site technical audit, and staging QA against fresh uncached responses.
Competitor intelligence, organic content analysis, and five recorded GEO test documents across four engine families.
Keyword-to-page ownership map, page-level content direction, page titles, and meta descriptions.
URL and indexation matrix, canonical and redirect rules, sitemap and robots specification, schema guide, and a proposed llms.txt.
Structured data
The plan covered a connected graph rather than isolated snippets: Organization, LocalBusiness, WebSite and WebPage, AboutPage and ContactPage, Service, Offer and OfferCatalog, BreadcrumbList, FAQPage, Blog and BlogPosting, and CollectionPage.
The rules attached to it mattered as much as the types. No unsupported ratings. No fake testimonials. No hidden claims. Nothing asserted in structured data that was not visible on the page.
Indexation
Indexable destinations were limited to real public pages: services, pricing, portfolio, approved case studies, reviews, FAQ, contact, and useful articles. Back-office and low-value destinations (thank-you, payment, enquiry, login, internal search, author, category, tag, test, and placeholder pages) were assigned exclusion treatment.
What changed during the engagement
By the final staging review, fresh uncached responses showed substantial progress on the commercial pages. Page-specific titles and meta descriptions were present. The homepage and core service pages had clear headings. Service pages explained audience, deliverables, process, packages, and next steps. Pricing and retainer pages had real commercial structure. Real review content loaded on the reviews page. Breadcrumb, FAQ, and article schema appeared on the relevant templates.
GetBorvis supplied the research, strategy, implementation specifications, and QA. The client’s design and development team adapted the content and implemented the website changes.
That is a substantial amount of implementation for the time available, and it was done by the client’s team while they were also finishing the build. Specifications are easy to write and hard to execute; this one was executed.
The same review also listed work still open at that point: final production entity and service schema, production canonicals, sitemap membership, the llms.txt file, some navigation URLs, final entity consistency, and portfolio detail content. That is a handover list from a mid-flight checkpoint, not a list of failures. The last preserved verification was a staging review, not a final production sign-off. It is named here rather than omitted because claiming a finished implementation without a production check would be exactly the kind of overstatement this page is trying to avoid.
The honest outcome
There is a defensible before. There is not yet a like-for-like after. What can be said accurately today is what was built, specified, and verified:
- An open-ended brief became a page-by-page implementation plan.
- Commercial competitors, search competitors, and placement platforms were separated and treated differently.
- An honest, dated AI answer baseline was established across four engines.
- A staging sitemap that contained everything the build produced became a deliberate index, noindex, and redirect decision system.
- Keyword ownership was mapped to reduce page overlap and cannibalisation.
- A connected business, service, and offer schema architecture was specified.
- Strong existing visual and mobile performance was preserved as a requirement, rather than a redesign being recommended that the business did not need.
- The developer was left with a repeatable verification checklist for future work.
What is not being claimed
No higher rankings. No increased organic traffic. No additional leads or revenue. No improved conversion rate. No new AI recommendations or citations. No claim that every legacy URL migrated successfully, that production schema is fully deployed, or that every recommendation is live.
A baseline is not a result. A recommendation is not an implementation. Neither becomes the other by being written about confidently.
What gets measured next
The measurement plan was fixed before launch, so the comparison cannot be chosen retrospectively to look flattering. Once a full post-launch window closes, this page will be updated with:
- Priority pages indexed against pages submitted.
- Branded and non-branded impressions, and organic clicks to priority service pages, from Search Console.
- Average positions for the locked keyword set, from a dedicated rank tracker.
- Local visibility and Google Business Profile actions.
- Organic enquiries and qualified leads, from verified records rather than analytics events alone.
- Successful legacy redirects and the resulting 404 rate.
- Mention and citation rate for the same fixed AI prompt set, run against the recorded baseline.
Each surface has one source of truth, and those sources are not merged. Search Console, analytics, a rank tracker, and the AI prompt set define their numbers differently, and treating their totals as interchangeable is how misleading reports get made.
What will be disclosed alongside any result
A great deal changed during this period beyond the search work: a full website rebuild, new copy and navigation, an evolving URL architecture and portfolio, changed crawl controls at launch, standardised business information, and existing paid acquisition running throughout.
If organic visibility improves, the honest statement is that it changed following the combined website launch and search-foundation work. Because content, design, campaigns, and implementation all changed in the same period, the result will not be attributed to one intervention alone.
What GetBorvis did not do
Stated plainly, so the contribution is not overread:
- Did not design or develop the website, or implement changes in WordPress.
- Did not control the production launch or server cutover.
- Did not write every final page in the client’s brand voice.
- Did not create or approve the client’s portfolio work.
- Did not run backlink outreach, digital PR, or directory acquisition.
- Did not manage advertising or social campaigns.
- Did not operate the client’s Google Business Profile as an ongoing service.
- Did not guarantee rankings, traffic, leads, rich results, or AI citations.
- Has not yet completed a full post-launch measurement period.