How I’ve Improved My Blog with GPT, One Step at a Time
How I use GPT for readable pages, multilingual SEO, search submissions and WeChat drafts—and how I check the results.
My blog, weiyii.cn, has used GPT for page changes, multilingual content, search submissions and WeChat drafts.
At first, my questions were broad: “How can I optimize the website?” “Why hasn’t Baidu indexed it?”
I learned to point directly at what bothered me. Cramped typography? Change it. Tables unreadable on a phone? Fix them. Specific problems make results easier to see.
Now I generally describe the problem, GPT reads the project, changes files and runs checks, and we look at the live result.
Start with what doesn’t feel right to read
For a blog, readable articles matter most to me. Is the homepage easy to scan? Is body text too small? Are headings too heavy? Can a phone user read the tables? Ordinary details, but readers meet them first.
I tell GPT directly:
Adjust the article page’s font and size, and check mobile too. Let tables use the content width; keep horizontal scrolling when they’re too wide.
It finds the relevant pages and styles before changing them. “Optimize the UI” alone won’t necessarily produce something you like. Say what feels wrong, then open the result on desktop and phone. Adjust again if needed.
I handle PageSpeed reports similarly: give it the link, ask it to investigate, and compare the findings with the project. The report helps locate issues, but I still want to know whether loading improved and reading remained comfortable. A score is useful; people need a usable site.
Multilingual work turned out to involve more than translation
I added English, Spanish, Russian, Japanese and Arabic so more people could read the articles. Beyond the body, titles, summaries, categories, tags, menus and sharing text all needed attention. Arabic also needed right-to-left layout; swapping text alone would look odd.
Each language now has its own URL: /en/articles/…/ for English, /ja/articles/…/ for Japanese. Opening it gives you the corresponding text.
I had GPT check hreflang, x-default and canonical too. The names sound complicated, but the purpose is straightforward: tell search engines which URLs are language versions of the same article.
The latest check passed for 370 foreign-language pages and their Chinese counterparts. Batch checking saves me opening them one by one. Translation quality still needs spot checks, especially when a technical term can change a sentence’s meaning.
I’ve also asked: submitted already, so why no indexing?
Of course I want people to find the site. I asked about the Sitemap, Baidu indexing, and having GPT submit the whole site.
The easy mistake is treating a successful submission as successful indexing. I now check which step actually happened:
| Platform | How I submit |
|---|---|
| IndexNow | Public page URLs |
| Sitemap through the Search Console API | |
| Baidu | URL submission API within the site quota |
After the latest release at the time of writing, IndexNow accepted 438 site URLs and Google accepted the Sitemap. Baidu’s daily quota was exhausted, so remaining submissions had to wait.
That sounds good, but 438 accepted URLs doesn’t mean 438 indexed pages. Crawling and indexing still need checking in the search platforms. GPT can complete the submission; search engines decide what and when to index.
For ordinary blog posts, Google doesn’t offer a general per-page indexing-request API equivalent to IndexNow. I use its Sitemap API.
More articles made manual repetition less appealing
Writing is followed by translations, builds, page checks, uploads, cache refreshes and URL submissions. Then come the WeChat cover, layout, summary and original-article link.
A couple of posts are manageable manually. With repetition, I wanted a fixed process. GPT helped turn those steps into scripts. The next release uses the same workflow; logs show where something failed.
WeChat drafts now go through the API too. Supported fields—title, author, summary, cover and source link—are set together, then read back to verify them. We check for an existing draft before retrying: a network failure can otherwise leave duplicates.
I stop at the draft box. Before publishing publicly, I look again, especially at mobile tables, paragraphs and the cover.
The more I use it, the less I say “optimize everything”
I try to state three things: the problem, expected behavior and how to verify it.
Article tables overflow on mobile. Fix them, keep horizontal scrolling, and check Chinese and English pages. Explain the cause and verification.
Or:
Submit public pages to IndexNow and record the response. Keep failures pending. Don’t call submission success indexing success.
The wording doesn’t need to be fancy. It needs enough information.
I still check live pages after “done.” A local build doesn’t prove the live cache updated; a successful site release doesn’t prove search submission succeeded. We encountered Baidu quota limits and an IndexNow historical-state validation failure. An existing full-site submission script resolved the latter. Clear status and finishing the remaining work help more than a blanket “everything succeeded.”
The best part is not starting over every time
GPT saves scattered bits of time: finding styles, checking links, organizing translations and preparing drafts. Small tasks add up.
I can now hand it a concrete problem and examine the result. Saved workflows remain useful next time. What the site should cover, which articles deserve publishing and whether a page feels comfortable are still my decisions.
Start with one small task: a mobile table, an article’s language pages or a working draft-upload process. Get it working, then add the next piece. That’s how my blog has improved.