Maintain third-party links and logos on a website

Start with the official source

For each resource, record its current public name, official URL, exact purpose and verification date. A search result or old announcement may help you find it, but the destination itself should confirm that the service still exists.

Open the final URL in a browser and see what visitors actually receive. HTTP 200 alone is insufficient: the link might land on a homepage, login or unrelated content. The web directory illustrates entries with a stated use and destination.

• Name and URL confirmed by the official site.
• Destination checked visually.
• Verification date retained.

Show the right identity in the right context

Use official brand resources where available. Keep the logo’s proportions and published usage rules. Do not confuse an old identity, generic favicon and the logo of the service actually linked.

A mark in a directory identifies a destination; it does not imply a partnership, endorsement or certification. The card title must remain readable if the image fails. A decorative logo beside a visible brand name usually needs an empty alternative rather than a repeated name.

• Asset belongs to the correct entity.
• Proportions preserved.
• No unsupported relationship implied.

Detect changes and failures

Review redirects, error codes and domain changes regularly. Pair automated checks with visual inspection of a sample: links can remain technically valid while becoming useless. Check logos too, particularly those loaded from third-party servers.

When a service closes or merges, find its official replacement, revise the description or remove the card. Do not silently send visitors to a different organisation. If validation requires an account, state what could and could not be confirmed.

Fictional exercise: a checker receives 405 for HEAD, while GET on the same URL returns 200 and the expected content. Record both methods instead of “site closed”. HEAD requests metadata without a response body, so it cannot provide a page for reading. A 405 concerns an unsupported method for the resource and should be examined with Allow. This scenario illustrates a check, without justifying poor server configuration.

Keep requested URL, method, check date, intermediate statuses, final URL and editorial result. A redirect to login, an unrelated 200 page and a timeout require different decisions. If the check is refused, record that limitation and use authorised access for review; invent neither closure nor validation. Without a received HTTP response, the status is unknown: “0” is not an HTTP status code from the server.

• Redirects and errors tracked.
• Visual spot-checks performed.
• Closures and mergers explained.

Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.

Keep each language version useful

Give every resource a concrete reason to use it: which question it answers, for whom and in which country or setting. A row of logos alone is not enough to choose. Avoid claims of being the best that you cannot substantiate.

Review translated names and destinations. If the source is available only in French, say so rather than inventing an English destination. The multilingual guide helps keep translations and links consistent.

• Use described in a precise sentence.
• Destination language clear.
• Translations reviewed after changes.

Identify features genuinely needed by a third-party integration.

Synthetic case: an embedded map needs neither camera nor microphone, while another component uses an allowed feature. Test policies on a copy of the journey and check each directive in target browsers. Do not copy restrictions without knowing their effects. The policy does not replace permissions requested from the person.

• Required features remain available; targeted restrictions and browser differences are documented.

• MDN Permissions-Policy

  Header controlling selected browser features in a document and embedded frames, depending on support.