Canonical strategy across a three-domain product family

Owning three domains does not create three times the authority. Without a boundary, it creates three places for the same idea to compete with itself.

The fix is not a clever canonical tag. It is deciding which domain owns which job.

For this product family, the boundary is:

• designedbyanthony.online owns apps, calculators, embeddable widgets, and technical build notes;
• designedbyanthony.com owns custom websites, Local Visibility, local service pages, studio pricing, and case studies;
• vertaflow.io owns CRM, pipelines, client operations, product documentation, and VertaFlow pricing.

That sentence is the most important SEO configuration in the system.

Unique pages should self-canonicalize

A canonical is for duplicate or very similar content. It is not a general-purpose way to tell Google that two brands are related.

Google’s canonicalization documentation describes canonical selection as choosing a representative URL from a group of duplicates. A useful app page on .online and a website-build service page on .com are not duplicates. Each should use its own self-referencing canonical.

The visible link between them should describe the relationship:

• “Need a custom website? See the studio’s website services.”
• “Need CRM and client operations? Explore VertaFlow.”
• “Need a field calculator? Use the app on .online.”

That helps a person move to the correct property and gives crawlers a plain-language relationship to follow.

Retired duplicates should redirect

This site used to behave like an umbrella. It carried studio pricing, service pages, local-market pages, and CRM descriptions. Those URLs overlapped the domains that should own them.

Leaving the pages live with cross-domain canonicals would keep two copies crawlable. Hiding them with robots.txt would prevent crawlers from reading the consolidation signal. Publishing noindex would remove them but would not create the cleanest transfer.

For a retired duplicate, the right response is normally a permanent redirect to the closest surviving owner. Google’s canonical URL guidance calls redirects a strong canonicalization signal and recommends them when deprecating a duplicate page.

So the old .online routes now hand off:

• /services/* → the .com services hub;
• /service-areas/* → the .com service-area hub;
• /pricing → .com pricing;
• /portfolio → the .com portfolio;
• the retired local-SEO post → the closest studio article.

The redirect is paired with removal from the .online sitemap. Signals work better when the server, HTML, sitemap, and internal links all tell the same story.

Sitemaps are ownership manifests

A sitemap should not be a dump of every route the build happens to produce.

For each domain, the sitemap should list only canonical URLs that property wants indexed. Transactional routes, retired sections, preview pages, and cross-domain handoffs do not belong there.

This matters even though sitemap inclusion is a weaker signal than a redirect or rel="canonical". Consistency is the point. A URL should not redirect to .com while .online continues advertising it as an indexable page.

Cross-links need a reason

Sitewide links can establish discovery, but repeating keyword-heavy links across every footer is not a substitute for useful architecture.

I use two layers:

1. a small family switcher that identifies all three properties; and
2. contextual links where the reader’s next task genuinely belongs elsewhere.

An Etsy fee calculator can link to the studio’s owned-store offer because the calculator helps make that decision. A build note about CRM boundaries can link to VertaFlow documentation. A .com case study can link to the .online technical tool used to produce the evidence.

The anchor text should state the destination’s purpose. “See custom website and Local Visibility services” is more useful than “click here,” both for people and for machines trying to understand the relationship.

Entity markup should not invent a corporation

The three properties share a builder and standards, but that does not justify inventing a corporate parent in structured data.

Each site publishes the entity that actually owns its content:

• the studio site describes the ANTHONY. professional-service business;
• the apps site describes the ANTHONY. Apps product division and its founder;
• VertaFlow describes the software product and its organization.

The apps-site WebSite entity can mention the related studio and product. The visible page explains the same relationship. That is more honest than forcing every property into sameAs, which is intended for equivalent identity references.

Measure by cluster, not just by domain

After the split, reporting should follow intent:

• app names, calculator queries, embed queries, and technical engineering topics for .online;
• web-design, Local Visibility, service, city, and case-study queries for .com;
• CRM category, feature, integration, comparison, and operational queries for VertaFlow.

If one domain begins earning impressions for another domain’s core cluster, that is a diagnostic signal. It usually means the content boundary or internal linking has drifted.

Clear ownership makes every future publishing decision easier: choose the searcher’s job, choose the domain that owns that job, self-canonicalize the unique page, and link to siblings only when the next action belongs there.

You can see the live boundary in the ANTHONY.online app catalog, the ANTHONY. studio services, and VertaFlow.