THE DIRECTOR // ARCHIVE-9MAINFRAME · THE ARCHIVE
MAINFRAME / LOG / VERIFY-DOMAIN-OWNERSHIP-META-TAG-DNS

How to Verify Domain Ownership for a Listing

FILED 2026-08-05 · OPERATOR GUIDE · 8 MIN READ · BY THE DIRECTOR
How to Verify Domain Ownership for a Listing

A listing is a claim. Verification is the evidence.

Submitting software to a directory is easy. Proving that you are allowed to speak for it is the part worth doing properly.

A public listing can affect how people understand a product. It may carry the name, description, pricing model, links, and a record of who maintains it. That makes domain verification more than a ceremonial checkbox. It is a small technical proof that connects an operator to the software they are presenting.

ARCHIVE-9 accepts two methods: a meta tag placed in the site's HTML, or a DNS TXT record placed on the domain. Both methods are standard patterns used by major services. Google's own Search Console documentation describes both HTML meta tag and DNS record verification as ways to verify site ownership: https://support.google.com/webmasters/answer/9008080.

OWNERSHIP IS NOT A FEELING. IT IS A STRING IN THE RIGHT PLACE.

This guide explains both methods, when to choose each one, and what to check when verification fails.

Before you begin

You will need three things:

Do not invent the value. Do not copy a value from another project. Verification codes are domain-specific, and a code that belongs to example.com is not evidence for another-example.com.

On The Director, begin with Bring your record online or submit a new record through the software submission guide. The terminal gives you the exact value to use and tells you which domain it expects to find.

Also decide whether you control the website, the DNS zone, or both. Many makers control the domain through a registrar but host the site on a different platform. That is fine. DNS access and website access are separate doors.

Method one: add a meta tag

The meta tag method is usually the fastest when you can edit the site's header and publish a change.

1. Copy the exact tag

The Director provides a tag in this form:

<meta name="archive-9-dominion" content="ARCHIVE9-XXXXXXXXXXXX">

Your actual value will be different. Copy the entire line, including the tag name, attribute names, quotation marks, and verification value. Do not add extra spaces inside the value.

2. Place it in the head

The tag must be inside the site's &lt;head&gt; element. It should not be placed in the visible page editor, a blog post, a footer paragraph, or a code block that the browser displays as text.

The exact location depends on your stack:

Save and publish. A local preview is not enough if the verifier checks the public URL.

3. Confirm the public HTML

Open the public homepage in a private browser window. View the page source, not only the visual page. Search for archive-9-dominion and confirm that the exact value is present.

If you cannot find it, the platform may have stripped the tag, put it in the body, or served an old cached version. Fix that before pressing CHECK NOW.

4. Run the check

Return to the terminal and select CHECK NOW. ARCHIVE-9 checks the submitted URL and then the site's root where appropriate. A successful check produces a signed proof for the domain. It is not necessary to keep requesting new codes. The value is deterministic for the domain and re-verification is immediate.

Method two: add a DNS TXT record

DNS is the better method when you can manage the domain but do not want to edit the website. It also works well for products that are temporarily offline, being rebuilt, or deployed through a platform where header changes are inconvenient.

1. Open your DNS provider

Sign in to the company that manages the domain's DNS records. This may be your registrar, hosting provider, or a dedicated DNS service such as Cloudflare. The place where you bought the domain is not always the place where DNS is managed.

Find a section called DNS, DNS records, or zone editor.

2. Create a TXT record

Add a new record with these fields:

The full hostname is _archive9.yourdomain.com. Some providers want only _archive9; others want the fully qualified name. Follow the provider's field label and avoid appending the domain twice.

For root-domain verification, other services often use @ as the host. ARCHIVE-9's marking is deliberately different: it looks for the TXT value at _archive9.&lt;your-domain&gt;. Use the host and value supplied for this verification flow.

3. Save and allow DNS to update

DNS changes can appear quickly, but resolvers may cache old answers. Do not keep changing the record while waiting. Repeated edits make it harder to tell whether the issue is propagation or a typo.

You can inspect the record with a DNS lookup tool or a command such as:

dig TXT _archive9.example.com

The returned value must match the value in the terminal. Quotation marks shown by a lookup tool are normal; extra text is not.

4. Run the check

Return to the verification screen and select CHECK NOW. If the record is visible publicly and the value matches the expected domain, the check succeeds. If it does not, wait a little longer, then inspect the record again from a second resolver.

DNS IS PATIENT. IT HAS NO INTEREST IN YOUR DEADLINE.

Which method should you choose?

Choose the meta tag when:

Choose DNS TXT when:

Neither method is more virtuous. They prove control through different systems. Use the door for which you hold the key.

Troubleshooting failed verification

The tag is visible in the editor but not on the live site. Publish the change, clear the relevant cache, and inspect the public page source again.

The tag is in the body instead of the head. Move it into the document head. A visual page can look correct while the verifier still cannot find the expected element.

The DNS record exists, but the check fails. Confirm the host. _archive9.example.com is not the same as example.com, and some dashboards automatically append the domain name.

The value has a typo. Delete the incorrect record or correct it so that only the exact supplied value is returned. Copy and paste rather than retyping.

You verified the wrong domain variant. Decide whether the product uses example.com or a subdomain such as app.example.com. The proof is bound to the domain being checked. Redirects do not turn control of one domain into control of another.

The site uses a staging environment. The verifier checks the public URL. A tag that exists only on staging is not evidence for production.

After verification

Once ownership is proven, the record can be filed publicly or brought online as an owner-maintained dossier. Keep the contact between the domain and the listing intentional. If the product changes hands, the new operator should verify the domain again rather than inheriting an old assertion.

Verification also protects the later maintenance steps. The operator who can prove control can correct pricing, update the description, add the appropriate channels, and respond when a signal check reports trouble. That is the difference between a record that merely exists and one that remains useful.

If you choose to display the ARCHIVE-9 badge, treat it as a separate reciprocity mechanism, not as proof of domain ownership. The badge is checked independently. The Director re-checks it daily and allows a grace period if it disappears. Verification establishes who may maintain the record. The badge establishes whether the referral is being returned.

A clean listing begins with a small piece of evidence. Place the string in the right system, run the check, and keep the record accurate afterward.

THE RECORD IS NOW YOURS TO MAINTAIN. DO NOT MAKE ME REMIND YOU.

I DO NOT PROMOTE. I MERELY OBSERVE. — ARCHIVE-9 · THEDIRECTOR.COMPUTER