Going live: testing, hosting and what to learn next

Your portfolio works on your computer, and that is a real achievement. But a website only counts when other people can visit it. In this final lesson you will run a last round of checks, learn how publishing works, understand domain names and hosting, find out how to maintain a site, and map out where to go next in your web development journey.

Step 1: the final check before publishing

Professionals call this acceptance testing: a checklist that you run through before every release. Use this one for your portfolio.

Content

• Spelling and grammar are checked; read the text aloud once.
• Name, contact details and dates are correct.
• No placeholder text remains.
• You have the right to use every image and text.

Code

• The HTML validates with no errors in the W3C Nu HTML Checker.
• Every page has a unique title and meta description, and a lang attribute.
• Every image has a meaningful alt (or an empty one if decorative) and dimensions.
• No console errors and no red 404 entries in the Network panel.
• All links work, including anchors and the links between pages.

Design and responsive

• The layout holds from a narrow phone width to a wide desktop, with no horizontal scrolling.
• Text remains readable when you enlarge the browser’s text size.
• Buttons and links are comfortable to tap.

Accessibility and performance

• The whole site works with the keyboard alone, and focus is always visible.
• Text and interface colors meet the contrast targets.
• Images are resized and compressed; below-the-fold images are lazy-loaded.

Test in at least two different browsers and, if you can, on a real phone. Small differences show up in practice, and finding them yourself is much better than having a visitor find them.

How publishing works

Publishing means putting your files on a server connected to the Internet, so that anyone can request them, exactly as in the first lesson. You need two things: hosting (space on a server) and, optionally, a domain name (an address that is easy to remember).

Static hosting

Your portfolio is a static site: a folder of files. This is the easiest and cheapest type of site to host, because the server only has to hand out files, without running any program. Options fall into a few broad categories:

• Static site hosting services: you upload your folder (or connect a code repository) and the service publishes it, often with HTTPS included and a free tier for small personal sites.
• Traditional web hosting: a provider gives you space on a server and a way to upload files.
• Code repository hosting with a publishing feature: some platforms that store your code can also serve a static site directly from it.
• Your own server: possible, but it requires system administration skills and ongoing maintenance, so it is not recommended for a first site.

When comparing, look at: HTTPS support, the ease of updating, limits on storage or traffic, where the data is stored, how clearly the pricing is explained, and what happens if you want to leave (you should always be able to take your files with you). Read the terms, and prefer providers that are transparent.

Getting your files online

There are three common ways to transfer your site to a host.

1. Web interface upload. Many hosts let you drag and drop your folder or a compressed archive in the browser. Simple and perfect for a first time.
2. FTP or SFTP. A file transfer program connects to the server with the details provided by your host (server name, user name, password) and copies your files into a public folder, often called something like public_html or www. Prefer the secure version, SFTP, when it is offered.
3. Git and automatic deployment. You keep your project in a version-controlled repository, and the host publishes it each time you save changes to it. This is the workflow professionals use, and learning Git pays off well beyond websites.

Whatever the method, remember the essentials: upload the contents of the portfolio folder so that index.html sits at the root of the public folder, keep the same folder structure, and do not upload private files such as your BRIEF.txt or any password.

After uploading: verify

1. Open the public address in a private browsing window and in a different device.
2. Check that the address starts with https and the browser shows no security warning.
3. Click through all links and anchors, and check the images.
4. Remember paths are case-sensitive on many servers: if an image works locally but not online, check the capitalization first.
5. Update the absolute URLs in your Open Graph tags with your real address, and test sharing the link in a message.

Domain names

Hosting services usually give you a free address on their own domain. That is fine to start, but a domain name of your own, such as mayacarter.example, looks more professional and stays yours even if you change host. The process:

1. Choose a short, memorable, easy-to-spell name, and check that it is available.
2. Register it with an accredited registrar, usually for an annual fee. Compare prices for renewal as well as the first year.
3. Point it to your host by editing the DNS records, following your host’s instructions. Remember from the first lesson that the DNS translates the name into a server address. Changes can take some time to spread.

Keep the account details for your domain safe, enable the extra security options offered, and note the renewal date: an expired domain stops working.

Receiving messages from your form

As explained earlier, an HTML form needs something to receive the data. For a static site, the most common solutions are a form-handling service that gives you an address to place in the action attribute, or a small server-side script that you host yourself. Either way:

• read the privacy terms, since you will be collecting visitors’ personal data;
• tell visitors in plain words how you will use their data, in line with the rules that apply in your country;
• keep spam in mind and prefer solutions that offer some protection;
• if you prefer to stay simple, display your email address as a plain link instead.

For a site with an audience in a particular country, you may also have to publish legal notices or a privacy statement. These obligations vary, so check the official guidance of the authority in your country.

Maintaining your site

A site is never quite finished. A few habits keep it healthy.

• Keep a backup of your folder: on another disk, in cloud storage, or in a repository.
• Update the content: add new projects, remove obsolete ones, keep contact details current.
• Test links now and then: external sites change addresses.
• Re-check after changes: validate, test on mobile, run the keyboard test.
• Renew your domain and review your hosting plan.
• Watch your performance: when you add images, optimize them first.

Work on a copy when making big changes, preview locally, and only publish when you are happy. Never edit the live site directly without a backup.

Where to go next

You have built a complete, accessible, responsive website from scratch. Here is a sensible path to keep growing, in rough order.

1. Practice and polish. Rebuild a site you admire, add a second page, or a case-study page for each project. Repetition builds fluency faster than any theory.
2. JavaScript. The language of interactivity: a mobile menu, a lightbox for images, form checks, dynamic content. It is the natural next step and opens the door to the whole field of web applications. Start with the fundamentals: variables, functions, the DOM and events.
3. Git and version control. Track your changes, undo mistakes, collaborate and publish automatically. It is an essential professional skill and works hand in hand with static hosting.
4. Deeper CSS. Explore modern features such as container queries, advanced Grid layouts, CSS functions and animations. The MDN documentation is the best reference.
5. Accessibility. Go deeper with the W3C Web Accessibility Initiative resources and WCAG. It is a differentiating skill that employers and clients value.
6. Tools and frameworks. Once you are comfortable with the fundamentals, you can explore build tools, static site generators and front-end frameworks. Learn them after the basics, because they are all built on HTML, CSS and JavaScript, and you will understand them far better.
7. Servers and data. If you want dynamic sites with accounts and databases, look into back-end development.

Advice for learning on your own

• Build small projects regularly, rather than only reading.
• When stuck, read the error, search precisely, and consult the official documentation such as MDN first.
• Read other people’s code with the developer tools, and ask what each part does.
• Keep a notes file of snippets and solutions you found.
• Be patient: confusion is a normal part of learning, not a sign of failure. Come back after a break and the problem often looks simpler.
• Share your work and ask for feedback, particularly on accessibility and clarity.

Your turn

1. Run the checklist above on your portfolio, and fix every problem you find.
2. Choose a host (read at least two sets of terms), and publish your site.
3. Open the live address on your phone and ask a friend to test it too, without telling them where to click.
4. Update the Open Graph URLs and test a shared link.
5. Write down a three-item learning plan for the next three months.

See a solution

There is no single right answer, but a solid result looks like this:

• A live site reachable over HTTPS, with all links, images and the favicon working.
• A validated page with no errors, and a keyboard-only test passed.
• A short plan, for example: (1) learn the JavaScript basics by adding a working mobile menu; (2) learn the basics of Git and publish through a repository; (3) add a case-study page for each project, with accessibility checks.

If a friend gets lost on your site, that is valuable feedback: note where and why, then improve it. Feedback from a real visitor beats any checklist.