AI Website Prompts for Beginners: From Brief to Tested Page
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.
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.
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
- Read every sentence. Remove invented claims, dates and testimonials. Check that visible promises match the available service.
- Follow every link. Verify the destination, including privacy and contact links. Check that the browser back button behaves sensibly.
- Use a keyboard. Move through interactive controls and confirm focus is visible and controls can be activated.
- Check a phone-sized view. Look for clipped text, oversized media and overlays hiding the main action.
- Test the intended interaction. Use an authorized test environment for forms or purchases; do not create real transactions as casual tests.
- 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.