WordRanger started as a fairly simple idea: build a focused word-finding site, add useful supporting articles, and keep the whole project small enough for one person to understand and maintain.
The website itself was the easy part. The learning curve appeared after the first version worked.
That distinction matters because “build a website with AI” can sound as though the hard work ends when the page appears in a browser. In practice, AI made it possible to build without a traditional software-development background, but publishing and operating the site introduced a second set of skills: GitHub, deployment, automation, Search Console, structured data, canonicals, sitemaps, and troubleshooting.
What WordRanger was meant to do
WordRanger is a focused word tool with supporting content. That made it a good beginner project because the purpose was easy to describe and the site did not need accounts, payments, a database, or a complex content-management system.
A small static site also has fewer moving parts than many traditional websites. The browser can load ordinary HTML, CSS and JavaScript files directly, while a service such as Cloudflare Pages handles hosting and deployment.
That simplicity is real. It is also incomplete. Once the site needed regular article publishing and search visibility, operations became more important.
What was easier than expected
1. Building the first useful version
AI could generate and revise HTML, CSS and JavaScript, explain unfamiliar code, and help turn a plain idea into a working site. Instead of learning an entire programming language before starting, I could work toward one concrete result and ask questions as problems appeared.
2. Making visual changes
Changing button text, spacing, navigation or article layout was usually a small edit. The useful part was not just getting replacement code. AI could also explain where the styling lived and why a particular change affected the page.
3. Static hosting
Publishing a static site on Cloudflare Pages was much simpler than managing a traditional server. Once the repository and deployment were connected correctly, normal site updates could follow the same version-controlled path.
Where the learning curve actually appeared
| Area | What I had to learn |
|---|---|
| GitHub | What a repository, main branch, commit and workflow actually mean in a live website project. |
| Deployment | Why changing a file in GitHub and seeing the new version online are related but separate events. |
| Scheduled publishing | How a dated article folder, GitHub Actions workflow and production deploy need to work together. |
| Search | Why submitting a sitemap does not guarantee indexing and why Search Console statuses require interpretation. |
| Technical SEO | How canonical URLs, structured data, titles, internal links and sitemap entries help describe the site consistently. |
The scheduled-publishing problem was a useful failure
One of the most instructive parts of the WordRanger build was article scheduling. The idea sounded straightforward: place an article in a dated folder, let GitHub Actions check the date, move the file into the public blog folder, and deploy the site.
Then a scheduled run did not happen when expected.
Running the workflow manually helped separate two questions: did the publishing logic work, and did the scheduled trigger run? Those are not the same problem. A workflow can work perfectly when started manually and still have a scheduling issue.
GitHub's own documentation warns that scheduled Actions can be delayed during periods of high load, especially around the beginning of an hour, and that under sufficiently high load some queued jobs may be dropped. Scheduled workflows also run from the default branch. That means a missing run is something to investigate, not immediate proof that the article or YAML is broken.
What AI did well
- Explaining unfamiliar systems. Terms such as workflow, cron, canonical and structured data became easier to understand when tied to a specific problem.
- Generating a first implementation. It was much faster to begin with a reasonable workflow or page and test it than to start from a blank file.
- Reading errors. A red GitHub Action or deployment error is less intimidating when the message can be translated into plain English.
- Making repetitive corrections. Once a pattern was understood, the same technical improvement could be applied consistently across articles.
What AI did not eliminate
- Testing the live result. Code that looks correct can still fail after deployment.
- Deciding whether a proposed fix makes sense. A technically valid change can still be the wrong product or SEO decision.
- Finding stale assumptions. Platform requirements, pricing and documentation change.
- Understanding the publishing chain. Repository, workflow, deployment, CDN cache and browser cache are separate places where a change can appear to “not work.”
- Learning enough to ask better questions. The process got easier as the vocabulary became familiar.
The search lesson: technical setup is necessary, but not the whole job
WordRanger also reinforced a basic indexing lesson. A sitemap can help Google discover URLs, but Google explicitly says that sitemap submission does not guarantee crawling, indexing or ranking. A new site may simply need time, and individual pages still need to be technically eligible and useful enough to justify indexing.
That led to a more complete audit process: technical SEO, search intent, query coverage, original usefulness, and a human-writing review. Fixing canonicals or structured data is worthwhile, but neither can turn a replaceable article into a distinctive one.
What I would do differently on the next small site
- Use GitHub from the beginning. Moving from local files to a repository later added an extra migration step.
- Set up one deployment path. I would decide early which branch represents production and how changes reach the host.
- Add the sitemap generator before the article library grows. Manual sitemap editing is easy to forget.
- Create an article template with canonical and structured-data fields already included.
- Test scheduled workflows manually before trusting the schedule. A manual dispatch is a useful check of the publishing logic.
- Keep the first site narrow. The manageable scope made it possible to troubleshoot without needing to understand an enormous codebase.
Would I use AI to build another site?
Yes, but with different expectations.
I would not describe the process as “AI builds the website for you.” A more accurate description is that AI can act as a technical collaborator that lets a motivated beginner do work that previously would have required much more coding experience.
The trade-off is that the beginner still becomes the operator. When the scheduler fails, Google does not index a page, or a deployment behaves differently than expected, somebody has to investigate. AI can help with that investigation, but the project still benefits from a human who understands the goal and checks the result.
References
- GitHub. Events that trigger workflows. GitHub Docs.
- GitHub. Getting started with Git. GitHub Docs.
- Google. Google Search crawling and indexing FAQ. Google Search Central.
- Google. Creating helpful, reliable, people-first content. Google Search Central.