AI Website Prompts for Beginners: From Brief to Tested Page

By Hamraah Foundation · Published 2026-09-25 · Updated 2026-10-25 · AI School

A useful AI website prompt describes the visitor, the page’s purpose, the content available, the required interactions and the checks the result must pass. Start with a small working page, review it, and request focused changes. Asking only for a “beautiful 3D website” leaves the system to guess what people should read or do.

This guide contains original practice prompts for a fictional community reading club. They are illustrative briefs, not excerpts from Hamraah’s paid toolkit and not claims that an AI-generated website has been tested. You can adapt them to a student portfolio or another small project without using real children’s information.

What should an AI website prompt include?

Give the assistant a clear specification before requesting code. A brief should separate facts you supply from decisions you want help making. If an event date, organization claim or image permission is unknown, require a clearly marked draft placeholder rather than an invented answer.

• Audience: who will use the page, on what device, and for what purpose?
• Goal: the single main action, such as reading a schedule or opening an enquiry form.
• Content: approved headings, text, images and links.
• Constraints: existing framework, visual identity and features to preserve.
• Acceptance checks: how you will determine whether the output works.

This is a practical way to reduce ambiguity, not a guarantee of correct code. Meta’s prompting guidance likewise emphasizes specific instructions and context. You remain responsible for checking the result.

Make a website content inventory before requesting a build

A content inventory is a list of the material your page needs and what is ready to use. For a small AI-assisted website, it can be a short document rather than a large spreadsheet. The University at Buffalo's content audit guidance offers a structured approach to reviewing existing website content. The original exercise below adapts that planning task to a beginner's single-page brief.

• Page section: where the material belongs and the visitor question it answers.
• Approved content: the exact text or asset you can provide.
• Source or owner: who can confirm the information and when it was checked.
• Status: ready, needs confirmation or excluded from the draft.
• Next action: the specific decision required before publication.

For the fictional reading club, “weekly reading discussions” is supplied content. A meeting address is missing, an enquiry email has not been approved, and no member quotation has been provided. Those are three unresolved inputs, not three invitations for the AI to invent realistic details. A decorative image also needs an approved asset and a decision about whether it adds useful information.

Review this content inventory before generating the page.
For each item, return: section, supplied fact, missing input and next action.
Use only my approved text and assets.
Do not turn an unknown into a plausible address, testimonial or statistic.
Keep draft placeholders out of publish-ready copy.
If the main enquiry route is missing, flag the page as not ready to publish.
Inventory: [paste the reviewed list].

Compare the response with your list line by line. If the model adds a claim, remove it or obtain evidence before including it. If it omits an important question, revise the brief before asking for styling. This check gives you a concrete way to review the output without needing to understand every line of code.

Save the approved inventory with the project. When someone later changes the schedule or contact route, update the source note as well as the visible page. The website handover checklist helps the next editor find those records. Keeping the facts in one reviewed list also makes later prompt revisions easier to compare.

Prompt 1: Turn an idea into a page brief

Plan one landing page for a fictional community reading club.
Audience: adults looking for a local reading activity.
Goal: understand the activity and find the enquiry contact.
Use only the facts below; mark missing facts as draft placeholders.
Facts: weekly reading discussions; contact details are not yet supplied.
Propose the page sections and explain the purpose of each.
Do not invent attendance numbers, testimonials, dates or partnerships.
Do not write code yet. List the decisions I need to make first.

Review the plan for unnecessary sections. A small page may need only a heading, a short description, practical details and a contact route. Decide the content first: changing a vague brief after a complex animation has been built creates avoidable work.

Prompt 2: Build the simplest usable version

Implement the approved reading-club page using the existing project stack.
Keep the current site header, footer, colours and typography.
Use semantic HTML and one descriptive H1.
Use actual anchor links for navigation.
Make the layout readable on narrow screens without horizontal scrolling.
The contact address is still missing: show a draft note, not a working form.
Do not add analytics, new packages or external services without explaining why.
List the files changed and checks I should run.

The instruction about the contact address prevents a convincing but non-functional submission experience. Before publication, replace draft notes with approved content or remove the incomplete feature. A button that displays “success” without delivering a message is not an enquiry system.

W3C’s page structure tutorial explains the role of headings and meaningful regions. Its forms tutorial covers labels, instructions and feedback. Use those references to review the output, rather than treating a prompt’s accessibility request as proof of accessibility.

Prompt 3: Add an optional visual effect with boundaries

Add a restrained decorative depth effect to the approved hero.
Keep the heading, explanation and enquiry link as normal HTML.
The decoration must not block reading, keyboard access or scrolling.
Respect reduced-motion preferences and provide a static fallback.
Explain any added dependency and its effect on loading.
If the decoration fails, the content and navigation must still work.

For a beginner, CSS depth or a static illustration may be enough. A full 3D scene introduces more decisions about assets, rendering and device performance. Ask the assistant to justify the complexity against the page goal. Avoid choosing an effect simply because the generator can produce it.

Test the fallback before keeping a 3D effect

A decorative scene should be optional to the visitor's task. For the fictional reading-club page, write down what must remain available: the club description, practical details and approved enquiry link. If the decoration cannot load, those elements should still make sense in ordinary HTML.

Two different cases need attention. A visitor may prefer less motion, or the rendering feature may fail. MDN's reduced-motion documentation explains how a page can respond to the user's motion preference. That preference is not a general test of whether a 3D scene can render, so request separate handling for failure.

Extend this private practice page with a decorative scene only after its plain version works. Preserve all essential text and links outside the scene. Provide a static version for reduced-motion preferences and a usable fallback if the scene fails. Explain how I can deliberately select the fallback in a local test without changing the visitor's device settings. Report what was actually tested and what still needs manual review. Do not claim accessibility compliance or invent test results.

This is an original practice brief, not a tested code sample or an excerpt from the paid toolkit. Use it to obtain an implementation and a test procedure you can inspect. If the tool cannot explain how the fallback is activated, resolve that before publishing the effect.

1. Open the plain version and confirm the main text and enquiry link work.
2. Use the implementation's documented local test procedure to show the fallback. Confirm the same content remains readable and the link retains its destination.
3. Review the reduced-motion version separately. Check that decorative movement stops or is appropriately reduced rather than merely becoming slower without explanation.
4. Use the keyboard and a narrow layout in each version. Record any hidden controls, obstructing overlays or layout shifts that prevent the task.

Keep a short result for each case: expected behaviour, observed behaviour and unresolved issue. An attractive normal version does not cancel a failed fallback check. If the effect adds complexity you cannot inspect or maintain, keep the plain version and continue learning with the portfolio practice exercise.

How to ask for a useful revision

Describe the observed problem, where it occurs, what you expected and what should stay unchanged. “Make it better” provides little evidence. “At a narrow phone width, the primary link overlaps the description; keep the desktop spacing and fix the mobile wrapping” gives a specific task to verify.

Change one concern at a time where possible. Save a working version before asking for a broad revision. After each change, repeat the checks affected by that change: a new menu needs navigation checks; a new image needs loading and layout checks; a revised form needs validation and delivery checks.

A practical review before publishing

1. Read every sentence. Remove invented claims, dates and testimonials. Check that visible promises match the available service.
2. Follow every link. Verify the destination, including privacy and contact links. Check that the browser back button behaves sensibly.
3. Use a keyboard. Move through interactive controls and confirm focus is visible and controls can be activated.
4. Check a phone-sized view. Look for clipped text, oversized media and overlays hiding the main action.
5. Test the intended interaction. Use an authorized test environment for forms or purchases; do not create real transactions as casual tests.
6. Inspect the initial page. Confirm its title, description, heading and substantive content are available, then run the project’s build and relevant checks.

Record what you tested and what remains untested. “Looks right on my screen” is narrower than “works for visitors.” An AI assistant can help prepare a test list, but a generated checklist is not evidence that the checks passed.

Worked exercise: test a generated enquiry link

Suppose the fictional reading-club page now has an approved email address. The intended action is to open an email draft. Start by writing the expected result: the link has a meaningful label, keyboard users can reach it, and its destination contains the approved address. Opening a draft does not prove a message was sent or received.

Review the enquiry link on this practice page.
Expected behavior: open an email draft to the approved address.
Check the actual link destination, accessible name and keyboard focus.
Report each check as passed, failed or not tested, with evidence.
Do not send a message. Do not treat a visual button as proof of delivery.
If you cannot inspect the browser, give me manual steps instead of claiming a pass.

Run the page and check the result yourself. If the button has no destination, request a real link. If it opens the wrong address, supply the correction without changing the rest of the page. If your device has no email application configured, record that limitation and provide a visible approved address visitors can copy. Keep test addresses inside a private draft until the real destination is confirmed.

A useful bug report says: “The enquiry control is visible, but pressing Tab never reaches it. I expected to focus and activate it from the keyboard.” Ask for the smallest correction, then repeat that check and confirm the destination still works. This links a revision to an observed failure instead of asking the assistant to redesign the whole page.

Use W3C's Easy Checks to expand the review to headings, text alternatives and other basic accessibility issues. W3C explicitly describes these as preliminary checks: passing them does not establish full accessibility. Keep a note of unresolved issues before deciding whether a page is ready to publish.

Before buying additional resources, use our AI website prompt toolkit selection guide to compare samples, project fit and what the purchase includes.

Where Hamraah AI School fits

Hamraah AI School presents a website-building prompt toolkit. Review the current page’s previews and contents to decide whether it suits your project. This guide does not describe it as an age-specific children’s course or promise certification, instructor support or employment outcomes.

If you are choosing resources for a school or community program, start with the learners’ needs, supervision and access to suitable devices. Our education project brief guide explains how to separate a proposed activity from the outcome you want to assess. You can also read about Hamraah Foundation for organizational context.

Start with one page you can explain

Choose a small project, write its brief and build a version you can inspect. Add complexity only when it improves the visitor’s experience. To explore more website-planning resources, review the AI School toolkit and compare its contents with the decisions your project requires.

Turn an accessibility concern into a reproducible repair prompt

Do not accept an AI tool's statement that a page is accessible as a test result. Describe an interaction you actually tried, the expected behaviour and what happened instead. The W3C Easy Checks are a starting point for manual review, not a complete accessibility evaluation.

For this fictional reading-club exercise, open the site and use the keyboard to reach its main navigation and enquiry controls. Notice whether the focused control is visible and whether you can leave each component. Increase text size and inspect a narrow layout for hidden instructions or controls. Record the specific page and control involved instead of reporting only that the site feels difficult to use.

Review this observed problem: [page and control]. Steps: [what I did]. Expected: [the usable behaviour]. Actual: [what occurred]. Explain the likely cause and propose the smallest repair. Preserve the approved content and existing working interactions. Do not claim compliance from this repair alone. Give me the same steps to repeat after the change and identify any checks that still need human review.

As an original example, suppose a fictional menu opens but keyboard focus disappears behind it. Ask the tool to explain the focus behaviour before making a change. Repeat the opening, navigation and closing sequence afterward. Then check another unaffected control to make sure the repair did not break it. A generated code patch is only a proposal until the relevant behaviour has been observed.

Keep a short issue record with the page, steps, expected result, actual result and retest outcome. Mark untested items as untested. If your project is a personal showcase, the student portfolio prompt exercise adds checks for truthful project evidence and ownership alongside usability.

Explore Hamraah AI School