DEV Community: ahfu168

How I’m Building SEO for a Brand Nobody Searches For Yet

ahfu168 — Wed, 19 Aug 2026 08:23:44 +0000

A few days ago, I wrote about migrating an Android app from Song Flow to a new brand: MiraYola.

That post focused mostly on infrastructure:

keeping the Android package name stable
moving to a new domain
fixing redirects
setting canonical URLs
handling App Links
keeping old shared links alive
waiting for search engines and third-party systems to catch up

Once most of that was working, I ran into a different problem.

The migration could be technically correct, but almost nobody was searching for the new brand.

That changes the SEO problem completely.

If people already search for your company, SEO can focus on capturing existing demand.

But what if the brand is new enough that there is almost no branded demand to capture?

That is where I am with MiraYola right now.

And I definitely do not have a success story yet.

What I have instead is an experiment:

Can I gradually create a consistent search identity for a new product by making the website, app stores, developer profiles, social channels, and external content all reinforce the same brand and product category?

This post is about what I have tried so far, what is beginning to appear, what still is not working, and how my thinking about SEO has changed.

1. The first SEO problem was not ranking

My original instinct was fairly conventional.

MiraYola is an AI music product, so I started thinking about keywords such as:

AI Music Maker
AI Song Generator
Text to Song
Lyrics to Song
AI Remix Generator
AI Music Video Generator

Those are useful terms.

But there was a more basic problem.

Google first had to understand:

What is MiraYola?

Is it:

a website?
an Android app?
an iOS app?
an AI music generator?
a music discovery product?
a renamed version of Song Flow?
a random word appearing on a few unrelated pages?

For a completely new brand, I think this question comes before most traditional keyword work.

So instead of thinking only about pages and rankings, I started thinking about identity consistency.

2. The model became a matrix instead of a website

At first, I thought of SEO mainly as something happening on:

mirayola.huoji.app

Now I think about MiraYola more like this:

                    MiraYola
                       |
        --------------------------------
        |              |               |
     Website       App Stores       Content
        |              |               |
    Feature Pages   Google Play     Articles
    Live Rooms      App Store       Product Notes
    Music Plaza
        |
        --------------------------------
        |                              |
     Developer                      Social
     Identity                       Identity
        |                              |
     GitHub                        YouTube
     GitHub Pages                  Instagram
                                  X

None of these surfaces is individually very powerful.

The idea is that they should gradually tell the same story.

For example:

MiraYola
→ AI Music Maker
→ AI Song Generator
→ Create Music
→ Discover AI Music
→ Live AI Music Experiences

If Google encounters the same relationship across multiple independent surfaces, my hope is that the brand becomes easier to understand over time.

I am treating this as an entity-building experiment, not just a backlink campaign.

3. I started by making the product identity boringly consistent

This sounds simple, but it was surprisingly easy to get wrong.

After the rename, there were many possible descriptions:

MiraYola
MiraYola AI Music
MiraYola AI Music Maker
MiraYola Music Exploration Space
MiraYola AI Song Generator
Song Flow / MiraYola

Using all of them everywhere would create noise.

So I gradually moved toward one primary relationship:

Brand:
MiraYola

Primary category:
AI Music Maker

Supporting concepts:
AI Song Generator
AI Music Creation
AI Remix
AI Music Video
AI Music Discovery

That is why the store name is now close to:

MiraYola: AI Music Maker

The website uses the same relationship.

My developer site describes MiraYola similarly.

The social profiles are moving in the same direction.

This is not sophisticated SEO.

It is mostly consistency.

But for a new brand, I suspect consistency is more valuable than trying to invent a different optimized tagline for every platform.

4. The website now has two jobs

The MiraYola website originally felt more like a product experience.

It contains things such as:

Live Rooms
Music Plaza
music discovery
previews of the product experience

That is useful for users, but it does not automatically create strong search entry points.

So I started giving the website a second job:

explain individual product capabilities in the language people actually search for.

That led to feature pages around concepts such as:

AI Song Generator
Text to Song
Lyrics to Song
AI Remix
AI Music Video

The important part was not simply creating one page per keyword.

I wanted each page to represent a real difference in user intent.

For example:

Text to Song

The user has an idea:

A quiet song about meeting an old friend again

but does not necessarily have lyrics.

Lyrics to Song

The user already has words and wants to turn those words into music.

Those queries look similar from a product implementation perspective, but they represent different starting points for the user.

That distinction became my rule:

I do not want to create two pages only because two keywords are different. I want to create two pages when the search intent is meaningfully different.

I am still applying this rule imperfectly.

There is always a temptation to create:

/ai-music-maker
/ai-music-generator
/ai-song-maker
/ai-song-generator

and hope four pages are better than one.

They probably are not if they all say the same thing.

This has become one of the bigger lessons from the experiment.

Keywords are not the same thing as pages.

5. The website does not pretend to do something it cannot do

There is another complication.

MiraYola has a web presence, but the full creation workflow currently happens in the app.

That creates an SEO problem.

Imagine someone searches:

text to song

lands on a webpage, and discovers that the actual generation happens inside an app.

It would be easy to build an SEO page that looks like an online generator even though it is not.

I decided against that.

The feature pages explicitly explain what the feature does and then tell the user that creation continues in the MiraYola app.

The page still needs to be useful on its own:

explain the workflow
explain what input is expected
give examples
distinguish it from related features
answer common questions
show where to continue

This may or may not be enough to rank competitively.

I do not know yet.

But I would rather test an honest landing page than manufacture fake tool pages purely for search traffic.

6. The App Store and Google Play are part of the same SEO system

I used to mentally separate SEO and ASO.

Now I think the separation is less useful for a product like this.

The Google Play listing currently describes MiraYola using concepts such as:

AI music maker
AI song generator
text to song
lyrics to music
AI remix
instrumental music
music video
music discovery
live AI music

The App Store uses the same core brand/category relationship:

MiraYola: AI Music Maker

The website then reinforces those same concepts.

So instead of:

Website SEO
      +
Google Play ASO
      +
App Store ASO

I am thinking more like:

                MiraYola
                    |
        -------------------------
        |           |           |
       Web      Google Play   App Store
        |           |           |
        -------------------------
                    |
             AI Music Maker

The terminology does not need to be identical word-for-word.

But the systems should not disagree about what the product is.

7. GitHub became part of the identity layer too

I also created a simple GitHub Pages developer site.

Its purpose is not to rank for competitive AI music keywords.

It exists primarily to establish another understandable relationship:

Developer
    ↓
Products
    ↓
MiraYola
    ↓
Official Website / Store

The site lists my products and describes MiraYola as an AI music maker and exploration product.

I also updated my developer-facing profiles so that MiraYola is associated with the same creator identity.

This made me reconsider how I think about backlinks.

Previously I would have asked:

Is this a dofollow backlink?

Now I am also asking:

Does this page help establish a believable relationship between the developer, the brand, the website, and the product?

A link from a developer profile may never move a competitive keyword by itself.

But it can still be part of a coherent identity graph.

8. I started writing about the problems instead of the product

I do not want every external article to say:

MiraYola is an amazing AI music app. Download it here.

That would quickly turn into low-value self-promotion.

Instead, I am trying to write about problems that actually happened while building the product.

The previous article was one example.

The subject was not:

Introducing MiraYola

It was:

What I Learned Migrating an Android App
to a New Brand and Domain

MiraYola appeared because it was the real product involved in the problem.

This article follows the same principle.

The topic is not really:

Please search for MiraYola.

It is:

What do you actually do with SEO when your brand is too new to have meaningful branded search demand?

That creates a more natural relationship:

Developer experience
        ↓
Real implementation
        ↓
MiraYola

I have been experimenting with longer-form articles and product notes in a similar way, writing about product decisions, technical problems, branding, and AI music instead of republishing store descriptions.

Whether any of this produces meaningful search authority remains to be seen.

At this point I care more about creating legitimate references than manufacturing large numbers of weak links.

9. Social media is not only a traffic channel

YouTube, Instagram, and X originally felt separate from SEO.

I am beginning to treat them as part of the same brand system.

The direct traffic from these channels is still small.

But they create public objects associated with the brand:

MiraYola YouTube channel
MiraYola videos
MiraYola social profile
MiraYola music content
MiraYola AI music descriptions

The strategy is not to put twenty SEO keywords into every caption.

It is much simpler:

Brand
+
Content category
+
Repeated real usage

For example, a music video can naturally associate:

MiraYola
AI Music
AI Music Video

A product demonstration can associate:

MiraYola
AI Song Generator

A Live Room clip can associate:

MiraYola
AI Singer
Live Music Experience

The profiles then connect back to the same product identity.

Again, I do not know how much direct ranking value this produces.

That is not something I want to pretend I can measure yet.

But it makes the public footprint much more coherent than having one isolated website trying to establish a new word by itself.

10. I also started thinking about `sameAs`

Structured data became another part of this experiment.

Conceptually, I want the website to be able to express something like:

MiraYola
  ├── Website
  ├── App
  ├── Developer
  ├── YouTube
  ├── GitHub
  └── Other official profiles

Schema such as Organization, SoftwareApplication, and sameAs can help express those relationships.

I do not treat structured data as a ranking hack.

Adding:

"sameAs": [...]

does not suddenly create brand authority.

I see it more as reducing ambiguity.

If I am already maintaining several official identities, I want machines to have an explicit way to understand that they belong together.

11. What has actually happened so far?

This is where I want to be careful.

The experiment has not succeeded yet.

MiraYola is still a very young brand.

Branded search volume is tiny.

The website is still being crawled and re-indexed.

Some SEO pages are only beginning to appear in search.

The external footprint is still small.

And after changing the Google Play name from Song Flow to MiraYola, store browsing impressions dropped noticeably.

That last part is especially important.

A rebrand can destroy some of the recognition the old listing had accumulated before the new identity has earned anything to replace it.

So the current situation is not:

Rebrand
→ SEO strategy
→ traffic growth
→ success

It looks much more like:

Rebrand
        ↓
Old signals weakened
        ↓
New brand has little demand
        ↓
Rebuild identity across platforms
        ↓
Wait for crawling / indexing / association
        ↓
Measure
        ↓
Adjust

And I am somewhere in the middle.

12. There are still some early signals

Although I would not call them results yet, a few things are at least moving in the intended direction.

MiraYola now exists publicly across multiple independent surfaces.

The search engine can encounter:

Official website
Feature pages
Google Play
App Store
GitHub / developer site
Long-form articles
YouTube
Social profiles

Some of the new website feature pages are already discoverable.

The app stores use the new brand.

The GitHub developer site contains the new brand.

YouTube has moved to the new identity.

Third-party app indexes have also started reflecting the new name.

This is a very different situation from the first day of the rename, when MiraYola was essentially a word with almost no history.

But this is still presence, not authority.

That distinction matters.

Having ten URLs containing your brand name does not mean people search for the brand.

Being indexed does not mean ranking for competitive generic keywords.

And having social profiles does not automatically improve organic traffic.

The only thing I can reasonably say right now is:

the entity is becoming more consistently represented across the web.

Whether that eventually turns into rankings or branded demand is the next part of the experiment.

13. My current SEO model has three layers

After doing this for a while, I now think of MiraYola's SEO in three layers.

Layer 1: Brand identity

Make sure search engines can answer:

What is MiraYola?

Signals include:

official website
app stores
developer identity
social profiles
structured data
external mentions

Layer 2: Product category

Make sure the relationship is understandable:

MiraYola
    ↓
AI Music Maker

with supporting concepts such as:

AI Song Generator
AI Remix
AI Music Video
AI Music Discovery

Layer 3: Search intent

Only then do individual pages compete for things like:

Text to Song
Lyrics to Song
AI Song Generator
AI Remix Generator

I previously jumped almost immediately to Layer 3.

Now I think a new brand needs all three.

14. The matrix I am building now

The current version looks roughly like this:

Surface	Main purpose
Official website	Canonical brand identity
Feature pages	Capture specific product/search intent
Google Play	Android product identity + category
App Store	iOS product identity + category
GitHub Profile	Developer identity
GitHub Pages	Developer → product relationship
Long-form articles	Real implementation and product thinking
YouTube	Product + music/video content
Instagram	Visual/music content
X	Brand activity and product updates
Structured data	Connect official identities
Existing directories	Independent product references

The goal is not:

Get backlinks from all of them.

The goal is:

Make all of them describe roughly
the same real thing.

That is a subtle difference, but it has changed how I choose SEO work.

15. What I am deliberately not doing

There are also several things I am trying to avoid.

Creating dozens of near-identical landing pages

I would rather have one strong page for one real intent than five pages that differ only by replacing “maker” with “generator.”

Publishing the same promotional article everywhere

That creates URLs, but not necessarily useful signals.

Repeating the exact same keyword unnaturally

Consistency does not mean copy-pasting the same sentence across every platform.

Judging SEO changes after one or two days

This has been one of the hardest habits to break.

Search Console reports are delayed.

Crawling is delayed.

Indexing is delayed.

Ranking responses are delayed.

Third-party sites update on their own schedules.

SEO has much longer feedback loops than most product development.

16. What I am watching next

The next stage is measurement.

I want to see whether several things change over time.

Branded search

Does:

MiraYola

eventually produce a cleaner SERP dominated by the official product and profiles?

Brand + category

Do searches such as:

MiraYola AI Music
MiraYola AI Music Maker

become clearly associated with the product?

Feature queries

Can specific pages begin getting impressions for:

text to song
lyrics to song
AI remix generator
AI song generator

even if they start far from page one?

App discovery

Does Google Play browsing recover after the rename and metadata changes settle?

External discovery

Do independent developer pages, articles, videos, social profiles, and product listings start appearing around branded searches?

Those will be more meaningful signals than simply counting backlinks.

17. The biggest change has been how I think about SEO

Before this migration, my mental model was close to:

Keyword
   ↓
Page
   ↓
Backlinks
   ↓
Ranking

I still think all of those things matter.

But for a brand that almost nobody searches for yet, I now think the earlier stage looks more like:

Consistent identity
        ↓
Independent references
        ↓
Product/category association
        ↓
Search engine confidence
        ↓
Search visibility
        ↓
Eventually, branded demand

I cannot prove yet that this strategy will work for MiraYola.

That is part of why I wanted to write this now rather than after the fact.

Success stories tend to make experiments look much cleaner than they really were.

Right now the situation is messy.

Some pages are indexed.

Some are still settling.

The new brand exists across more surfaces.

Google Play visibility took a hit after the rename.

Generic AI music keywords are extremely competitive.

And almost nobody wakes up in the morning already planning to search for “MiraYola.”

That is the actual starting point.

Final takeaway

My previous post ended with the idea that a rebrand is really an infrastructure migration.

I would add another lesson now:

After the infrastructure migration comes an identity migration.

Changing:

Song Flow

into:

MiraYola

inside the application was easy.

Getting the wider internet to gradually understand:

MiraYola
    =
AI Music Maker
    +
AI Song Creation
    +
AI Music Discovery
    +
Live AI Music Experiences

is much slower.

So for now, I am not trying to claim an SEO win.

I am building the matrix, watching what gets indexed, watching which queries begin producing impressions, and trying to make every public surface tell a consistent story.

Maybe six months from now this experiment will look smart.

Maybe I will discover that half of these signals mattered much less than I expected.

Either result will be useful.

For now, the experiment continues.

MiraYola is the AI music product I am currently building and was previously known as Song Flow.

Website: https://mirayola.huoji.app

The previous post in this series is “What I Learned Migrating an Android App to a New Brand and Domain.”

AI-assisted disclosure: AI was used to help organize and edit this article. The product decisions, SEO experiments, migration issues, and observations are based on the actual MiraYola project.

What I Learned Migrating an Android App to a New Brand and Domain

ahfu168 — Mon, 17 Aug 2026 04:07:21 +0000

Renaming an existing app turned out to be much more than changing a logo and a store title.

When we moved our product from Song Flow to MiraYola, we had to deal with several systems that had already formed assumptions around the old brand:

Android package identity
Deep links
Website domains
Google Play App Links verification
Canonical URLs
Old shared links
Google Search Console
Third-party pages that still referenced the old name

The most important lesson was that a brand migration is really an infrastructure migration.

This post covers the parts that caused the most uncertainty and the decisions that helped us avoid breaking existing users.

1. Keep the Android package name stable

The Android app already used:

com.huoji.singflow

The public product name changed, but we intentionally kept the package name.

For an existing Google Play app, the package identifier is part of the application's technical identity. Changing it would effectively mean publishing a different application.

That would create unnecessary problems around:

Existing installs
Store history
Purchases
Deep links
Update continuity

So our setup became:

Public brand: MiraYola
Android package: com.huoji.singflow
Website: mirayola.huoji.app

It looks inconsistent, but technically it is completely reasonable.

A public brand name and an internal package identifier do not need to match.

2. Decide what the root URL should represent

The website supports multiple languages:

/en
/zh
/ja
/ko
/ar

We did not want both:

and:

/en

to behave like duplicate English homepages.

So the root URL permanently redirects to the English version:

/ → /en

The English page then declares itself as canonical.

A simplified example:

<link
  rel="canonical"
  href="https://mirayola.huoji.app/en"
/>

This gave search engines one clear English homepage instead of two competing URLs.

3. Do not panic when Search Console lags behind production

During the migration, Google Search Console temporarily reported the root page as:

Page is not indexed: Redirect error

The first instinct is to assume the current routing is broken.

Instead, we checked the real HTTP behavior:

curl -IL https://mirayola.huoji.app/

The expected flow was:

308
Location: /en

followed by:

on the destination page.

The production behavior was already correct, while Search Console was still reflecting an earlier crawl.

After Google crawled the site again, the status changed.

That was a useful reminder:

Search Console is not always a real-time representation of production.

During migrations, I now verify both:

The actual HTTP response
The latest Google crawl state

before changing routing again.

4. SEO pages and App Links should not be the same thing

One of the most useful decisions was to avoid making the entire website open inside the Android app.

Pages such as:

/en
/en/features/ai-song-generator
/en/plaza

are normal web pages.

They should stay accessible in the browser.

But URLs representing interactive app content, such as:

/room/*

are good candidates for Android App Links.

So the model became:

Informational / SEO pages
→ Browser

Interactive app content
→ Android app

This kept App Links focused instead of treating every web URL as an application route.

5. Configure the Android side with a narrow intent filter

A simplified intent filter looked like this:

<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />

    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />

    <data
        android:scheme="https"
        android:host="mirayola.huoji.app"
        android:pathPrefix="/room/" />
</intent-filter>

This tells Android that the application wants to handle URLs under:

https://mirayola.huoji.app/room/

The important part is keeping the scope intentional.

Just because an app owns a domain does not mean every page on that domain should open the app.

6. Verify the relationship with `assetlinks.json`

The website also needs to authorize the Android application.

That happens through:

/.well-known/assetlinks.json

A simplified example:

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.huoji.singflow",
      "sha256_cert_fingerprints": [
        "PLAY_APP_SIGNING_SHA256"
      ]
    }
  }
]

The most important detail here is the signing certificate.

For an app distributed through Google Play, the fingerprint used by production installations may be the Play App Signing certificate rather than the certificate used locally.

Using the wrong fingerprint can make the configuration look correct while verification still fails.

7. Keep the old domain alive during the transition

Old links do not disappear when a brand changes.

They may still exist in:

Old social posts
Chat messages
Bookmarks
Search indexes
Previously shared content

Instead of immediately removing the old Song Flow domain, we kept it available during the migration.

The new domain became the preferred destination:

mirayola.huoji.app

while old links could continue working when necessary.

This was especially important for deep links.

A migration is much safer when new links move forward without forcing every old link to stop working on the same day.

8. Redirects and App Links solve different problems

This distinction helped simplify the architecture.

A redirect answers:

Which web URL should this web URL resolve to?

For example:

/ → /en

An App Link answers:

Should Android open this HTTPS URL in the app?

For example:

/room/123 → Android app

Those are separate layers.

Mixing them together makes debugging much harder.

9. The hardest part was not technical

Most of the technical changes can be verified quickly.

You can check:

HTTP responses
Canonical tags
assetlinks.json
Android intent filters
Google Play Deep Links verification

The harder part is that external systems update at different speeds.

After a rebrand:

The app store may show the new name immediately
Google Search may still show old information
Third-party directories may take longer
Old URLs may remain indexed for some time

That does not necessarily mean the migration is broken.

It often means the internet is gradually converging on the new identity.

What I would do differently next time

Before changing the public brand, I would make a migration checklist covering:

Domains
Android App Links
Deep links
Canonical URLs
App store metadata
Structured data
Social profiles
Shared URLs
Third-party listings
Search engine indexing

I would also test all important URLs before and after the change.

A few simple commands can catch a surprising number of problems:

curl -I https://example.com/
curl -IL https://example.com/
curl https://example.com/.well-known/assetlinks.json

And most importantly, I would avoid changing stable technical identifiers unless there is a real reason to do so.

The public brand can change.

The infrastructure does not always need to.

Final takeaway

The visible migration was simple:

Song Flow → MiraYola

The actual migration involved:

Brand
+
Domain
+
Redirects
+
Canonical URLs
+
Android App Links
+
Deep Links
+
Backward compatibility
+
Search re-indexing

That is the part of a rebrand users rarely see.

If you are planning a similar migration, my main advice is:

Treat the rename as an infrastructure change first, and a branding change second.

This post is based on the real migration of the MiraYola Android app and website.

AI-assisted disclosure: AI was used to help organize and edit this article. The technical decisions and migration details are based on the actual implementation.

DEV Community: ahfu168

How I’m Building SEO for a Brand Nobody Searches For Yet

1. The first SEO problem was not ranking

2. The model became a matrix instead of a website

3. I started by making the product identity boringly consistent

4. The website now has two jobs

Text to Song

Lyrics to Song

5. The website does not pretend to do something it cannot do

6. The App Store and Google Play are part of the same SEO system

7. GitHub became part of the identity layer too

8. I started writing about the problems instead of the product

9. Social media is not only a traffic channel

10. I also started thinking about sameAs

11. What has actually happened so far?

12. There are still some early signals

13. My current SEO model has three layers

Layer 1: Brand identity

Layer 2: Product category

Layer 3: Search intent

14. The matrix I am building now

15. What I am deliberately not doing

Creating dozens of near-identical landing pages

Publishing the same promotional article everywhere

Repeating the exact same keyword unnaturally

Judging SEO changes after one or two days

16. What I am watching next

Branded search

Brand + category

Feature queries

App discovery

External discovery

17. The biggest change has been how I think about SEO

Final takeaway

What I Learned Migrating an Android App to a New Brand and Domain

1. Keep the Android package name stable

2. Decide what the root URL should represent

3. Do not panic when Search Console lags behind production

4. SEO pages and App Links should not be the same thing

5. Configure the Android side with a narrow intent filter

6. Verify the relationship with assetlinks.json

7. Keep the old domain alive during the transition

8. Redirects and App Links solve different problems

9. The hardest part was not technical

What I would do differently next time

Final takeaway

10. I also started thinking about `sameAs`

6. Verify the relationship with `assetlinks.json`