"Keeping the same URLs because 'SEO is scary'" is almost certainly a losing move over a three-year span.
When ChatGPT surfaced that line in our discussion, I made up my mind. The TIELEC Blog I had operated for five years was going to move from WordPress (database-driven) to Lovable (Markdown files). And this time, I would completely rethink the URL structure.
One hundred posts. All that content we had built up. It was time to refresh it.
The decision catalyst: Meeting Lovable
In the latter half of 2025, I started using Lovable.
At first, I shrugged and thought, "Another tool, huh?" But once I started playing with it, I felt it.
This is an incredible tool.
You can compose a website freely while leveraging LLMs. You envision what you want to do and then realize it with speed. On WordPress, whenever I wanted to customize, it never felt that fast - pick a theme, hunt for plugins, tweak PHP...
Lovable was different. Flexible, polished, and fast. If you'd like to try Lovable, you can get started with this invite link:
🔗 https://lovable.dev/invite/HN8QQET
"This is the tool I should leverage going forward."
When I decided that, another thought followed immediately: maybe now was the moment to migrate.
We had been running the blog for five years, stacking up a hundred posts. But that was exactly why-if we didn't change now, we would stay on WordPress forever. Multilingual support, Git management, ideal URL design: all would remain "someday projects."
Clarifying requirements with ChatGPT: Dialogue for clarity
I started by asking ChatGPT:
"I want to rebuild this blog on Lovable. Can you help me clarify the requirements and write the prompt to hand over to Lovable?"
ChatGPT inspected the current blog and pointed out the WordPress-specific URL structure (/index.php/<slug>/). Then it presented two options.
Plan A: Keep URLs in place (safe, conservative)
- Keep the current URLs
- Minimally implement 301 redirects
- Almost zero SEO damage expected
Plan B: Redesign URLs (growth-focused)
- Switch to
/ja/blog/<slug>/and/en/blog/<slug>/ - Integrate multilingual support into the structure
- Short-term SEO dip, long-term strength
I hesitated. The SEO value of these 100 posts-could I really let go of it?
When I asked how long recovery might take, ChatGPT answered:
"SEO will recover even if the URLs change. However, the recovery timeframe ranges from a few weeks to more than half a year, depending on planning and migration quality."
It also outlined rough phases:
- Initial turbulence: 1-2 weeks (rankings dip temporarily)
- Reevaluation: 3-8 weeks (Google tracks through the redirects)
- Recovery: 2-4 months (back to the old rankings)
- Growth: 3-6+ months (structural improvements kick in)
But I also thought: we plan to keep producing new posts. We are serious about multilingual support. Isn't it better to endure some pain now and lock in the ideal structure?
"Let's go with Plan B."
The wisdom of phased migration: A three-phase strategy
After choosing Plan B, another discussion arose.
At first, I thought, "We can finalize the design first and map the URLs later, right?"
ChatGPT calmly but firmly said:
"Deciding the mapping later is risky for SEO."
The reasons were clear:
- Google remembers what it first sees.
- Once users hit a 404, recovery slows down.
- Leaving slug decisions for later almost always leads to drift.
In other words, you need to finalize the mapping to the old URLs while you're building the new blog. But you also don't want search engines to index the unfinished work during the experimentation phase.
That led to the three-phase strategy.
Phase 1: Fix the design (hide from search engines)
- Build out the UI/UX of the new blog
- Add
noindex, nofollowto every page - Skip generating sitemap.xml
- Block crawling via robots.txt
At this stage, the new site is invisible to search engines. You can rebuild it repeatedly without impacting SEO.
Phase 2: Finalize slugs → map → migrate articles
- Finalize the slug list from the old WordPress URLs
- Fix the new URLs (
/ja/blog/<slug>) definitively - Prepare a complete 301 redirect map
- Place Markdown articles
- Update internal links to rely on the new URLs
Only after this phase is the structure ready for publication.
Phase 3: Switch the domain (go live)
- Activate the 301 redirects
- Remove
noindex - Submit the sitemap
- Monitor via Search Console
Google can now immediately understand that the new URLs replace the old ones. That's how you minimize SEO damage.
How the migration actually unfolded: Preparation paid off
I had some groundwork already laid for this migration.
I had used the WordPress plugin Git it Write to export articles into Markdown for Git. So exporting Markdown wasn't the hardest part.
The most tedious work was mapping the site URLs.
Mapping from old /index.php/<slug>/ to new /ja/blog/<slug>/ took time. About 80% mapped smoothly, but the remaining 20% needed individual attention.
- Articles whose categories had shifted
- Slugs that contained special characters
- Posts with a history of slug changes
I verified each of them carefully, often leaning on LLM assistance. I'd give ChatGPT the old URLs and ask for a conversion into the new format. Doing that by hand would have been soul crushing.
Building on Lovable: Two days of astonishment
The final prompt for Lovable, crafted through repeated discussions with ChatGPT, was nearly 1,000 words long.
What mattered most was that we clearly separated what we would do now from what we wouldn't.
â– Current scope (â‘ Design finalization phase)
doing
- Finalize the blog-wide base design
- Design the UI with multilingual support in mind
- Build a structure resilient to future URL redesigns
done by others (important)
- Production launch
- SEO tasks (canonical, hreflang, sitemap, etc.)
- Final slug decisions
- Mapping to old WordPress URLs
- 301 redirects
After handing this prompt to Lovable, progress accelerated in a way I hadn't expected.
It wasn't perfect on the first try, but the broad strokes of the design came together quickly, and we could add the necessary features one by one. The speed felt incomparable to WordPress.
Two days.
In just two days, the blog's core structure was ready. Compared to installing WordPress on a server, customizing a theme, and so on, it was clearly faster.
Again, I was reminded how phenomenal this tool is.
The SEO reality: Still uncertain
How is the SEO holding up after the migration?
Frankly, it's still unclear.
We just launched, so it's hard to see long-term effects. However, judging by the page views, it doesn't seem like we suffered a huge hit. Whether that's genuine recovery or just the baseline, only time will tell.
In a few months, we will inspect Search Console data: Are the 301 redirects credited? Are the new URLs indexed? How have the rankings changed?
For now, we are in that waiting period.
Future operations: The potential of Git management
Switching to Markdown changed the writing workflow.
It's still early, so I can't say "writing speed has gone up" yet, but that's definitely our goal. Git-based management makes reviews easier and clarifies version history.
We're now ready to take multilingual support seriously. The URL structure is already separated into /ja/ and /en/, so it's just a matter of translating and placing the content.
Looking back: Aiming to say "that was fun"
Looking back, was choosing Plan B the right move?
Honestly, I don't know yet.
Right after the migration, I still have doubts. Will SEO recover? Will multilingual support work as planned? Will Git-based operations stick?
But there is one conviction:
The important thing is to make sure we can look back and say, "That was fun."
Facing technical debt brings pain. Resetting five years and a hundred posts was heavy. But if we kept postponing it, three or five years from now would feel even scarier.
I saw potential in Lovable. I migrated. I discussed the risks with ChatGPT and planned to minimize them. Prepping with GitIt Write made the migration smooth.
Things didn't go perfectly. Mapping still required 20% of the posts to be handled individually, and we still don't know how SEO will turn out.
But the process itself was a lesson.
If a junior engineer ever told me, "SEO is scary, so I want to keep the URLs as they are," I'd tell them:
"Your fear is justified. But if you don't change now, when will you? Three or five years from now will be even scarier."
Technical debt balloons over time. If you can choose the right moment to tackle it, it stops being debt and becomes an investment.
I will keep writing and make sure this migration truly becomes an investment.