I decided to get an automated Korean/English economic news blog running, and with Claude built the whole skeleton in a single day — source research, design, SEO structure, OAuth authentication, and even the automation architecture.
Step 1: Nailing down news and data sources
The first thing I got stuck on was "where do I even get the data." I went through aggregators like GDELT and Finnhub, then FRED, SEC EDGAR, the Bank of Korea's ECOS, and government policy briefing RSS feeds, checking commercial-use terms one by one. yfinance and FMP's free tiers turned out to be personal/non-commercial only, so those were out, and Korean news-agency RSS feeds had clauses banning AI training and commercial use, so I kept those for trend monitoring only. In the end I settled on official government/institutional APIs — FRED, SEC EDGAR, ECOS, Korea's Public Data Portal, and policy briefings.
Step 2: Verifying full automation was actually possible
I confirmed that the Blogger API, Instagram Graph API, and Threads API all officially support automated posting. Instagram needed a business account, but Blogger just needed OAuth. Rather than going fully hands-off from day one, I decided to start with a semi-automated setup where a human reviews each post right before it publishes.
Step 3: Designing a vintage-newspaper theme
I wanted a professional feel, so I went with an old-newspaper look — serif fonts, a cream-toned background, drop caps, a two-column layout. I sketched Korean and English mockups, got them approved, and then ported the design into actual Blogger XML theme code.
Step 4: Designing the multilingual SEO structure
Mixing Korean and English content under one URL confuses search engines about the page's language, so I decided to split the blog entirely — "one Google account, two blogs." With a single OAuth token I can control both blogs just by switching the blogId, which actually made the automation simpler, not more complicated.
Step 5: Checking AdSense risk up front
I learned that content built mostly around summarizing and translating news can run into AdSense's "scraped/reconstituted content" policy. So instead of just repackaging source material, the design builds in original commentary and a human review step before anything publishes. I also confirmed that even under one account, registering multiple blogs still means each site gets reviewed separately.
Step 6: Actually launching the blog and picking a domain
Free domains (.tk, .ml, etc.) turned out to hurt credibility because of their spam history, so I decided to start with a free blogspot.com address. I made the English blog the primary one, and left the Korean blog with search-engine visibility turned off until it has enough content. Along the way I learned that "blocking search engine visibility" and "making the blog fully private" are two completely different settings.
Step 7: Authenticating with Google Cloud and the Blogger API
I created a project in Google Cloud Console, enabled the Blogger API, and issued an OAuth client (desktop app). After confirming both blogs' blogIds with an auth script, I finished a script that safely posts test entries as drafts.
Step 8: Setting up Instagram and Threads accounts
I confirmed you can sign up for Instagram as a regular account first and switch to business later. Using the "Instagram API with Instagram Login" path let me connect the API without linking a Facebook Page, so I didn't need to create one. Threads auto-generates a profile as soon as you have an Instagram account, so no separate sign-up was needed there either.
Step 9: Settling on an automation architecture direction
I was worried that depending 100% on Claude would mean heavy token costs, but I worked out that separating orchestration (scheduling) from generation (summarizing/translating) logic sidesteps the problem. If the generation logic is written so the provider is swappable, moving to a local Ollama setup or an open-source orchestrator like n8n later won't require rebuilding the skeleton.
Step 10: Switching tools and handing off the session
Up to now I'd been working screenshot by screenshot, confirming each step. Starting with the next phase — the data-collection scripts — I decided to move to Claude Code instead. Cowork is strong for non-developer workflow automation, but for work like this, where I'm directly creating, running, and debugging files, Claude Code fit better. Since context doesn't automatically carry over between sessions, I wrote up all the decisions so far and the next steps in a CLAUDE.md file to hand off to the next session.
Trouble Shooting
| Symptom | Cause | Fix |
|---|---|---|
| Language-switch link displayed incorrectly based on blog.locale | The locale value follows the admin interface language, not the actual content language | Switched to hardcoding the current language per blog |
| Couldn't find "v3" when searching for the Blogger API library | v2 was retired and the name was simplified to just "Blogger API" | Confirmed that the unversioned "Blogger API" is v3, and proceeded |
| 403 access_denied during authentication | The OAuth consent screen was in testing mode and my own account wasn't registered as a tester | Added my email as a test user under the Audience menu and retried |
| Mistakenly thought the Korean blog wasn't set to private | "Blocking search engine exposure" and "making the blog fully private" are separate settings | Clarified the distinction; noted that blocking exposure alone is enough for now |
Reflections / Next steps
I was able to get through source validation, design, SEO structure, authentication, and architecture decisions in a single day because I moved each step straight into code and documentation as I went. Next session, I'll wire up the FRED/GDELT data-collection scripts and the summarization/translation logic in Claude Code, and move on to actually creating the Instagram and Threads accounts.
Comments
Post a Comment