Ed Umbao
Ed's Lab Answer-Based SEO Article Planner

Public tool / Learning project

Answer-Based SEO Article Planner

I built this after noticing that article planning often starts with a search question but still needs more context before a useful draft can begin.

The tool asks for the question, audience, angle, example, and CTA, then turns those inputs into a structured planning prompt for an initial article review draft.

Open live tool ↗ View GitHub ↗
Status Working learning project

Public and functional, with small improvements still planned.

Built with HTML · CSS · JavaScript

Published through GitHub Pages with no backend or login system.

Focus SEO article planning

Turning a repeated content-planning step into a small browser tool.

Turn a repeated article-planning step into a browser tool.

I wanted to take a planning process I already use in content work and make it easier to repeat. Instead of starting with a broad topic, the tool begins with the question the article should answer.

From there, it asks for the main audience, the article angle, an example or scenario, and the call to action. Those inputs become a structured prompt that can be copied into a writing workflow.

01 Question

Start with the search question the article should answer.

02 Reader

Add the audience so the article has a clearer direction.

03 Direction

Add the angle, example, and CTA.

04 Prompt

Generate a copy-ready planning prompt for an initial draft.

A search question is useful, but it is not the whole brief.

In my SEO and content work, I still need to think about who the article is for, what angle makes sense, what example will make the explanation clearer, and what action should follow.

I built the planner so those decisions are visible before drafting. It also gave me a small project where I could practice front-end code, GitHub Pages, analytics, and documentation without needing a large software stack.

A static page was enough for the workflow.

The current version works without a backend, database, login system, or framework. Plain HTML, CSS, and JavaScript were enough to collect the inputs, generate the prompt, copy the result, and reset the form.

I also added Google Analytics event tracking to the Generate action, which gives me a better signal of tool use than page views alone.

Public tool

The planner is published through GitHub Pages and can be used without an account.

Simple stack

The implementation stays small because the current workflow does not need a backend.

Copy-ready output

The generated prompt can be moved into another writing workflow instead of trying to write the entire article inside the tool.

Usage signal

The Generate action is tracked so I can see whether people actually use the planner.

The first version worked, but the surrounding project felt unfinished.

The original README was only two lines long, so the repository did not explain why the tool existed, what it did, or what I learned. The code was more complete than the documentation made it look.

The first version also allowed a prompt to be generated with an empty article question, and the Copy action used a browser alert. I later added basic validation and inline feedback so the tool behaves more clearly without making the project much larger.

I also realized the sharing interface has more options than the core tool probably needs. That is a useful reminder that adding interface elements is not always the same as making a tool more useful.

Small tools can still teach me useful technical habits.

This project helped me see that a useful workflow tool does not need a large framework. It also made the relationship between code and documentation more obvious: a working tool is harder to understand if the repository does not explain the problem, scope, setup, and limitations.

I also learned to keep the project boundaries clear. This is an article-planning utility. It does not perform keyword research, retrieve SERP data, measure search volume, or generate a finished publish-ready article.

The tool came directly from my SEO and content workflow.

SEO planning

The workflow starts with the question an article should answer instead of treating the topic as the entire brief.

Content writing

Audience, angle, examples, and CTA are made explicit before the drafting step begins.

Technical writing

Improving the README became part of the project because the documentation needs to explain scope, setup, behavior, and limits.

Analytics

Event tracking gives me a simple way to distinguish actual Generate-button use from passive page visits.

Keep the tool focused instead of making it look bigger.

I do not want to add features simply to make the repository appear more advanced. The next changes should solve a real planning problem or make the current workflow clearer.

  1. Simplify the sharing interface if most of the current options are not useful.
  2. Add a clearer distinction between a weak article question and a stronger one.
  3. Keep the README and project notes updated as the tool changes.
  4. Use analytics to see whether people actually generate prompts before deciding what to add next.

The useful part of this project is not its size. It is that a repeated content-planning task became something I could build, test, document, and improve.

Open the tool ↗ View source on GitHub ↗