A member badge can look correct and open the expected website while its configured link differs from the publisher requirements. When investigating a possible verification problem, that is a specific mismatch you can check before changing registration details.
This guide focuses on the link around the Congrid member badge. For a broader preparation review, use the publisher website verification checklist.
Establish the exact requirement
The current publisher onboarding guide requires the member badge on the homepage at /, with the surrounding link's href exactly equal to https://congrid.net. The badge's domain and wallet also need to match the registration.
Start a review note with the public homepage URL, the time of the observation, and the symptom that prompted the check. If you are looking at a publisher-status readout, record its exact label and source separately. A suspected link mismatch and a reported protocol status are different pieces of evidence.
Inspect the link around the badge
Open the deployed public homepage rather than an editor preview. Confirm that you are reviewing the intended publication and the badge on its root homepage.
Ask the website maintainer to inspect the surrounding anchor element and its href attribute. Selecting only the badge image may leave you looking at the image's attributes instead of the link that wraps it.
Compare the configured attribute value with the current guide. Clicking the badge and checking the final address is insufficient for that comparison: a redirect or an altered URL may still lead to a recognizable Congrid page.
For developers inspecting the DOM, MDN documents the distinction between an anchor's href property and its attribute. The property resolves a valid relative URL to an absolute URL. The getAttribute() method reads the specified attribute's string value and returns null when that attribute is absent. Inspect the attribute value when comparing it with the documented requirement.
Compare three stages of the deployment
Keep the generated embed, the homepage template, and the deployed result side by side. This helps locate where a link changed.
| Stage | Evidence to inspect | What a difference suggests |
|---|---|---|
| Generated embed | Code produced by the current onboarding page for the intended domain and public wallet | The starting code or entered details need review |
| Homepage template | The badge code saved in the production homepage template | The embed may have been edited while being added |
| Deployed homepage | The surrounding anchor and its current href attribute | A build step, link-handling rule, or deployment difference may need investigation |
Use this comparison to locate the actual change in your own deployment before choosing a fix.
For example, imagine a template rule that sends external links through a local redirect path. The badge still opens Congrid after a click, but the deployed anchor now contains that redirect path. The relevant evidence is the changed attribute, even though the reader's final destination looks familiar.
Identify the value that needs correction
Use the guide's exact requirement as the reference. The examples below illustrate attribute comparisons; they are not complete member badge embeds.
| Observed href value | Comparison with the documented value |
|---|---|
https://congrid.net |
Matches the required value |
https://congrid.net/?utm_source=homepage |
Contains an additional query string |
/out/congrid |
Uses a relative redirect path |
| Attribute absent | Provides no href value to compare |
Use the full embed generated by publisher onboarding when making the repair. Preserve its intended domain and public owner wallet details as well as the required surrounding link.
If your template intentionally rewrites external links, ask the maintainer to use the site's supported method for preserving this embed. Review the deployed result after that change instead of assuming that saving the template completed the repair.
Keep the website repair and registration review separate
After deployment, reopen the public homepage and inspect the anchor again. Record the observed value and the check time. That closes the specific website-code comparison when the evidence matches the requirement.
Then review whether the intended registration details changed. A link repair and an owner-wallet change are different tasks. The publisher guide requires registration again when the owner wallet changes and states that the new owner takes effect after verifier consensus confirms the change. Follow that workflow when it applies.
Use precise completion notes:
- Homepage link corrected and checked on the public site.
- Domain and public wallet compared with the intended registration.
- Any required registration update recorded with its actual result.
- Publisher status checked through the current workflow, or still unresolved.
A public-page repair and a protocol status update are separate milestones. Use the reported status and its timestamp to confirm the result; keep the issue open while that result is unresolved.
Prepare a useful follow-up record
If the link comparison is now correct but the original concern remains, retain the homepage URL, observation times, before-and-after attribute values, deployment reference, and the status evidence you actually have. State the remaining question explicitly.
For example: “The homepage badge link now matches the onboarding requirement; the owner-change result still needs confirmation.” That gives the next reviewer a narrower task than “verification is broken.”
Continue with the current publisher and verifier guides for the applicable workflow. Evaluate reader visits through a separate referral-traffic review; traffic changes alone do not establish whether this particular link mismatch is resolved.