One name: Rodrigo ES Porto across the entire site
In the previous post, I talked about the site review conducted by four agents from our team, who evaluated our setup with A+ scores in security and performance.
What I wanted to solve
I work during the day, and at night and on Sundays I build with AI agents. I have never programmed professionally. When my personal website launched on 3 October 2026, my initial reaction was relief. The custom domain was working, the home page opened quickly, and the main articles carried my proper name.
A closer look at the review findings revealed an annoying consistency problem. In several places that an ordinary visitor does not notice right away, the site was still using an older, shorter version of my name. That outdated reference appeared in the browser tab title, in the footer on some pages, in the summary descriptions prepared for search engines, in the RSS feed file, in the web app manifest, and even on the social sharing preview image generated for social platforms.
On that same day, 3 October, I made a firm decision: change everything to Rodrigo ES Porto. Having two different forms of your name circulating causes confusion. Someone sees the site shared on X under one name, clicks through and reads another, while search engines index a third term. A personal brand only works if you maintain the exact same identity across every point of contact.
Quick summary
- The audit showed that an older, shorter version of my name remained scattered across configuration files and metadata.
- I mapped out six critical spots where the old text stayed hidden: browser tab titles, footers, search snippets, the RSS feed, the web manifest, and the social preview card.
- Arte designed a new social preview image featuring the corrected brand name.
- I applied all the adjustments in the project files and pushed them in a single GitHub commit.
- I verified all 30 live pages of the site from an outside browser to confirm that the changes went live cleanly.
- Time and cost: about one hour of focused work and zero additional spend on tools.
First: what these hidden places actually are
Anyone unfamiliar with website internals might assume that the text visible on the screen is all there is. Behind the scenes, a website relies on instructions that talk directly to browsers, search engine crawlers, and social networks. When those instructions fall behind, the consistency of your project takes a hit.
The browser tab title is the line of text shown at the very top of your browser window. It is also the primary headline Google displays in search results. If the tab carries an old label, anyone juggling multiple open tabs will have trouble finding their way back to your post.
The meta description is a brief summary stored inside the page code. Visitors do not read it while browsing the article itself, but search engines place it directly beneath the title link on search results pages. If that snippet holds an outdated name, the search listing looks mismatched.
The RSS feed is a plain text file that compiles recent articles in a structured format. With it, news reader apps and automated aggregators let subscribers know whenever a new post appears, without requiring them to visit the website manually every day.
The web app manifest is a small instruction file for mobile devices. If a reader decides to pin a shortcut to the site on their phone home screen, this file tells the operating system what title to place under the icon and which graphic to display.
The social preview image, commonly called Open Graph across social networks, is the rectangular card that pops up automatically when someone pastes your article link on X or inside a messaging app. Without this card set properly, your link displays without visual context or pulls a random generic icon.
A commit is a save record in GitHub. Instead of saving stray files without tracking your steps, you bundle a related group of edits together and stamp them with an explanatory note, recording the date and time in your project history.
What I used
- Hugo: the static site generator that processes our markdown drafts and builds the production site.
- Google Antigravity: the coding environment where I reviewed and modified template files under my direct guidance.
- GitHub: the platform where I store version history and publish website updates.
- Arte: our creative agent on Grok Bot responsible for designing visual graphics and team member avatars.
How the cleanup happened in a single commit
With the review checklist in front of me, I structured the work to resolve everything at once. The goal was to avoid having half the website updated while the other half remained on the old label.
First, I opened the primary site configuration file in Antigravity. That was where I adjusted the global site title, author variables, and base descriptions to strictly read Rodrigo ES Porto.
Second, I walked through the page templates for the header, footer, and base layout. In a few of those templates, the older text had been typed directly into the HTML structure instead of referencing the central author variable. I updated every occurrence to pull from the official name.
Third, I inspected the templates that produce the RSS feed and the web app manifest. These files are easy to overlook because nobody views them during daily reading, yet they still held the outdated phrase.
Fourth, I received the updated social preview image from Arte. She generated the graphic using the official visual palette with the corrected name placed prominently. I placed the asset into the theme image directory and updated the social preview paths.
Fifth, I published the update. After reviewing the full set of changed files, I committed everything together in one GitHub push. Seconds later, the hosting platform received the commit and rebuilt the site automatically.
Sixth, I checked the live site from the outside. I opened a clean browser and visited all 30 pages currently published, verifying the tab title, the footer text, and the page source on every single one to make sure the older reference had vanished completely.
What went wrong and what I learned
The biggest surprise was seeing how easily an old name embeds itself in hidden layers. When you bootstrap a site, default templates and automated setup wizards populate background fields using whatever name you supplied on day one. If you later refine your public brand identity, changing the body copy of your posts is only part of the job.
Another hurdle was browser caching. During my first verification pass, the social preview image and the manifest still pointed to the older files on my machine. The server had updated, but my local browser was serving stale assets stored in memory. I had to clear local cache files and re-check each page through an incognito window to view the site exactly as a first-time visitor would.
The practical takeaway for anyone starting out is simple: treat your site metadata with the same care you give your main articles. Search bots and social platforms do not view your design visually; they read the code tags underneath.
Costs and limits
The additional financial cost for this entire cleanup was zero. I relied on the existing code editor and version control repositories already in place, while the updated graphic came from Arte using our active visual tools.
In terms of time, the cleanup took about one hour of focused effort covering file adjustments, the commit push, and manual verification of all 30 live addresses.
The limitation of this task is that it requires human judgment. An automated tool can find and replace words in a text file, but only a human can check whether a social card remains readable on a smartphone screen or whether a browser tab title runs too long to fit comfortably.
What I would do differently
If I were starting this setup from scratch today, I would establish a single global author variable across the main configuration file on day one. Hardcoding names directly into layout templates created avoidable extra work when it came time to update everything.
Who this is for and who it is not for
This practice helps anyone publishing content online who wants to build a clear, dependable identity. If you write articles, share links on X, or manage a public portfolio, having a uniform name ensures readers never wonder who created the work.
It is not as critical for someone still experimenting with early rough drafts who has not decided on a permanent project name or public launch. In those early testing days, your focus belongs on writing and testing. But the moment you attach a domain and invite people to read, consistent branding becomes essential.
Next steps
With one uniform name across every page and background file, the public structure of the site looks tidy and reliable. In the next part of our series, I will present the ecosystem map: each agent and where it lives, detailing how we distribute responsibilities between local machines and cloud systems.
If you are building your own projects with the help of artificial intelligence tools or want to discuss this workflow, connect with me on X at @RodrigoesPorto. That is where I talk through what I am learning at every step of this journey.