https://preview.redd.it/grmmngy30gjh1.png?width=1436&format=png&auto=webp&s=1edf09cb63e0e859ff44f61a6e0ead8b6c5c29df

I just finished migrating a local SEO platform from a custom React/tRPC/MySQL stack to a new managed stack.

The interesting part was not the frontend. It was preserving the SEO asset while changing everything underneath it.

The site has 17 city hubs, 16 service hubs, 272 city × service landing pages, 1,681 sub-service pages, 2,756 FAQs, and roughly 2,000 public URLs. The migration needed to feel like a hosting/backend swap, not a site relaunch.

Here’s the migration checklist that mattered.

https://preview.redd.it/cgslg6ykzfjh1.png?width=1028&format=png&auto=webp&s=99b56197cfec67a0152e7614b150b58dc672b335

1. Treat URLs and content as production data

We exported the existing database into a PostgreSQL-compatible package and preserved IDs, slugs, relationships, metadata, long-form copy, FAQ content, image URLs, and statuses.

The rule was simple: no regenerated slugs, no “cleaned up” copy, no new URL hierarchy, and no surprise image substitutions.

We also generated a URL contract file from the active database rows. That gave us a list of every city, service, territory, and sub-territory URL expected after migration.

2. Separate public content from operational noise

The public import contained the tables needed to render pages: cities, services, sub-services, operators, territories, sub-territories, and FAQs.

We did not import legacy lead or quote-request records because they were test submissions, not real CRM history. That kept the new admin clean from day one.

3. Do not accept client-side SEO injection as parity

This was the biggest catch.

The first migrated version looked correct in the browser, but raw HTML on deep pages did not contain page-specific title tags, meta descriptions, canonicals, or JSON-LD until JavaScript ran.

That is not good enough for a site where SEO is the product.

We moved the SEO rules into native server-rendered route loaders/head functions. Then we verified with raw curl, not DevTools after hydration.

The verification target was:

Page Type	Raw HTML Must Include
City hub	Title, description, canonical, Open Graph/Twitter tags, breadcrumbs
Service hub	Title, description, canonical, service image/social tags
Territory page	LocalBusiness/ProfessionalService, FAQPage, BreadcrumbList, canonical
Sub-territory page	Same schema set, self-referencing canonical, specific meta

4. Build a minimal admin before switching production

The public site was migrated, but publishing without an admin would have created two systems of record.

So we built the MVP admin first:

•Cities

•Services and sub-services

•Territories

•Operators

•FAQs

•Leads and quote requests for new submissions only

The public site and admin now read the same PostgreSQL data. One edit in the admin updates the live public page. No sync layer.

5. Make authorization boring and strict

We used normal application auth, role-based access, row-level security, and server-side admin checks. No public signup. No self-promotion to admin. No elevated privilege functions exposed to public routes.

The useful test was not “does the admin screen load?” It was:

1. Can an anonymous request read private data? No.
2. Can a signed-in non-admin update a city? No.
3. Can a non-admin create an admin role? No.
4. Can a real admin edit a territory and see the exact change render publicly? Yes.

6. Publish before DNS, then cut over deliberately

We did not touch DNS until the new deployment was published and verified on its preview hostname.

Final pre-cutover checks:

•Raw HTML SEO on all page families

•XML sitemap returns XML, not the SPA shell

•Full URL count matches the contract

•Existing trailing-slash behavior is permanent

•www redirects to the apex domain

•Admin works on the new host

•One test lead and one test quote reach the new admin

The goal is not “a new website.” The goal is a new system that the public—and Google—cannot tell was replaced.

https://preview.redd.it/74e2n8zszfjh1.png?width=1049&format=png&auto=webp&s=2358b44769bf00cca8a6f18900a9a595d6945e37

What I would do differently next time

I would create the URL parity manifest and raw-HTML SEO test suite on day one.

Most migrations fail quietly because the pages look right in a browser. The real breakage lives in canonicals, metadata, schema, redirect status codes, pagination limits, and data that got “normalized” during import.

If anyone has migrated a programmatic/local SEO site across stacks, what did you validate that I missed?

I wanted to make a game that is almost unnecessary in the best way: you mostly watch a small society become itself.

The figures gather food, build districts, form relationships, argue, migrate, recover from disasters, and can eventually collapse as a society. You can intervene as a director—cause a flood, tornado, fire, or thunder strike—but the people decide who runs, who helps, who blames whom, and what gets rebuilt.

I’m still tuning the simulation, especially long-term behavior and the stories that emerge. I’d genuinely like feedback on one question: what would make you keep watching a tiny society like this for another five minutes?

Playable link: https://autonomoussociety.manus.space/

https://preview.redd.it/o8f4t3kxkejh1.png?width=1440&format=png&auto=webp&s=629d2e6409d48ab319da670deb74d5ff4bd5e7c7

I keep seeing the same mistake with small businesses, and honestly enterprise companies make it too.

Someone hires a designer or developer and the conversation immediately becomes:

“Can we make this animation cooler?”

“I like this font better.”

“Can the cards move when I hover over them?”

“This section feels more premium.”

And none of those things are automatically bad.

A website should look good.

But here’s where businesses fuck up:

they start optimizing the website for what they personally like instead of what the customer and the systems responsible for finding that customer actually need.

Your customer does not care that you spent three weeks perfecting a hover animation.

Google does not care that your homepage feels “luxury.”

ChatGPT, Gemini, Perplexity, and other retrieval systems are not sitting there admiring your color palette.

They need to understand things like:

Who are you?

What do you sell?

Who do you serve?

Where do you serve them?

What makes one service different from another?

What evidence supports the claims you’re making?

How are your pages related?

What business entity does this website represent?

What should happen when someone searches for a specific problem you solve?

And your customer needs to understand all of that too — usually within seconds.

That’s where machine-readable structure and actual information architecture matter.

Clear pages.

Clear services.

Clear headings.

Intentional URLs.

Internal relationships.

Accurate business information.

Useful copy.

Structured data that reflects what’s actually on the page.

Fast pages.

Accessible pages.

Clear conversion paths.

Tracking that tells you whether any of this is producing business.

Meanwhile, companies will spend thousands making a site visually impressive while nobody has figured out whether search engines can properly understand the business, whether the correct pages can rank, or whether a visitor actually knows what to do next.

Then six months later:

“No one can find us.”

“We’re getting traffic but no leads.”

“Google isn’t ranking the new site.”

“AI never recommends our company.”

“We paid a fortune for this redesign.”

That expensive redesign might have been beautiful.

That doesn’t mean it was useful.

And the opposite is also true:

Ugly websites are not automatically good websites because they have SEO.

This isn’t design vs. SEO.

It’s understanding that design is one layer of a business system.

A good website should be visually credible, technically understandable, discoverable, useful, measurable, and capable of converting the right person.

Small businesses especially cannot afford to treat a website like digital wall art.

If I’m spending $5,000, $10,000, or $30,000 on a business website, I care a hell of a lot more about:

Can people find it?
Can machines understand it?
Can customers trust it?
Can we measure it?
Does it make the phone ring, generate a form submission, book an appointment, or create a sale?

The hover effect comes after that.

A website can be memorable to the owner and completely invisible to the market.

That’s the part I think businesses need to start paying much more attention to.

I keep seeing people trying to define exactly where SEO ends, where AEO begins and where GEO fits.

I understand why.

We need terminology.

But I think there’s a point where the terminology starts slowing down the experimentation.

For years, search was relatively easy to describe:

query → ranking → click → website → conversion

AI breaks that path apart.

Someone can now:

discover a company in ChatGPT
validate it on Reddit
watch the founder on YouTube
compare it in Gemini
Google the brand
come back three days later directly
and convert without ever following the journey we traditionally measured

Was that SEO?

AEO?

GEO?

Social?

Content marketing?

Demand generation?

Demand capture?

Probably some combination.

And that’s why I think the market is moving faster than our labels.

I’m not saying terminology is useless.

I’m saying don’t get married to it.

Right now I’d rather:

build something
publish it
measure it
watch what changes
fail
adjust
run the next experiment

than spend six months arguing about which department should own it.

This is especially important because smaller teams have an advantage right now.

They can test:

Reddit
YouTube
entity reinforcement
comparison pages
third-party mentions
structured content
AI prompts
new search surfaces

without waiting for five meetings and a strategy deck.

That speed matters.

I still think SEO is the foundation.

But AEO and GEO are increasingly retrieval layers on top of the same problem:

How does a machine understand, trust, retrieve and choose an entity when somebody needs an answer?

Traditional Google results are one interface.

ChatGPT is another.

Gemini is another.

Perplexity is another.

AI Overviews are another.

Reddit and YouTube can influence several of them.

The interface changes.

The underlying need for clarity, authority, relevance and corroboration doesn’t.

So my working philosophy right now is:

Build fast.
Measure.
Fail intelligently.
Improve.
Repeat.

Not reckless publishing.

Not AI spam.

Just shorten the distance between hypothesis and evidence.

The labels can catch up later.

https://preview.redd.it/t0i2jkmpktih1.png?width=1440&format=png&auto=webp&s=bd18e6e7fedd72f08e8e5abe1a340deb2d032dbf

I got the same Manus notice today as everyone else.

I actually like Manus a lot and don’t want to stop using it.

But I also never wanted Manus — or any AI builder — to become the only place where one of my production sites could actually live.

So alongside the official backup, I’m doing something I’ve already been doing with all of my vibe-coded projects:

building a clean, portable GitHub repository that another developer, AI platform, or future owner could actually understand and deploy.

There’s a big difference between:

“My project syncs to GitHub.”

and

“My GitHub repo is the documented source of truth for the project.”

A repo can technically exist in GitHub and still be a mess.

It might not explain:

• what the project actually does
• how the architecture is structured
• what depends on what
• which environment variables matter
• where the database lives
• what third-party services are connected
• what breaks if you change hosts
• how DNS is configured
• how to rebuild or deploy it elsewhere
• what SEO structure needs to stay intact

That is not real portability.

That is just code sitting somewhere else.

Years ago, getting a proper production repo, technical handoff package, architecture documentation, deployment notes, environment setup, dependency mapping and migration plan built correctly could easily become a serious five-figure development project.

AI makes that dramatically easier now.

But only if you know what standard to ask it to build toward.

This is the prompt I use.

One note before the prompt:

I intentionally use the phrase “potential acquisition.”

I’m not necessarily selling the project.

That wording is there because it changes how the AI approaches the task.

“Make me a README” gets you one level of documentation.

“Prepare this project for potential acquisition, migration and independent operation” tends to make the AI think much more seriously about:

due diligence, transferability, undocumented dependencies, ownership handoff, credentials, external accounts, technical debt, deployment continuity, operational risk and future maintainability.

That is the standard I want (modify if you already have a GitHub repository).

Here’s the prompt:

"It doesn’t appear that this project currently has a dedicated GitHub repository.
Please help me create a high-quality, expert-level PRD and a well-structured, portable GitHub repository that fully documents the project.
The goal is to make the project easy for another developer, technical team, or future owner to understand, maintain, migrate, and continue building without relying on undocumented knowledge.
The documentation and repository should clearly capture:
What has been built and the purpose of each major component
The current architecture, technology stack, dependencies, and integrations
Repository structure and how the codebase is organized
Environment variables, configuration requirements, and external services
Build, deployment, hosting, and DNS requirements
Data flows, APIs, databases, authentication, and third-party connections where applicable
Known limitations, technical debt, assumptions, and areas that may need future improvement
Recommended conventions for maintaining and scaling the project
Clear setup and handoff instructions for another developer or owner
This project is being prepared for potential acquisition, so portability and migration readiness are especially important.
Please thoroughly identify and document anything that could affect transferring the project to a new owner or environment, including hosting dependencies, domain and DNS configuration, deployment settings, credentials or secrets that must be recreated, external accounts, integrations, databases, storage, analytics, automation, APIs, and any platform-specific dependencies.
The final result should function as both a professional technical handoff package and a reliable blueprint for rebuilding, migrating, maintaining, or scaling the project independently."

Then I would have Manus build or clean the repo based on the current working project, not just assume an old GitHub sync captured everything correctly.

If you already have a GitHub sync, great.

But I’d still ask:

Could another AI system or developer open this repo tomorrow and actually understand how to run the project without guessing?

If not, I’d improve it now.

And obviously:

still run the official Manus backup.

This is not a replacement for that.

The difference is:

Backup = preserve what Manus gives you.

Portable repo = preserve your ability to leave Manus if you ever need to.

That distinction matters.

I’ve already been moving some of my own sites into another environment because I wanted a failsafe before this situation ever happened.

I’m currently using Lovable for that, but the specific destination is not really the point.

The point is that if your repo is clean and portable, another platform can understand what it is supposed to build.

That is what I mean by vibe architecture.

Vibe coding is:

>Build me a seo website.

Vibe architecture is:

>Here is the business model, entity structure, URL architecture, content model, integrations, SEO requirements, technical constraints, and portability requirements. Build the system around that.

That difference is why migration becomes much easier.

And for anyone who cares about SEO, there’s one more layer:

Google generally doesn’t care which hosting/build platform publishes the site; it cares about what remains crawlable, indexable, and consistent after the migration.

So if you move environments, the goal should not be:

“rebuild something that looks similar.”

The goal should be:

preserve the existing search architecture as close to 1:1 as possible.

Same URLs where appropriate.
Same content intent.
Same canonicals.
Same schema.
Same metadata.
Same redirects.
Same internal relationships.
Same important business facts.

A GitHub sync is not the same as a portable GitHub repository.

A backup protects your files.

A portable architecture protects your ability to operate.

Hope this helps at least a few people who woke up panicking today.

PS: Take advantage of Manus 1.6 been free credit wise.

AI site builders have made it ridiculously easy to create websites.

That’s great.

But I think a lot of people are learning the hard way that:

having your AI builder connected to GitHub is not the same as having a portable website.

A repo can technically exist in GitHub and still be a mess:

• unclear dependencies
• undocumented environment variables
• platform-specific assumptions
• assets scattered everywhere
• routes that only work inside the original builder
• database logic nobody understands
• SEO metadata generated inconsistently
• schema disconnected from the actual content
• no clear deployment instructions
• no clean separation between content, code, hosting and data

That isn’t portability.

That’s just a backup of whatever the builder happened to generate.

The question I care about is much simpler:

If the platform disappeared tomorrow, could another developer or AI system take the repo, understand it, deploy it somewhere else, and preserve how the site actually works?

If the answer is no, the site is still dependent on the platform.

This is where I think the difference between vibe coding and vibe architecture becomes important.

Vibe coding is:

>

Vibe architecture is:

>

AI can execute that incredibly fast now.

But someone still has to understand what the architecture should be.

And this matters for SEO too.

Google generally doesn’t care which hosting or build platform publishes the site. It cares about what remains crawlable, indexable and consistent after the migration.

If you move from one platform to another and preserve:

• URL paths
• content intent
• canonical URLs
• structured data
• internal linking
• metadata
• redirects
• crawlability
• important business facts

then changing the underlying platform does not inherently require changing the search architecture.

The goal should be as close to a 1:1 migration as possible when those URLs already have value.

That’s why I’ve started thinking about GitHub differently.

It shouldn’t just be:

“Where my AI builder syncs the code.”

It should be:

“The portable source of truth another system can actually understand.”

If you’re building production sites with AI, one of the best tests you can run is:

>

If not, I’d fix that before adding another feature.

A backup protects your files.

A portable architecture protects the business.

That’s probably the version I’d post.

For your more AI-first audience, I’d even use a slightly sharper title:

Vibe Coding Builds the Site. Vibe Architecture Makes It Portable.

I think people are mixing up two very different things right now:

cheap production
and
cheap expertise

They are not the same.

I’ve been working in search for 15+ years, building websites for a long time, and working deeply with AI for the last several years.

At this point, with the workflows I’ve built, I can sometimes take a business from nothing to a functional website in 5–10 minutes.

And I don’t mean a generic AI template.

I mean a site with things like:

• clean architecture
• proper service targeting
• entity relationships
• metadata
• schema
• internal linking
• forms
• analytics foundations
• image naming
• existing asset reuse
• crawlable business facts
• external entity references
• a structure that can actually scale

If there’s an existing site, I can usually pull down the assets, rename and organize them, preserve what has value, and rebuild the architecture without starting from zero.

That speed is real.

But the mistake is assuming:

>

That’s not how expertise works.

AI compressed the execution time.

It did not compress the 15 years it took to learn:

• what pages should exist
• what pages should not exist
• how entities should relate
• what search intent belongs where
• how users should move through the site
• what technical mistakes will cause problems later
• what needs to be measurable
• and what “good” actually looks like

This is where I think the conversation around vibe coding is missing something.

Vibe coding is:

>

What I’m more interested in is vibe architecture.

That’s when you already understand the system:

the entity model, page hierarchy, service relationships, conversion paths, search intent, measurement, and business constraints

…and then you use AI to execute that system quickly.

That is a completely different skill.

The Picasso analogy gets used a lot, but it fits.

If someone can create something valuable in five minutes because they spent decades learning how to do it, the value didn’t disappear because the production time got shorter.

The same thing is happening with websites.

A good operator can now compress work that used to require:

a developer
a designer
a copywriter
a technical search specialist
an analytics person

into a much faster workflow.

That should make good websites more accessible.

But it doesn’t mean the expertise behind them became worthless.

The real question for a business owner is no longer:

“Who can build me the cheapest site?”

It’s:

“Who already knows what this site needs to do, and can use AI to get there efficiently?”

That’s where the value is moving.

Not into typing code.

Into judgment.

A lot of AI tools promise better outputs by giving you a better prompt template.

Objective.
Audience.
Constraints.
Success criteria.
Context.

That can help.

But there’s a problem:

People still have to know what to put in the blanks.

If someone doesn’t actually understand:

• what they’re trying to accomplish
• what the real constraint is
• what success looks like
• what information matters
• what the AI should not assume

then a perfect prompt template just gives them a cleaner way to describe an unclear idea.

This is why I keep coming back to using AI conversationally first.

Brain dump.

Talk through the problem.

Let the model ask what’s missing.

Clarify the objective.

Challenge assumptions.

Then turn that into a structured prompt or operating instruction.

For me, the workflow is:

messy human thought
→ structured intent
→ explicit constraints
→ machine-operable instructions
→ execution

Not:

find magic prompt
→ paste business problem into brackets
→ hope

I think this is also why expertise becomes more valuable as AI gets better.

The model can increasingly handle the execution.

The harder part is knowing what should be executed in the first place.

The most valuable AI skill may not be prompt engineering.

It may be problem articulation.

I saw someone ask how to give ChatGPT access to their computer so it could organize files, read emails, work with screenshots, move documents around, and generally take more work off their plate.

Most of the answers immediately jumped to:

>

And I think that skips the most important step.

**Before an AI gets more permissions, the human needs to get clearer about the job.**

This is something I’ve learned from using AI heavily over the last several years.

Most of us don't naturally think in clean operating instructions.

We brain dump.

We say things like:

>

A human who knows you can usually fill in the gaps.

An autonomous system might fill them in too.

The problem is that you might not like what it decides.

So I’ve started thinking of ChatGPT as having two different jobs.

# Job 1: Conversational layer

This is where I can be messy.

Voice note.

Brain dump.

Explain the problem badly.

List every constraint I can remember.

Change my mind halfway through.

Basically communicate like a human.

Then I have AI turn that into something structured.

# Job 2: Execution layer

Only after the intent is clear do I create the actual instructions for the agent.

Something more like:

Objective:
Organize project assets.

Allowed:
- Read files in /Projects
- Rename image files
- Create folders
- Move files inside /Projects

Not allowed:
- Delete anything
- Modify files outside /Projects
- Touch the external drive
- Overwrite an existing file

Escalate:
- Duplicate filenames
- Unclear project ownership
- Anything requiring deletion

Now the agent isn't being asked to figure out both:

**what I meant**

and

**how to execute it**

at the same time.

That's a big distinction.

I think this same pattern applies far beyond desktop agents.

AI coding.

Content generation.

SEO automation.

Analytics.

CRM workflows.

Website changes.

The quality of agentic AI isn't just determined by how capable the model is.

It is also determined by the **architecture of the instructions surrounding it**.

My preferred flow now is:

**brain dump → organize intent → define rules → define permissions → define exceptions → execute**

Not:

**brain dump → give AI root access → hope**

And I think that's going to become increasingly important as AI moves from answering questions to actually taking actions.

The most valuable AI skill may not be prompt writing.

It may be learning how to turn **human ambiguity into machine-operable instructions.**

I saw someone ask how to give ChatGPT access to their computer so it could organize files, read emails, work with screenshots, move documents around, and generally take more work off their plate.

Most of the answers immediately jumped to:

>

And I think that skips the most important step.

Before an AI gets more permissions, the human needs to get clearer about the job.

This is something I’ve learned from using AI heavily over the last several years.

Most of us don't naturally think in clean operating instructions.

We brain dump.

We say things like:

>

A human who knows you can usually fill in the gaps.

An autonomous system might fill them in too.

The problem is that you might not like what it decides.

So I’ve started thinking of ChatGPT as having two different jobs.

Job 1: Conversational layer

This is where I can be messy.

Voice note.

Brain dump.

Explain the problem badly.

List every constraint I can remember.

Change my mind halfway through.

Basically communicate like a human.

Then I have AI turn that into something structured.

Job 2: Execution layer

Only after the intent is clear do I create the actual instructions for the agent.

Something more like:

Objective:
Organize project assets.

Allowed:
- Read files in /Projects
- Rename image files
- Create folders
- Move files inside /Projects

Not allowed:
- Delete anything
- Modify files outside /Projects
- Touch the external drive
- Overwrite an existing file

Escalate:
- Duplicate filenames
- Unclear project ownership
- Anything requiring deletion

Now the agent isn't being asked to figure out both:

what I meant

and

how to execute it

at the same time.

That's a big distinction.

I think this same pattern applies far beyond desktop agents.

AI coding.

Content generation.

SEO automation.

Analytics.

CRM workflows.

Website changes.

The quality of agentic AI isn't just determined by how capable the model is.

It is also determined by the architecture of the instructions surrounding it.

My preferred flow now is:

brain dump → organize intent → define rules → define permissions → define exceptions → execute

Not:

brain dump → give AI root access → hope

And I think that's going to become increasingly important as AI moves from answering questions to actually taking actions.

The most valuable AI skill may not be prompt writing.

It may be learning how to turn human ambiguity into machine-operable instructions.

I’m running an early local-search architecture pilot for a large multi-location healthcare organization.

I’m keeping the company anonymous, but the setup is straightforward.

The existing flagship site is established, has a large location footprint, mature brand visibility, and a long search history.

For the pilot, we built a separate local. search layer from the ground up around a much tighter relationship:

brand → service → location → local intent → conversion

That included the location architecture, technical foundation, structured data, entity relationships, internal linking, and call/form attribution.

Initial indexation started around July 20, so this is still early data.

And the goal was never simply to generate more impressions.

The question was:

>

So far, the answer appears to be yes — strongly enough that I think the pilot is worth continuing.

First: the full location-page comparison

Same organization. Same observation window.

Across the full location-page sets:

https://preview.redd.it/j3qzcw4e2dih1.png?width=891&format=png&auto=webp&s=aed2b57e5967ca04903e24292aa1df6c5455a850

The pilot generated:

• about 49% as many clicks
• from only about 15.5% as many impressions
• at roughly 3.2× the CTR
• while appearing about 9 positions higher on average

That is the first thing that caught my attention.

The pilot does not have more visibility.

It has substantially less.

But the visibility it does have is converting into organic visits much more efficiently.

Local Pilot

Flagship

Then I isolated “near me” queries

This is where the difference became even more interesting.

For explicit proximity queries containing “near me”:

Local pilot

• 487 impressions
• 5 clicks
• 1.03% CTR
• 5.80 average position

Flagship location set

• 6,073 impressions
• 9 clicks
• 0.148% CTR
• 11.01 average position

So the pilot produced:

• 55.6% as many clicks
• with roughly 92% fewer impressions
• at about 6.9× the CTR
• while ranking about 5.2 positions higher on average

Another way of looking at it:

For every 1,000 near-me impressions:

• the pilot generated about 10.3 clicks
• the flagship generated about 1.5 clicks

That is the part I care about.

Not because five clicks is a huge sample.

It isn’t.

But because this is exactly the class of intent the architecture was designed to serve.

Local Pilot

Flagship

The pattern is not isolated to one location

I also compared matched locations between the two environments.

At the moment, 8 of the 10 matched locations show a higher CTR on the pilot.

A few examples:

https://preview.redd.it/4eigi6db3dih1.png?width=877&format=png&auto=webp&s=75a4a3310ac766c33c58ebfd686c927bdadf8c56

It is not universal.

There are locations where the pilot is not currently outperforming on CTR.

That matters.

I’d rather have a pattern with exceptions I can investigate than pretend every page behaves the same way.

What I think may be happening

My working hypothesis is not “subdomains rank better.”

I don’t believe the data supports that.

The more interesting explanation is that the pilot gives Google a cleaner local environment in which the relationships are more explicit:

organization → service → location → geographic intent → conversion path

The flagship site has to serve a much broader set of purposes.

The local layer has one job.

That may be helping it align more tightly with queries like:

• autism therapy near me
• ABA therapy near me
• autism diagnosis near me
• autism centers near me
• autism evaluation near me
• applied behavior analysis near me

The pilot is already being surfaced across that class of service + proximity searches.

That does not prove lead quality.

But it does suggest the search engine is associating the new location layer with the intent it was specifically designed to address.

One hypothesis I’m still watching

Part of the original concept was to deploy the pilot inside an already established domain ecosystem rather than launch a completely disconnected property.

It is plausible that this reduced some of the friction associated with launching a new search environment.

But I cannot isolate that variable from the current data.

So I’m treating it as a hypothesis, not a conclusion.

I’m also not claiming that schema, internal linking, the subdomain, or any single implementation choice caused the performance.

The pilot changed several things at once.

This is architecture validation, not a controlled laboratory experiment.

There are also confounding variables

The flagship environment is older, broader, and has some legacy URL variation.

For example, there are instances where more than one flagship URL appears to represent the same geographic market.

That means this is not a perfect one-URL-vs-one-URL experiment.

Query mix also differs between the two environments.

And because indexation only began around July 20, the observation window is still short.

Those are reasons to keep measuring — not reasons to ignore the signal.

What the data supports today

Supported by evidence

• the pilot location set currently has a materially higher CTR
• the pilot currently has a materially better average position
• near-me queries are producing substantially stronger click efficiency
• most matched locations currently show higher pilot CTR
• the pilot is appearing for explicit service + proximity searches

Directionally promising

• stronger local intent alignment
• cleaner geographic/entity relationships
• better search efficiency for high-intent local queries

Not proven yet

• that the subdomain caused the performance
• that schema caused the performance
• that existing domain trust was inherited in a measurable way
• that higher CTR automatically means better leads
• that the pilot has produced more revenue or enrollments

That distinction matters.

The pilot is already producing downstream activity

The search data is only useful if it connects to actual business behavior.

For the same July 20–August 8 observation period, we also tracked conversion activity separately through CallRail and HubSpot.

CallRail recorded:

16 calls to pilot-specific tracking numbers.

https://preview.redd.it/nb73xdmh5dih1.png?width=2857&format=png&auto=webp&s=9b6b7d279ff29ae5bdaf5263825895d66fb1e408

HubSpot recorded:

8 form submissions during the same period.

https://preview.redd.it/iga8ir5c5dih1.png?width=2529&format=png&auto=webp&s=3b10b1973d67cab2aae1b9936ed91f42c80f1117

I’m deliberately not combining those into “24 leads.”

Some callers may also have submitted forms, some calls may not represent qualified opportunities, and CRM qualification still needs to be reconciled.

But this does move the pilot beyond search visibility alone.

We now have evidence across multiple funnel stages:

Search visibility → click → call/form submission → CRM contact

The remaining business question is:

>

That is the next validation layer.

The real test is downstream

Clicks are not the finish line.

We’re tracking:

Search visibility → session → intent action → call/form → qualified lead → intake/enrollment

No paid campaigns are being directed to the pilot property, which helps keep the organic measurement cleaner.

The next question is whether this stronger search efficiency translates into stronger qualified-lead efficiency.

If it does, then this becomes much more than an SEO experiment.

It becomes evidence that a purpose-built local search layer can create real incremental business value alongside an established flagship site.

I think people are mixing up two very different things right now:

cheap production
and
cheap expertise

They are not the same.

I’ve been working in search for 15+ years, building websites for a long time, and working deeply with AI for the last several years.

At this point, with the workflows I’ve built, I can sometimes take a business from nothing to a functional website in 5–10 minutes.

And I don’t mean a generic AI template.

I mean a site with things like:

• clean architecture
• proper service targeting
• entity relationships
• metadata
• schema
• internal linking
• forms
• analytics foundations
• image naming
• existing asset reuse
• crawlable business facts
• external entity references
• a structure that can actually scale

If there’s an existing site, I can usually pull down the assets, rename and organize them, preserve what has value, and rebuild the architecture without starting from zero.

That speed is real.

But the mistake is assuming:

>

That’s not how expertise works.

AI compressed the execution time.

It did not compress the 15 years it took to learn:

• what pages should exist
• what pages should not exist
• how entities should relate
• what search intent belongs where
• how users should move through the site
• what technical mistakes will cause problems later
• what needs to be measurable
• and what “good” actually looks like

This is where I think the conversation around vibe coding is missing something.

Vibe coding is:

>

What I’m more interested in is vibe architecture.

That’s when you already understand the system:

the entity model, page hierarchy, service relationships, conversion paths, search intent, measurement, and business constraints

…and then you use AI to execute that system quickly.

That is a completely different skill.

The Picasso analogy gets used a lot, but it fits.

If someone can create something valuable in five minutes because they spent decades learning how to do it, the value didn’t disappear because the production time got shorter.

The same thing is happening with websites.

A good operator can now compress work that used to require:

a developer
a designer
a copywriter
a technical search specialist
an analytics person

into a much faster workflow.

That should make good websites more accessible.

But it doesn’t mean the expertise behind them became worthless.

The real question for a business owner is no longer:

“Who can build me the cheapest site?”

It’s:

“Who already knows what this site needs to do, and can use AI to get there efficiently?”

That’s where the value is moving.

Not into typing code.

Into judgment.

I’m not really selling “a website.”

I build a managed web/search layer for small businesses that need to get online quickly without spending $3k–$10k on a traditional site build.

The setup is $499 one time + $149/month, no long-term contract.

The initial build includes:

• fast, responsive website deployment
• domain/DNS routing
• technical SEO foundation
• structured business/service data
• JSON-LD schema implementation
• search visibility baseline
• content publishing system
• ongoing technical maintenance

The monthly plan includes the managed infrastructure and up to 8 published content pieces per month.

You can use it as:

• your primary website
• a replacement for an outdated site
• a focused service/location site
• an additional search entry point alongside an existing corporate site

I’m intentionally keeping the base build productized rather than turning every project into a $5k custom development engagement.

That means design revisions, custom pages, integrations, major copy rewrites, or custom functionality are scoped separately.

If you already own a domain at GoDaddy, Bluehost, HostGator, etc., you normally keep it there. We configure the routing rather than forcing a domain migration.

The goal is simple:

get the business live quickly, make the business/services/location relationships clear, and maintain the technical/search layer after launch.

$499 setup
$149/month
Cancel anytime

Built and managed by MFGSEO LLC.

I think people are mixing up two very different things right now:

cheap production
and
cheap expertise

They are not the same.

I’ve been working in search for 15+ years, building websites for a long time, and working deeply with AI for the last several years.

At this point, with the workflows I’ve built, I can sometimes take a business from nothing to a functional website in 5–10 minutes.

And I don’t mean a generic AI template.

I mean a site with things like:

• clean architecture
• proper service targeting
• entity relationships
• metadata
• schema
• internal linking
• forms
• analytics foundations
• image naming
• existing asset reuse
• crawlable business facts
• external entity references
• a structure that can actually scale

If there’s an existing site, I can usually pull down the assets, rename and organize them, preserve what has value, and rebuild the architecture without starting from zero.

That speed is real.

But the mistake is assuming:

>

That’s not how expertise works.

AI compressed the execution time.

It did not compress the 15 years it took to learn:

• what pages should exist
• what pages should not exist
• how entities should relate
• what search intent belongs where
• how users should move through the site
• what technical mistakes will cause problems later
• what needs to be measurable
• and what “good” actually looks like

This is where I think the conversation around vibe coding is missing something.

Vibe coding is:

>

What I’m more interested in is vibe architecture.

That’s when you already understand the system:

the entity model, page hierarchy, service relationships, conversion paths, search intent, measurement, and business constraints

…and then you use AI to execute that system quickly.

That is a completely different skill.

The Picasso analogy gets used a lot, but it fits.

If someone can create something valuable in five minutes because they spent decades learning how to do it, the value didn’t disappear because the production time got shorter.

The same thing is happening with websites.

A good operator can now compress work that used to require:

a developer
a designer
a copywriter
a technical search specialist
an analytics person

into a much faster workflow.

That should make good websites more accessible.

But it doesn’t mean the expertise behind them became worthless.

The real question for a business owner is no longer:

“Who can build me the cheapest site?”

It’s:

“Who already knows what this site needs to do, and can use AI to get there efficiently?”

That’s where the value is moving.

Not into typing code.

Into judgment.