How to Put Your Own Domain on a Consulting Portfolio Website

September 22, 2026 · 11 min read

By Ahmed HusseinFounder of Seera · Software Development Engineer at AmazonReviewed by Mazen Ahmed

Quick answer: Pointing your own domain at a consulting portfolio is a three-move sequence, not a purchase. Buy the domain from an independent registrar, add one DNS record for the www hostname (a CNAME to the hostname the builder gives you) and one for the apex (an ALIAS/ANAME if available, otherwise A records to the platform's published IPs), then wait for the certificate authority to issue HTTPS — usually another few minutes after the DNS resolves. If you want to see what a paid tier actually costs before you invest the effort, compare the portfolio builders that support custom domains under $10/mo; if you want the raw domain-pricing question isolated from hosting, the how much a portfolio website costs guide breaks it out.

Key Takeaways

Every custom-domain connect that goes wrong goes wrong in the same three places: the wrong record type on the apex, the TTL that was never lowered, and the mail records that were casually replaced along with the web records. Everything in this guide is aimed at those three failure modes.

Move Where it happens How long it takes
Buy the domain An independent registrar (Cloudflare, Porkbun, Namecheap) 2 minutes
Add the target hostname or IPs to your builder The portfolio builder's dashboard → Custom domain 1 minute
Add the www CNAME + apex ALIAS / A records Your registrar's DNS panel — not the builder's 3 minutes
Wait for DNS to propagate at your resolver Runs on the TTL you set (or inherited) 5–60 minutes typical
Wait for HTTPS certificate to issue Handled by the builder + Let's Encrypt or similar 1–15 minutes after DNS resolves
Verify with dig or an online DNS checker Any resolver — not a browser tab, which lies 30 seconds

Table of Contents

Why Your Address Earns the Trust the Copy Asks For

Everything a consulting portfolio says about your judgement, taste, and standards is refereed by a two-second glance at the address bar before a prospect even reads the first line. A hostname on a platform's shared subdomain reads as "trial account"; a bare custom domain reads as "practice." The words on the page can be identical either way — the difference is the box they arrive in, and that box is set by four DNS records you spend fifteen minutes on once and never think about again.

Consultant Amani puts it more directly in a widely shared LinkedIn post about developer portfolios: Small detail, big difference. Swapping a project.vercel.app link for your own domain instantly changes how people perceive what you've built. That effect is not vanity. A domain you own is portable, indexable, memorable, and unspoiled by the parent brand of whatever tool happens to render the HTML this year. Every one of those properties is a small reduction in the amount of work a prospect has to do to trust you.

This guide is the operational half of that argument — how to actually get yourname.com resolving to the page you already built. If you haven't chosen a builder yet, the custom-domain-under-$10 roundup is the buyer's-guide companion; this post assumes the page exists and you just need to point the name at it.

Buy the Domain Before You Buy the Builder

Almost every portfolio platform offers to sell you the domain during checkout. Almost every one of those offers looks convenient and is, quietly, the wrong move. When the builder resells the domain, it lands in a bulk registrar account keyed to the platform's business, not to you — and the day you want to move to a different builder, transferring it out becomes a support-ticket process rather than a login. In a few cases the domain is bundled as a promotional item that lapses back to the vendor if you cancel the subscription. The domain is the one part of the stack you actually want to own, so buy it separately from the tool that renders the site.

Three independent registrars cover the practical cases:

Any of the three will do. What matters is that the domain is registered under your email address, that you can see it in a dashboard you log into directly, and that the "get transfer code" button is one click away without a chat window. That is the guarantee that this domain is yours, and it is the reason every step below happens at the registrar rather than inside the builder.

The Four Inputs to Gather Before You Touch DNS

DNS panels look intimidating because they list eight record types and no context. In practice a portfolio connect uses at most three, and you already have the values before you start; you just need them in one place.

  1. Your exact domain. Write it out both ways — yourname.com and www.yourname.com — because the DNS records treat them as separate hosts and you will need to add one for each.
  2. The target hostname the platform gave you for the www record. Every builder publishes one; it is typically buried in the Custom Domain section of the dashboard and looks like portfolios.builder.com or sites.builder.net. Copy it including the trailing dot if the panel shows one.
  3. The IP addresses the platform publishes for apex connections. Only relevant if your registrar does not support ALIAS/ANAME records. Usually a small set of four IPv4 addresses (and sometimes IPv6 equivalents). GitHub Pages, for instance, publishes four IPs for this purpose; other platforms publish their own.
  4. Your current MX and TXT records, if you already receive email at this domain. Screenshot them or copy them into a text file now, before you change anything, so that if the DNS panel accidentally offers to replace the zone you can restore them from memory rather than an outage.

Those four inputs — domain, hostname target, IP fallback set, existing mail records — are the entire universe of what you need. Everything else in the DNS panel is unrelated to this task and should be left untouched.

Step-by-Step: Connect the www Hostname

The www.yourname.com version of the site is the easy half, because CNAME records exist for exactly this purpose. A CNAME is a host-to-host alias: it tells any resolver asking about www.yourname.com to go look up whatever hostname the platform gave you, and then use whatever address that resolves to. You never have to hard-code an IP address, and the platform can rotate its infrastructure freely underneath.

The steps at almost every registrar are the same shape:

  1. Log into the registrar, open the DNS panel for yourname.com, and find the section for adding a record.
  2. Add a record with these values: Type CNAME, Name / Host www, Value / Target the hostname the builder published (for example, portfolios.builder.com), TTL 300 seconds if you can set it, otherwise leave the default.
  3. Save. Most panels apply the change within a few seconds; the record is now live on the authoritative nameservers.
  4. In a fresh terminal, run dig +short www.yourname.com (or use an online DNS checker if you don't have a terminal). You should see the target hostname you entered, followed by its own resolution to an IP. If you see the target hostname, the CNAME is working; the rest is caching.

Two small traps at this stage. First, some registrars require the Name field to be just www, others require the full www.yourname.com, and a few auto-complete either way — read the field's placeholder text carefully. Second, if the panel silently strips a trailing dot from your target hostname and the resolution then fails, add the trailing dot back explicitly (portfolios.builder.com.). The dot is DNS syntax for "this is a fully-qualified name; do not append the current zone to it."

The Apex Trap: Connecting yourname.com Itself

Now the awkward half. Most consulting portfolios want to be reachable at the bare domain — yourname.com, not just www.yourname.com — and the DNS specification does not allow a CNAME record on the apex of a zone. That is not a policy anyone can lift; it is a rule about how record types interact, and if you add a naked apex CNAME it will either be rejected by the panel or silently break the mail records that share the apex.

Two paths around it:

Path 1: ALIAS / ANAME (preferred, if your registrar supports it)

ALIAS and ANAME are registrar-side pseudo-records that behave like a CNAME on the apex but resolve to the target's IP at query time — a pattern Cloudflare documents as "CNAME flattening," where the resolver returns A/AAAA records to the client and the alias is invisible to them. If you see any of those names in your registrar's dropdown, use them:

  1. Add a record with Type ALIAS (or ANAME), Name / Host @ or blank (both mean "the apex"), Value / Target the same hostname you used in the CNAME above, TTL 300 seconds.
  2. Save. Verify with dig +short yourname.com; you should see an IP address, not the target hostname, because the flattening happens on the resolver side.

Cloudflare, DNSimple, and several other DNS providers offer this record type. If the dropdown shows it, prefer it — it is the cleanest option and the one that keeps working when the builder rotates its backing IPs.

Path 2: A records to the platform's published IPs (fallback)

If your registrar's DNS panel lacks ALIAS/ANAME (Namecheap's basic DNS is the common example, though most vendors have added it in recent years), fall back to plain A records:

  1. Read the platform's docs to find the exact IPv4 addresses they publish for apex connections. Do not guess and do not copy from a blog post; the IPs change and the platform's docs are the authoritative source.
  2. Add one A record per IP, all with Name / Host @ and each with its own Value. If the platform also publishes IPv6 addresses, add matching AAAA records the same way.
  3. Save. Verify with dig +short yourname.com A and confirm the response matches the platform's published list exactly.

The tradeoff is that if the platform ever changes its apex IPs — rare, but it happens during infrastructure migrations — you will need to update the A records manually. That is why ALIAS is preferred. On any modern portfolio builder, both paths deliver the same user experience; the difference is entirely on your side of the stack.

Propagation, TTLs, and Why the Browser Lies

Every guide waves at "DNS propagation can take up to 48 hours" and then leaves you refreshing the tab for the rest of the day. The real story is more useful than that.

Two clocks are running. The first is the registrar publishing your new record to its authoritative nameservers, which is essentially instant — call it seconds. The second is every recursive resolver on the internet honoring the previous cached answer until its time-to-live (TTL) expires. TTLs are a value stamped onto every DNS response, and they default to anywhere from 300 seconds to 24 hours depending on the record and the resolver. When you switch a record, the old value keeps being served from cache to any user whose resolver last asked before the change, right up until that resolver's clock ticks past the old TTL.

The practical implication is the opposite of what the "48 hours" advice suggests: the internet is not slow, the cache you set is. Lower the TTL on the record to 300 seconds a day before you make the switch, wait for the old TTL window to elapse, then change the target. The transition itself will land in under ten minutes on the paths that matter.

Also: the browser lies. Your operating system caches DNS responses, and so does your browser on top of that, so a refresh in the same tab you originally loaded on the old value will keep returning the old answer long after the internet at large has moved on. To check whether propagation is done, use dig, or an online tool that queries resolvers around the world, or open the URL in a browser you have never visited it in. Do not use the tab you were staring at while making the change.

HTTPS: The Second Handshake That Finishes the Job

DNS getting your name to the right server is only half the connection. The other half is HTTPS — the browser refusing to load anything at your domain until the platform has served a valid TLS certificate for it. That certificate is issued by a certificate authority (Let's Encrypt is the free default that most builders use), and issuance is a separate step that only starts once DNS resolves correctly.

The typical modern flow, automated by every serious portfolio platform, is:

  1. You add the DNS record.
  2. The platform's provisioning system notices, within a minute or two, that your domain now resolves to it.
  3. It kicks off an ACME challenge with the certificate authority — usually the HTTP-01 challenge, which places a short verification file at a well-known URL on your domain, and the CA fetches it to confirm you actually control the name.
  4. The CA issues a certificate for your domain. The platform installs it and terminates HTTPS on your behalf.

What this means for you: the browser warning ("your connection is not private") that appears the moment DNS is working is not a bug. It is the correct behaviour of a system that has not yet had time to complete step four. Wait ten minutes, hard-refresh, and check the platform's dashboard for a certificate-status indicator. If it still hasn't issued after fifteen or twenty minutes, it usually means DNS is inconsistent — the CA sees one thing, your browser sees another — and the fix is a resolver check, not a support ticket. Certificates auto-renew every ninety days on Let's Encrypt without any action from you.

Don't Break Your Email While Connecting Your Site

This is the mistake that turns a fifteen-minute task into a day of missed replies. Consulting portfolios often live on the same domain as your working email — you@yourname.com. Web traffic and mail travel over completely separate DNS record types: web on A / CNAME / ALIAS, mail on MX (and TXT for authentication like SPF, DKIM, and DMARC). Editing one does not touch the other, unless you replace the entire zone.

Two things replace the entire zone by accident:

The safer default is to keep the registrar as the nameserver, add only the CNAME and ALIAS/A records you need, and leave every MX and TXT record untouched. If email breaks anyway, the fix is to restore whatever MX record your provider (Google Workspace, Fastmail, Zoho, whoever) documents in their onboarding page — those records are stable across years and the provider's help center has them within one click.

Five-Minute Troubleshooting Sequence When It Isn't Working

If the domain does not load correctly after fifteen minutes, do not start guessing. Run this sequence, in order, and stop at the first step that shows the wrong answer.

  1. Check that the record actually saved. Refresh the registrar's DNS panel and confirm the CNAME (or ALIAS / A records) are present with the values you intended. Registrar UIs occasionally silently reject a save if there's a conflict; the record must be visible in the list.
  2. Check the authoritative answer, not the cached one. Run dig +short www.yourname.com @1.1.1.1 from a terminal (or use a browser-based DNS checker set to Cloudflare's 1.1.1.1 resolver). This bypasses your local resolver's cache. If the value is correct here but wrong in your browser, the problem is caching and you just need to wait or clear the local DNS cache.
  3. Confirm the target hostname is exactly what the builder specified. One trailing dot, one letter, one region-suffix wrong and the CNAME resolves to nothing. Copy-paste it fresh from the builder's dashboard rather than retyping.
  4. Look for the certificate status in the builder's dashboard. If DNS is correct and the browser still shows a warning, the certificate has not issued yet. Wait five more minutes, then check the dashboard. If it says "verification failed," the ACME challenge is being blocked — most often because the platform is receiving a different DNS answer than your browser is (a stale record on one resolver, a fresh one on another).
  5. Check whether a CAA record is blocking issuance. A rare but real cause: some registrars pre-populate a Certificate Authority Authorization (CAA) record that only permits one CA to issue certs for the domain. If your builder uses Let's Encrypt and the CAA only lists a different CA, issuance will fail silently. Either remove the CAA record or add an entry for letsencrypt.org.

If all five checks pass and the domain still isn't loading, it is a platform-side issue and worth a support ticket — but not before, because the answer will be one of the five above ninety-five percent of the time.

The domain part is worth doing right. The rest doesn't have to be.

Seera parses your resume into a publishable consulting page in about a minute, includes custom-domain support and automatic SSL on the Pro plan, and lets you keep the domain with your own registrar.

Start free → See Pro pricing

Worked Example: Connecting a Domain to a Seera Portfolio

To make the abstract concrete, here is the connect flow for a Seera portfolio. Every builder's dashboard looks a little different, but the shape of the steps generalizes.

  1. In your Seera dashboard, open the portfolio you want to publish on a custom domain and go to Settings → Custom Domain. Enter yourname.com (or the subdomain you want to use) and confirm. Seera displays the exact CNAME target and, if you're using the apex, the A-record IP(s) you'll need.
  2. At your registrar (Cloudflare, Porkbun, Namecheap, or whichever you chose), add a CNAME record with Host www pointing to the target hostname Seera displayed. If you're also using the apex, add an ALIAS record with Host @ to the same target, or fall back to A records with the IPs Seera published.
  3. Wait for propagation. Refresh Seera's Custom Domain page after a few minutes; it will show verification status ("Waiting on DNS → DNS resolved → Provisioning certificate → Live"). The full sequence usually completes inside ten minutes.
  4. Verify in a fresh browser (or a private window that has never loaded the domain). yourname.com should serve the portfolio over HTTPS with your name in the address bar and no security warning.

The whole thing is a one-time setup. From that point onward the domain simply is your portfolio's address, and everything you send — proposals, invoices, LinkedIn Featured links, email signatures — points at a URL you own. To go deeper on what belongs on the page once it's live, see the business consultant portfolio checklist or the annotated consultant portfolio example.

Frequently Asked Questions

Do I buy the domain from my portfolio builder or from somewhere else?

Buy it from an independent registrar and point it at the builder. That order — registrar first, builder second — keeps the domain in your name and moveable if you ever leave the platform. When the builder resells the domain to you, some vendors register it under a corporate account or lock transfers behind the subscription, and getting it back is a support ticket rather than a login. A neutral registrar like Cloudflare, Porkbun, or Namecheap lists the domain under your email, gives you the transfer authorization code on demand, and lets any platform in the world use it. The savings are usually five or ten dollars a year; the option to walk away is worth more than that.

What DNS record connects a domain to a portfolio website?

For the www version of the domain, a CNAME record pointing to the hostname your builder gives you (something like sites.example.com or portfolios.example.net). CNAMEs are host-to-host aliases and are the correct record for pointing a subdomain at a platform-managed target. For the apex — the bare yourname.com without www — a plain CNAME is not allowed by the DNS specification, so you either use your registrar's ALIAS or ANAME record if it offers one, or add A records pointing at the fixed IPv4 addresses the platform publishes. Most builders now support the apex through a flattening record; only fall back to A records if the flattening option is missing.

How long does DNS propagation actually take?

Usually minutes at the resolver you use, up to a couple of hours globally. Two clocks are running. The first is your registrar publishing the new record to its authoritative nameservers, which is near-instant. The second is every DNS resolver on the internet honoring the old cached value until its time-to-live expires — that TTL is set on the record itself and defaults to anywhere from five minutes to a day. Lower the TTL to three hundred seconds a day before you switch, wait for the old TTL to elapse, then make the change; the switch itself will land in under ten minutes on the paths that matter. The internet is not slow; the cache you set yesterday is.

Why is my domain showing a security warning after I connect it?

Because HTTPS is a two-step handshake and only one of them is DNS. Pointing the record makes the domain resolve to the platform; issuing the certificate is a separate step where the certificate authority verifies you actually control that domain, usually by fetching a well-known file on the same hostname. Most builders start that verification the moment the DNS record resolves correctly, but they can only start; the certificate authority takes a minute or two to issue, and the browser will show the warning until it does. Give it ten minutes after the DNS is confirmed, hard-refresh, and check the platform dashboard for the certificate status before you assume something is wrong.

Can I connect a domain I already use for email without breaking the email?

Yes, and this is the mistake that costs consultants a day of lost mail. Email routing lives on MX records; the website lives on A, CNAME, or ALIAS records. Changing one does not touch the other, unless you replace an entire zone or ask the registrar to point nameservers at a new provider. Add or edit the web records only, leave every MX and TXT record untouched, and mail keeps flowing. If your builder or hosting provider asks to become the nameserver for the whole domain, export your existing MX and TXT records first and re-add them on the new side before you flip nameservers — otherwise the receiving mail server will start rejecting messages within the hour.

Useful sources and further reading

About the author

Ahmed Hussein — Founder of Seera · Software Development Engineer at Amazon

Ahmed builds Seera and writes about the developer-side of consultant portfolios — the DNS, hosting, and deployment pieces that turn a page into a real website on a domain you own.

Reviewed by Mazen Ahmed, Co-founder & Growth Product Manager at Seera.

Editorial standards →