Reduce Web Notification Spam with Chrome and Firebase Cloud Messaging

Target outcome: after the review, the website requests notification permission only after a deliberate user action, does not pressure users to click Allow, does not send misleading or irrelevant content, and can disable the FCM registration when users turn off notifications.

To reduce unwanted web notifications, do not start by changing the Firebase project or regenerating the VAPID key. Check these items in order: the permission-request flow → the permission status in Chrome → the FCM registration → the content and sending frequency → abuse reports. FCM provides a mechanism for delivering messages to the web, but it does not replace the website’s responsibility to request permission appropriately and choose suitable content (see firebase.google.com).

Distinguish the Four Layers Behind Unwanted Web Notifications

Layer to check	Common problem	Verification signal
Permission-request interface	Displays a fake dialog resembling a system button or forces users to allow notifications to view the content.	The user did not deliberately request notifications but has already seen an invitation to enable them.
Browser permission	The domain is still allowed to send notifications even though the user no longer wants to receive them.	Chrome lists the domain as allowed to send notifications.
FCM registration	An old token or Firebase Installation ID is still stored and continues to receive messages.	The account or browser has disabled notifications, but the registration record remains active.
Message content	A title falsely presents a system alert, a message resembles a chat notification, the link is unfamiliar, or messages are sent too frequently.	The payload does not clearly explain why the message was sent or where it leads.

Chrome and Google Web Tools classify misleading permission requests, fake notifications, phishing notifications, and promotions for malicious software as forms of abusive notifications. Therefore, “someone clicked Allow” does not mean that “the registration is valid” (see support.google.com).

Check the Permission-Request Flow Before Checking FCM

Remove Permission Requests on Initial Page Load

Do not call Notification.requestPermission() in code that runs immediately when the page opens, in DOMContentLoaded, in an automatic timer, or after a redirect that the user did not deliberately initiate.

Chrome Lighthouse flags requesting notification permission immediately on page load as a poor practice. A safer approach is to first explain what type of messages the user will receive, then open the permission dialog only when the user clicks a clearly labeled subscription button (see developer.chrome.com).

The code below runs in browser-side JavaScript. The #enable-notifications button must exist in the website’s HTML. The registerFcmSubscription() function is the integration point with your Firebase setup; replace it with the actual function in your project, and do not copy the function name unchanged if your project does not contain that function.

const enableButton = document.querySelector('#enable-notifications');

if (!enableButton) {
  throw new Error('Không tìm thấy nút #enable-notifications');
}

enableButton.addEventListener('click', async () => {
  if (!('Notification' in window)) {
    showMessage('Trình duyệt này không hỗ trợ thông báo web.');
    return;
  }

  try {
    const permission = await Notification.requestPermission();

    if (permission === 'granted') {
      // Thay bằng hàm đăng ký FCM thật của ứng dụng.
      await registerFcmSubscription();
      showMessage('Đã bật thông báo. Bạn có thể tắt bất cứ lúc nào.');
    } else {
      showMessage('Bạn chưa bật thông báo; website vẫn hoạt động bình thường.');
    }
  } catch (error) {
    console.error('Không thể xin quyền thông báo:', error);
    showMessage('Không thể bật thông báo lúc này.');
  }
});

After replacing the integration function, open the website in a test Chrome profile, click the button, and verify that the permission dialog appears only after the click. If the user declines, do not create an FCM registration record.

Design the Invitation So Users Do Not Click by Mistake

Clearly state what users will receive—for example, “delivered-order alerts” or “new messages”—instead of simply saying, “Click Allow to continue.”
Do not lock the content, video, search results, or close button behind the notification-permission request.
Do not use images or wording that imitates system dialogs, virus warnings, private messages, or browser-update requests.
Let users choose “Not now” while continuing to use the website normally.
Display a button for turning off or managing notifications in the user account instead of forcing users to find the setting in their browser.

If the website uses an intermediary interface before showing the Chrome dialog, that interface must explain the request honestly and must not apply pressure. A deceptive prompt can cause users to subscribe unintentionally and is a common sign of web notification abuse.

Check notification permissions in Chrome

On a computer, open Chrome and go to Settings → Privacy and security → Site settings → Notifications. Check the website’s domain in the lists of allowed and blocked sites, as well as any entries that Chrome is prompting users to review.

Chrome may automatically revoke notification permission from websites that Safe Browsing identifies as deceiving users into granting permission. Chrome may also limit prompts or require a website to request permission again. Therefore, a changed permission does not necessarily indicate that FCM is broken; first check the permission-request experience and the domain’s safety status (see support.google.com).

For a practical test, use a clean Chrome profile or clear the domain’s permission in Settings, then run the following scenarios:

Open the page for the first time: the permission dialog must not appear automatically.
Read the explanation without clicking the subscription button: the browser’s permission dialog must not appear.
Click the subscription button: only then should Chrome display the permission request.
Select “Don’t allow”: the website’s main content must remain usable.
Select “Allow”: receive only the type of notification that was described.
Revoke permission in Chrome: the system must no longer treat the browser as an active subscription.

Chrome has a “Use quieter messaging” option to reduce disruptive prompts. This is a browser feature, not a fundamental fix for a website that repeatedly requests permission or sends poorly targeted content.

Review Firebase Cloud Messaging and notification subscriptions

FCM on the web requires notification permission, a service worker, and HTTPS configuration. Only after permission has been granted should the application register the browser, store the required identifiers on the server, and use them to send messages to the right recipients. In your system, create at least the following mapping table:

Field	Purpose	Required handling
User or account ID	Identify which user owns the subscription.	Delete or disable it when the account signs out, unsubscribes, or is deleted.
Origin or domain	Prevent a subscription from another website from being used accidentally.	Reject records whose domain does not match the expected domain.
FCM token or Firebase Installation ID	Route notifications to the correct browser instance.	Update it when the value changes; remove it when FCM returns an invalid-token error.
Consent state	Record whether the user has enabled notifications, disabled them, or has not decided.	Do not assume that a user is “subscribed” merely because a token once existed.
Topic or recipient group	Limit the types of content that can be sent.	Unsubscribe the user from the group when they clear the selection.

Do not send a promotional notification to every token simply because the tokens still exist in the database. Each campaign should have audience criteria, a purpose, an expiry period, and a mechanism for excluding users who have opted out. Firebase also recommends managing installation identifiers and not mixing legacy and current subscription-management methods in the same flow.

Revoke the subscription when the user turns off notifications

The “Turn off notifications” button should perform both actions: update the consent status on the server and delete or disable the corresponding FCM subscription. If it only hides the button in the interface, the server may still send messages to the old token.

async function disableNotifications() {
  const response = await fetch('/api/notification-subscription', {
    method: 'DELETE',
    headers: { 'Content-Type': 'application/json' },
    credentials: 'include'
  });

  if (!response.ok) {
    throw new Error(`Không thể tắt đăng ký: HTTP ${response.status}`);
  }

  showMessage('Đã tắt đăng ký thông báo trên tài khoản này.');
}

The code runs in the browser and /api/notification-subscription is only an example endpoint; replace it with the application’s actual API. The server API must authenticate the user and disable only subscriptions belonging to that account. Do not expose an FCM server key, a VAPID private key, or administrative credentials in JavaScript sent to the browser.

Check notification content, links, and frequency

Every notification should answer three questions: Who sent it? Why did I receive it? Where will it take me if I click it? If users cannot answer these three questions quickly, the notification may be perceived as spam even when the delivery technology is working correctly.

Title: describe a specific event, such as “Your order has been delivered”; do not use “Urgent alert” unless there is a genuine incident.
Body: keep it brief and accurate; do not create a false sense of loss or ask users to enter a password out of context.
Icon: use a recognizable brand or product icon; do not use imagery that resembles an operating-system alert.
Link: use HTTPS, point to the correct relevant page, and do not redirect through a chain of domains of unclear origin.
Frequency: Group similar events, set per-user limits, and stop sending messages when there is no longer a valid reason to do so.

For background web notifications, FCM supports links that take users back to the application; these links must be HTTPS URLs. Firebase documentation also recommends that the title accurately describe the nature of the notification and not repeat the website name or domain in the title when the browser already displays the domain (see firebase.google.com).

Check the Chrome Abusive Notifications Report

If you are the domain owner or a user with access in Google Search Console, open the domain’s Abusive Notifications Report . The report may show page examples, the type of violation, and how the experience appears. The report examines only a sample URL, so fixing one page is not enough to conclude that the entire domain is safe.

Record the URL, interface pattern, and type of issue shown in the report.
Identify the source of the experience: the website’s code, a tag manager, a plugin, an advertising network, or a third-party library.
Remove misleading permission requests and any fake or fraudulent notifications or links to unwanted software.
Review templates, landing pages, subdomains, and shared scripts.
Check again using a clean browser profile and the states for granting, denying, and revoking permission.
Request a review after addressing the entire group of issues.

If the report status is Failing, Chrome may block all notifications, as well as the website’s permission requests. Google states that the report is based on URL samples and that you must fix both the listed violations and any similar violations that remain; after the status changes, the updated behavior may take time to be fully reflected in Chrome (see support.google.com).

Quick troubleshooting tree for persistent unwanted notifications

No permission prompt appears: check the domain’s current permission, quiet notification mode, HTTPS, and browser management policies.
The user denied permission but still receives messages: look for old tokens, multiple domains, or multiple service workers recording the same device; disable the record on the server.
Only some users receive incorrect messages: check the segment, topic, configuration cache, and whether signing out of the account removes the subscription.
Chrome revokes permission or blocks the request: check the Abusive Notifications Report, fake interface layers, third-party scripts, and linked content.
Duplicate notifications are received: check for duplicate sends from notification messages, data messages, and the service worker; ensure that only one flow is responsible for displaying the notification.
Notifications continue after the service worker is deleted: check the domain’s permission, FCM records on the server, and other browsers or subdomains; deleting one service worker does not automatically revoke all user permissions.

Acceptance checklist before wider rollout

The first page load does not automatically request permission.
The explanation clearly states the type of notifications and their expected frequency.
Users can dismiss the prompt and still use the main content.
FCM is registered only after the permission status is granted.
The token or Firebase Installation ID is associated with the correct user, domain, and content group.
Invalid, outdated, or revoked tokens are disabled on the server.
The notification opt-out button updates both the consent status and the sending record.
Notifications do not impersonate system alerts, private messages, or security warnings.
Links in notifications use HTTPS and lead to the correct context.
The Chrome Abusive Notifications Report has been checked after deployment.

If you are fixing a legacy system, deploy the minimum path first: disable automatic permission requests → add a clearly labeled subscription button → stop sending to tokens that cannot be verified → review the payload → check Google’s report. Only then optimize segmentation and frequency. This approach helps distinguish permission, subscription-data, and content problems instead of changing everything at once.

Reduce Web Notification Spam by Auditing Chrome and FCM Permissions