A bilingual personal website needs to describe one person consistently while allowing each language to serve its own readers. The difficult part is not adding a language switch. It is deciding which pages are equivalents, which articles are independent, and which claims about the author are actually supported.
This article reviews the identity structure implemented for UgurKeser.art and provides a maintenance checklist. It describes the site code inspected on 24 September 2026. It does not claim that Google has created a knowledge panel, accepted every structured-data relationship, or indexed every page.
One person, separate language contexts
The site’s structured data uses a single stable person identifier: https://ugurkeser.art/#person. The visible name is Uğur Keser. Turkish and English pages refer to that same identity rather than defining unrelated authors for each language.
A stable identifier helps keep the site’s own references coherent. It is not a registration with a search engine and does not compel an external system to merge entities. The useful implementation question is whether the website describes the same person consistently across its author references and profile pages.
The public role is founder and project manager. That confirmed role should not expand automatically into unverified claims about company ownership structures, team size, awards, revenue, or project maturity. An identity graph is only as credible as the facts supplied to it.
The profile page has a specific job
The Turkish and English about pages are modeled as profile pages whose main entity is the shared person. They provide a place for readers to understand who is responsible for the work. The profile should remain useful as visible content even if a search engine ignores its markup.
Google’s profile-page documentation includes an author’s about page among the supported use cases and describes the connection between the page and its main person or organization. That technical vocabulary should follow the page’s actual purpose. A page containing unrelated commercial content should not be forced into a profile role merely to add another schema type.
On this site, the person record includes a public LinkedIn reference. Maintaining a short, checked set of identity links is preferable to adding every profile that happens to contain a matching name. Similar names do not establish that two profiles represent the same person.
Articles connect authorship to a real page
A byline should help a reader reach the author’s background and related work. The site’s article template displays the author and publication date, provides related reading, and emits article and breadcrumb information. These features support navigation and attribution; they do not establish expertise in every subject by themselves.
The editorial rule is to distinguish a project record from an application guide. A record can describe tested work with dates and evidence. A guide can explain a proposed method without claiming it has been applied successfully. Both can belong to the same author, but they make different promises to the reader.
That distinction matters especially in a portfolio. A project title placed beside a detailed article can make a hypothetical example look like a completed case study. The opening paragraph should make the status clear before the reader encounters any example numbers or proposed process.
Language equivalence is an editorial decision
The site publishes Turkish articles under /yazilar/ and English articles under /en/insights/. A Turkish Shopify migration checklist and an English event-taxonomy guide may be related, but they are not translations of the same content. The language switch must not imply that one is the other in a different language.
For core pages that genuinely correspond, the site can declare language alternatives. For independent articles, it does not invent an equivalent merely because both languages have content in the same topic area. The implementation groups alternatives only when an explicit translation relationship is present.
Google’s localized-page guidance describes hreflang as a way to identify language or regional versions of corresponding content. The important maintenance task is therefore to preserve the relationship, not maximize the number of alternate tags. Missing a translation is an editorial state; it should not be disguised with an unrelated destination.
Canonical addresses and identity identifiers differ
A canonical URL identifies the preferred address for a page. The person identifier identifies the person within the site’s structured description. They serve different purposes and should not be interchanged.
The current layout emits an absolute canonical address for the page being rendered. Article paths are generated from explicit locale and slug data, with preserved legacy paths where applicable. This reduces the chance that an English article accidentally advertises the Turkish listing as its canonical page.
A canonical declaration remains a signal to search engines, not proof of their final selection. Live inspection and search reporting are needed to understand how a page is processed externally. A correct tag in the source is an implementation result, not an indexing result.
A practical verification matrix
| Check | What to inspect | What a pass establishes |
|---|---|---|
| Person identity | Reused person identifier and visible name | Internal consistency |
| Profile relationship | About page points to the person | Intended page-to-person relationship |
| Article attribution | Byline and author reference | Declared responsibility for the article |
| Language pairing | Only corresponding pages are paired | Accurate editorial equivalence |
| Canonical address | Current page’s intended URL | Correct declared page preference |
| External profile | Link belongs to the intended identity | A supported identity reference |
Run these checks on both languages and on at least one independent article. Also test a page without a translation. A system that works only when every page has a counterpart will eventually misroute readers as the publication program grows.
Keep claims and dates maintainable
Publication dates should describe publication. Updated dates should reflect a meaningful revision rather than being advanced automatically every day. Project status and profile descriptions also need an owner: an outdated claim is not fixed by technically valid markup.
When a role changes, update the visible profile and structured description together. When a social profile disappears, verify and repair the reference. When an article becomes a genuine translation, record that relationship explicitly and check it in both directions.
The current implementation provides a foundation for these tasks. It does not remove the need for editorial maintenance or demonstrate a search visibility outcome. Future reviews should record the inspected version and separate code checks, live accessibility checks, and search-engine observations.
Primary references are Google’s profile-page documentation and localized-versions guidance. For the broader implementation history, see the Turkish WordPress-to-Astro migration record. For measurement design, read the event taxonomy guide.