[RFC] Rename mui.com/components/ to mui.com/react/

[oliviertassinari]

Summary

I propose we rename the https://mui.com/components/* URLs to https://mui.com/react/*.

Basic example

https://mui.com/components/modal/ would be available as https://mui.com/react/modal/.

Motivation

We are renaming all the URLs by changing the domain name (material-ui.com -> mui.com), this is going to negatively impact our ranking for ~3 months. Since renaming URLs is risky and costly, we probably don't want to do it twice in a single year. So I'm using this change, as an opportunity to discuss batching another one.

Developers, at large, are prefixing all their queries with "react" when fishing for a dependency when they face a specific problem. The higher we rank on Google for these queries, the more likely the developers will pick us, adopting us. (Developers already knowing us, likely search with the "mui" prefix instead).

Based on https://www.searchenginejournal.com/technical-seo/url-structure/ keeping track of the official statement that Google did on this topic, they are increasingly pushing towards hiding URLs and considering them overrated for search ranking (reducing the ranking influence). What they seem to emphasize instead, is to make so that the URL makes it clearer what's the page is about.

I think that this change could bring the following values:

1. A slight SEO ranking advantage. For instance, for the query "react date picker", we don't rank well.

You will also notice, the top-ranking results often have react in the URL. What is the correlation?
3. A terminology that clarifies that we expose React components, not Vue components, not Low-code components.
4. A terminology that scales with hooks. Isn't this weird https://material-ui.com/components/use-media-query/?
5. A terminology that allows us to expand to other platforms if we need it in the future: VR, Angular, etc. We are already building a team for a new low code product.

Benchmark

with "react":

• https://headlessui.dev/react/tabs
• https://ag-grid.com/react-data-grid/
• https://www.telerik.com/kendo-react-ui/components/buttons/button/disabled-state/
• https://react-table.tanstack.com/

with "component":

• https://ant.design/components/tree-select/
• https://material.angular.io/components/autocomplete/overview

Drawbacks

• Maybe it doesn't matter, it's not worth spending a couple of hours on implementing the change.
• Maybe mentioning react in the URL could suggest that we have more to offer, making it confusing. A counter-argument would be: it's more specific, maybe it will invite developers to propose targeting other platforms, we will eventually do more than react, e.g. could be Figma,

Alternatives

• do nothing
• use "react-components" in the URL instead of "components"

Unresolved questions

This change is part of a larger thread that we initiated in https://www.notion.so/mui-org/Sitemap-and-URL-structure-rearrange-ca604f628c17438db2d987961fcb8ffe about the overall URL structure. Here is how it currently looks like, with this proposal:

Main pages:

• mui.com/
• mui.com/pricing/
• mui.com/about/
• mui.com/store/
• mui.com/blog/
• mui.com/careers/

Product Marketing pages:

• mui.com/core/ → Marketing page for the set of Core components.
• mui.com/x/ → Marketing page for the set of advanced components.
  • mui.com/x/license/ our EULA
• mui.com/templates/→ Marketing page for the Templates.
• mui.com/design-kits/ → Marketing page for the Design Kits.
• mui.com/studio/ → Marketing page for the Studio/low-code product.

Docs MUI Core:

• mui.com/docs-core/getting-started/ → Documentation about the Core components as a whole. "getting-started" is only an example.
• mui.com/docs-core/api-material/modal/ → API documentation for a module in a given package
• mui.com/react/components/ → Page for displaying all components of the Core and X sets.
• mui.com/react/modal/→ Main component page, showcasing it in both DSs, which its toggling will happen on the client-side.
  • mui.com/react/modal/base/ → Unstyled documentation of the component.

Docs MUI X:

• mui.com/docs-x/getting-started/→ Documentation about the Advanced component as a whole. "getting-started" is only an example
• mui.com/docs-x/api-x-data-grid/grid-toolbar → API documentation for a module in a given package
• mui.com/react/data-grid/ → X component main page.

Docs Studio:

• mui.com/docs-studio/ → all the docs under this folder

[oliviertassinari]

As a side note, I wonder about the name of @mui/core. I personally feel that it's a bit weird:

• It doesn't match the prefix of the components we intend on using, e.g. SliderBase
• It doesn't match the latest folder URL name we intended on using, e.g. mui.com/react/modal/base/
• It can be confused with MUI Core, this product includes all the packages, it's not only about @mui/core
• It can be confused with @material-ui/core

At this point, I think that I would vote for @mui/base, luckily for us, this package is in alpha. We are still allowed to do breaking changes if needed.

[eps1lon]

they are increasingly pushing towards hiding URLs and considering them overrated for search ranking (reducing the ranking influence). What they seem to emphasize instead, is to make so that the URL makes it clearer what's the page is about.

These statements contradict each other. Is google considering URLs more or less for SEO?

From the source you linked, it's clear that the trend has been to consider URLs less for SEO. So why propose this change?

The specific example doesn't even apply and changing URLs just for SEO is also a constant battle. On the other hand, every existing URL now has to redirect and everybody needs to re-learn.

This does not seem like we gain any value long term.

A slight SEO ranking advantage. For instance, for the query "react date picker", we don't rank well.

You did not provide any proof that changing the URL will increase SEO ranking (see causation vs correlation).

3. A terminology that clarifies that we expose React components, not Vue components, not Low-code components.

On the other hand, this implies that we do contain non-react components. We don't and there are no long-term plans to do so.

4. A terminology that scales with hooks. Isn't this weird material-ui.com/components/use-media-query?

We could just as well move the page to e.g. /hooks.

5. A terminology that allows us to expand to other platforms if we need it in the future:

Don't try to solve scaling issues that aren't even possible long-term (see YAGNI).

[oliviertassinari]

Is google considering URLs more or less for SEO?

@eps1lon From what I understand the statements done by Google. They are using the URL as a ranking factor of limited influence. Long-term, they are trying to completely nullify its influence. They emphasize that the URL should ultimately be about helping people clearly understand what the page is about.

From the source you linked, it's clear that the trend has been to consider URLs less for SEO. So why propose this change?

Because

1. It might be more accurate to describe what the page is about. Most of our competitor uses react in the URL, I think that it's training our audience for React content -> react in the URL. We might have to follow the trend, to clarify our URLs.
2. it has a slight SEO influence. In a winner take it all context, it matters. For example, +1% of performance in the JO, and you get the gold medal. In SEO, the CTR (click-though-rate) on the SERP (Search Engine Results Pages) is not linear. This is the exposition gotten per position. There is an order of magnitude difference between rank 3, and rank 10. In the case of the date picker, we are far behind.

• Position 1 – 43.32%
• Position 2 – 37.36%
• Position 3 –29.90%
• Position 4 – 19.38%
• Position 5 –10.95%
• Position 6 – 10%
• Position 7 – 5.28%
• Position 8 – 4.13%
• Position 9 – 4.13%
• Position 10 – 3.11%

https://ignitevisibility.com/google-ctr-by-ranking-position/#googlectr.

every existing URL now has to redirect

The reasoning was that we already redirecting every existing URL from material-ui.com/* to mui.com/$. Why not batch it? Google says that 301 has no impacts on SEO ranking but I don't trust it. Two years ago, when we changed the URLs from v3 https://v3.material-ui.com/demos/avatars/ to v4 https://v4.material-ui.com/components/avatars/, ahrefs reported a -30% negative influence for over 3 months.

I think that the main counter-argument to this is that Google provides a domain change tool, so maybe a domain name change is cheap, while a folder path change is not. Meaning, the batching argument doesn't make sense and discredits the timing of this discussion: no value at doing it now, if we ever do it.

needs to re-learn.

I think that we can ignore this aspect, it has no long-term impact.

You did not provide any proof that changing the URL will increase SEO ranking (see causation vs correlation).

https://www.searchenginejournal.com/technical-seo/url-structure/ includes a statement of Google that says that there is a causality relationship.

"I believe that’s a very small ranking factor, so it’s not something I’d really try to force. And it’s not something where I’d say it’s even worth your effort to kind of restructure your site just so you can include keywords in the URL" https://www.youtube.com/watch?v=4FkSZIW6d48

On the other hand, this implies that we do contain non-react components. We don't and there are no long-term plans to do so.

I guess it depends on how close to React code API we are in the low-code effort.

[eps1lon]

It might be more accurate to describe what the page is about.

So you don't even know. Why do you propose things that have no certainty? It might be just the opposite.

it has a slight SEO influence.

Where do you take that from? So far you have provided no evidence that this is the case.

searchenginejournal.com/technical-seo/url-structure includes a statement of Google that says that there is a causality relationship.

Could you give the exact statement you believe says this? I could not find any in the article.

That article as a whole is just poor quality. It contradicts itself throughout the page. It starts with "we don't know" to "it has an impact" but doesn't source these claims. This reads like an average to below average article about a primary source without linking that primary source.

I guess it depends on how close to React code API we are in the low-code effort.

Please elaborate what that even means right now. Not maybe. Not in the past. Not in the future. Right now.

I think you are not capable of constructing a logical, evidence based argument. What you're trying to do is justifying that you want to change it. But you have no foundation on which this desire is based. You're post-hoc rationalizing your desire. You didn't collect facts that formed a desire for change.

And in every other area we agree that proving a negative is impossible. You have to make an argument for something. I don't need to make an argument against something.

As a closing statement please consider the very resource you linked:

When in doubt, optimize for the user because Google always recommends making pages useful for users.

This is clearly a doubtful change. So don't make that change since it doesn't serve the user. Quite the opposite, it takes away from the user by introducing potential for breakage and development time.

[mnajdova]

Looks like there wasn't a unified agreement on the new URLs, so in my opinion, we should just focus on changing the domain name at this moment if we want to be on track with changing the domain with the v5 stable release.

[oliviertassinari]

On another note, we started to make the component name singular (for all the new ones, and all the SEO attributes). I think that when we get the opportunity, we could do https://material-ui.com/components/buttons/ -> https://material-ui.com/components/button/

[danilo-leal]

Though I agree that now is probably a good time to think about batching this change since we're already changing the domain, I'm afraid it's not really worth the work to use /react right now.

My main concern is that it will signal, especially for new users, that if we have a /react, we might as well have a /vue or /angular or whatever. The thing is that we'd have to create a page for these URLs, since people would probably try them out, where we'd have to explain that we actually don't support these frameworks yet. Although it can be a useful metric (how much people land on these as a proxy for interest), I'm sure we could have it in cheaper ways.

I'm also not bought into the perspective that swapping /components for /react would give a significant SEO boost. I'm not an expert so take it with a grain of salt. But how much the date-picker example is actually illustrative? I'd suppose that there are probably other reasons as to why it doesn't rank so well.

Regarding the other topic, which is the docs URLs (given that the marketing pages are ok), I have a few thoughts about it, but they're all mostly questions and ideas, no hard argument for any of them:

• Would we really need the docs prefix? Would it work to be only /core/getting-started or /x/getting-started?
• If having docs is important, say for SEO or whatever, it reads better to me to have it after the product, as in /core/docs/getting-started. The hierarchy seems more logical in that sense: marketing page (explanation, contact) -> documentation (deep dive, usage).

Also, separating the documentation between products in the URL makes me wonder if we should have two different docs for each product. What I mean is: think about two completely different side-navs, one for the Core and another for the X components. I'm personally fond of this idea for I believe it makes it clearer and helps people navigate around them.

• When browsing through the Core components docs, I'd know everything there is free, no need to worry. When doing it on the X ones, a bit more attention is needed, since maybe the feature I'm looking for could be in a paid tier.

However (and anyways), I believe we should continue with only the domain change for now. We can keep discussing the URLs further on as it will for sure demand more back and forth.

[oliviertassinari]

My main concern is that it will signal, especially for new users, that if we have a /react, we might as well have a /vue or /angular or whatever. The thing is that we'd have to create a page for these URLs, since people would probably try them out, where we'd have to explain that we actually don't support these frameworks yet.

I'm personally not worried about this aspect. I think that a 404 error message is clear enough. I also think that developers are used to seeing "react" as a prefix of all the OSS projects they use. By now, they have learned it's because these projects need to clarify what they do, not because they also have a vue version.

Would we really need the docs prefix? Would it work to be only /core/getting-started or /x/getting-started?

I have proposed a different folder for the docs, so that, we could simplify the URL routing if we ever came to isolate the marketing site, to the documentation websites (at the technical level). Happy to ignore this aspect, it anticipates for what I could see on most of the larger projects, it felt that it will eventually always have to come to it. But delaying sounds great. Most of these pages have no competitive SEO value anyway, and maybe I anticipate something that will never come.

Also, separating the documentation between products in the URL makes me wonder if we should have two different docs for each product. What I mean is: think about two completely different side-navs, one for the Core and another for the X components. I'm personally fond of this idea for I believe it makes it clearer and helps people navigate around them.

Yes please.

[oliviertassinari]

Thanks for bouncing back thoughts at this. I think that we can wait, if we ever want to do this change, we don't need to do it now.

• Google has an SEO domain name change tool. I suspect that a cheap domain name change is cheaper than a folder name change.
• URL changes have inertia, Google takes weeks to update its index/ranking, we don't have to do it all at once, if we do it 2-3 weeks, it would probably have the same impact.