Block unwanted Telegram links without breaking useful replies
Build a link policy for websites and Telegram destinations, keep allowlists narrow, test hidden URLs and invitations, and recover from mistaken removals in Defendy.
A support group needs links to documentation, troubleshooting guides and release notes. It may also attract accounts promoting unrelated channels. A blanket link ban makes the promotion harder, but it can remove the most useful part of a legitimate answer.
Start by separating website links from Telegram destinations. Defendy gives those categories independent modes: remove, blocklist only, or leave untouched. Then check the exceptions and special link types. An allowed website, a public channel address and an invitation to a private group do not all follow the same path.
In an investment or crypto community, an allowed domain does not settle whether a pitch is safe. Review scams and fake-support scenarios before designing exceptions.
For buttons, nested rich blocks and links inside polls, use the modern-message test matrix. A successful plain-text URL test does not establish coverage of those surfaces.
Choose the policy your moderators can maintain
There are two practical starting points.
Allow new sources and block known unwanted ones. This suits communities that exchange research, products or technical references. It preserves useful discoveries, but an unfamiliar promotional domain will not become prohibited merely because it is new.
Allow only a small approved set. This suits a tightly scoped project group where members mostly need the project's own resources. It requires a responsive way to request additional sources. Otherwise members cannot provide evidence for their answers.
A temporary broad restriction during a spam incident can also be reasonable. Give it an owner and a condition for returning to the normal policy. Do not leave the community permanently restricted because nobody remembered why a switch was changed.
Publish the practical rule: what members may share, how to request an exception, and how to report a mistaken removal. The group-rules guide covers making that information available to members.
Separate the two ordinary-link categories
In Settings → Anti-spam → Links, choose a mode for Websites and another for Channels and chats.
| Mode | Ordinary-link decision | Suitable starting point |
|---|---|---|
| Leave untouched | Do not check this category of ordinary links | A category moderators will handle manually |
| Blocklist only | Treat listed sources as violations | Open discussion with a few known unwanted destinations |
| Remove | Treat sources outside the allowlist as violations | A narrowly scoped group with approved resources |
This table does not override the separate invitation and group-quote checks discussed below.
The allowlist and blocklist are not a combined priority system. In Blocklist only mode, the ordinary destination is checked against the blocklist. In Remove mode, its absence from the allowlist is what matters. Keeping the same source in both lists makes the configuration harder to understand rather than adding an extra layer of protection.
The member action is another decision. None means no additional member punishment, not a promise to preserve a violating message. Use that action with disposable messages in a private test group while you establish what the filter matches.
An allowlist is a boundary, not a safety certificate
For website exceptions, start with explicit hostnames. The checked implementation compares the extracted name with list entries using exact, case-insensitive matching. example.com is a different entry from docs.example.com and from example.net.
If a project needs both its main site and its documentation host, list example.com and docs.example.com separately. Do not assume that approving a parent domain automatically approves every subdomain. Likewise, a path such as /help should not be treated as a supported rule that approves only that section of a site: these controls are source lists, not page-level access policies.
The add-entry form offers Domain, IP address and Telegram types. Choose the appropriate type. Some interface hints mention wildcards or CIDR, but the checked list-matching logic does not establish expansion of wildcard patterns or address ranges. Use explicit, verified entries rather than relying on a broad pattern that has not passed your tests.
For a Telegram source, use a Telegram entry for the intended public destination. A public channel URL, a private invitation, a post link and a bot-launch URL with parameters are distinct cases. Approving one does not establish permission for all the others.
Be deliberate about popular-site exceptions
The Links screen also offers exceptions for popular websites and popular Runet websites. Review the actual domain lists before turning either on. These are additional permissions for sources; they do not inspect or endorse every page hosted there.
Those exceptions are checked before the blocklist. If a blocked popular domain keeps passing, check these toggles before adding the same domain again. A blocklist entry does not override an active popular-site exception.
A hosting platform can contain useful documentation and unwanted promotional pages. A URL shortener can point somewhere different from the address visible in the message. Broadly permitting either creates a larger exception than permitting a project's own host. Do not assume that the link filter follows every redirect or evaluates the content behind every allowed URL.
Invitations and post links can bypass your ordinary-list assumptions
Invitations and group quotes have separate controls. When the relevant check is enabled and a link is classified into that type, the ordinary allowlist does not override it. This explains a common surprise: the organizer's public channel address works, but an invitation they share is removed.
Leaving ordinary Telegram links untouched is not a universal off switch for these special checks. To suspend the entire link-filter module while investigating, use its main enable switch. Other moderation modules can still operate.
Test bot-launch links with parameters as well. Some links containing ?start= are handled by the invitation checks. An allowed bot name is not enough to establish that every launch link to it will pass.
The current interface's option for allowing user mentions is unavailable. Do not base your policy on a promise that the filter always distinguishes a person's @username from a channel's. Include a normal member mention in the test set before adopting a strict Telegram-link policy.
There is also no “block links for a member's first N days” timer in this form. Newcomer CAPTCHA is a separate control, not a way to configure such a link probation period.
Work through one configuration
Imagine a project-support group. Members should be able to share general technical sources, but a known promotional domain is unwanted. Ordinary Telegram links should be limited to the project's official channel. This is a hypothetical policy, not a default configuration.
- Open @defendy_bot, select Settings and choose a private test group. Verify the group name before editing.
- Open Anti-spam → Links and enable the module.
- Set Websites to Blocklist only and Channels and chats to Remove.
- Open the blocklist, choose Add, select Domain and enter the unwanted host. For a harmless test, use a controlled example such as
example.netrather than a real suspicious destination. - Add your project's actual public channel to the allowlist with the Telegram entry type. Check the spelling and saved record.
- Review invitations, group quotes, IP handling and non-clickable links explicitly. Leave popular-site exceptions off for the first test so the source of each decision is easier to identify.
- Choose None as the member action. Save the add-entry forms. Switches and selectors save as you change them; reopen the page to confirm the actual values.
- Run the cases below from an ordinary member without administrator privileges or special exemptions. Introduce member penalties only after the link decisions are acceptable.
If you later choose a temporary mute or ban, select its duration explicitly after choosing the action and verify the result. A warning can also trigger an existing escalation threshold, so read the warning settings before treating it as a mild test action.
Test the message, not just the domain
The following are expected outcomes for the hypothetical policy above, not recorded live-test results. Keep a separate column for what actually happens in your group.
| Test message | Expected result or question |
|---|---|
| A normal reference site absent from the blocklist | Remains |
A link to the blocked test host example.net | Produces a violation |
| A public URL for the allowed project channel | Remains unless a separate special-link check applies |
| A public URL for an unrelated channel | Produces a violation |
| One allowed URL and one blocked URL together | The allowed URL does not excuse the blocked one; the whole message may be removed |
| The words “installation guide” linked to a blocked URL | The destination must be checked, not only the visible label |
| An invitation to a private group | Verify separately under the invitation setting |
Telegram represents visible URLs and links embedded in text separately in MessageEntity. That is why a pasted-address test does not cover a formatted hyperlink.
Add the forms your members actually use: a photo caption, a link to a particular post, a monospace example, a subdomain, mixed capitalization and several links in one message. Non-clickable website links and non-clickable Telegram links have separate controls. Treat a disguised address such as site[.]com as a specific test case, not proof that every obfuscation will be detected.
Use prepared, harmless destinations. You do not need to open an unknown page to test whether a message violates your link policy.
Why disabling link previews did not solve it
Telegram's can_add_web_page_previews permission controls previews, not the presence of URL text. The distinction is documented in ChatPermissions.
Message removal also requires the bot's deletion authority; Telegram documents the supergroup delete-message right under deleteMessage. If settings save but a violating test message stays, start with the Defendy permission checklist.
Fix a false positive at the right layer
When someone reports a missing reply, first identify the actual content: a website host, a private invitation, a post link, a formatted URL, or several addresses together. The member may remember the helpful source and overlook the second URL in the same message.
Then inspect the matching category and the saved entry. A missing documentation subdomain calls for an explicit host exception and a retest. An invitation removed by its separate check will not be fixed by adding more website domains. A known blocked host that passes may be receiving a popular-site exception.
Consult the moderation log if logging was enabled for the relevant events. Do not infer the cause from the presence of a URL alone: another filter or another bot may have acted. If legitimate conversation is being disrupted repeatedly, temporarily disable the link module, isolate the cause and rerun the whole test set before enabling it again.
Correct any mistaken member warning or restriction separately. Changing the source list does not restore the original deleted message or undo an existing sanction. Once the configuration is fixed, ask the member to repost the useful answer and explain the adjustment briefly.
Keep the failed message in your test set. The next allowlist change should preserve the useful reply and still reject the unwanted example. That pair of outcomes is more meaningful than simply counting how many links disappeared.
Sources and verification
Defendy's controls and implementation details were checked on 5 October 2026. The link-filter guide provides the field reference. Telegram's official permissions, message entities and message-deletion documentation were checked on the same date. All worked configurations are hypothetical and still require testing in your own group.
