Why a cookie is not enough
The quickest way to make a site bilingual is a cookie: the visitor picks a language, the server remembers the choice and renders the right text. For a signed-in application that works fine.
For a public site it is a problem. A crawler does not send a cookie and therefore always sees the default language. One URL can only have one canonical body, so the second language simply never gets indexed — no matter how good the translation is.
The language in the path
Give every language its own path: /nl/portfolio and /en/portfolio. In ASP.NET Core you do not need custom routing for this; a small RequestCultureProvider that reads the first path segment is enough.
- Give every page two @page directives, one per language.
- Add a canonical per page plus hreflang references to the other language and x-default.
- Make the language switcher force a full reload, so the server culture changes along with it.
- List both languages in your sitemap, with the alternates included.
The pitfall with interactive server
With Blazor Server the culture is fixed when the circuit is created, on the first HTTP request. If you then navigate internally to a path in the other language, the URL changes but the culture does not.
The fix is simple: let only the language switcher do a hard navigation. Every other link inside the page keeps the current language prefix, and URL and content stay in sync.