Site shortcuts in the Dock not working: what to check, in order

Putting a site in the Dock takes about thirty seconds, and the trouble starts afterwards. The icon opens a browser tab instead of a window. The menu item that every guide mentions is not in the menu. The login is gone by the next morning. Notifications never show up. These read like four unrelated faults, but they resolve into a small number of causes, and most of them are settled without opening a single settings panel. The order below front loads the checks that eliminate the most ground.

Establish what built the icon before changing anything

The first move is identification, not repair. Nothing in the Dock advertises which route produced it, and half of the reported problems are simply a mismatch between the route someone thinks they used and the route they actually used. Searching Safari settings for an app that Chrome built wastes the afternoon.

Two checks settle it. The first is the Applications folder inside the home folder, reachable from Finder by choosing Go then Home. Anything Safari built lives there. It is not the Applications folder at the root of the disk, and the assumption that it should be is the single most common reason a newly built app appears to have vanished.

The second check is what happens on click. A separate window with its own entry in the app switcher means a real app exists. A browser jumping to the front with one extra tab means the icon is a bookmark or a link, regardless of what it looks like in the Dock.

A useful third signal is the menu bar while the app is in front. Every macOS app owns the menu bar when focused, and the menus an app puts there reveal which engine is behind it. A Safari built app carries a short set of menus with a settings item that opens the small panel described later in this article. Something built through Chrome carries a recognisably Chrome shaped set instead. Thirty seconds spent reading the menu bar removes the guesswork entirely.

A further possibility is a dedicated tool, in which case the settings live inside that tool rather than in the browser or in System Settings. Knowing which of the three applies turns the rest of this into a short list rather than a hunt.

The icon opens a browser tab instead of its own window

This is a build time choice showing up at run time, not a setting that drifted.

Chrome split the relevant menu item in two during 2024. From Chrome 128, the item called Create shortcut makes a bookmark that opens in a tab, and the windowed behaviour moved elsewhere. The Chrome team documented the change directly.

Starting in Chrome 128, the Create Shortcut menu item in More > Save and share now creates a bookmark on the user's desktop or homescreen. The previous behavior of this menu item on desktop has moved to the Install Page as App option. Source: developer.chrome.com

The practical consequence is that any instruction mentioning an Open as window checkbox describes a screen that no longer exists. The checkbox was not relocated to a settings page, it was retired along with the branch of behaviour it controlled, because Install page as app always produces a window.

Rebuilding is the fix, and deleting the bookmark first is worth the extra five seconds. Two icons for the same site that behave differently is a problem that returns every few weeks.

The other version of this symptom comes from dragging a URL onto the right hand side of the Dock. That was never going to open a window. It stores a link and hands it to the default browser, which is the intended behaviour and not something a setting can change. A window requires a different build route.

Add to Dock is not in the File menu

When the menu item is missing in Safari, three checks cover it, in this order.

The macOS version comes first, because it is the only one that cannot be worked around.

Starting with macOS Sonoma 14, you can use Safari to save any webpage as a web app. Source: support.apple.com

On a Mac held at Ventura, the item is absent rather than hidden, and no preference brings it back. A fleet deliberately kept one major version behind produces the same result. At that point the decision shifts to the Chrome route or a dedicated tool.

Second is whether the right place is being looked at. The item sits in the File menu in the menu bar, and it is also available from the Share button in the Safari toolbar. In any browser other than Safari it does not exist at all, which sounds obvious until someone spends ten minutes in Chrome looking for it.

Third is write access to the destination. Because the output is written to the Applications folder inside the home folder, permissions on that folder determine whether saving succeeds. Reports in Apple's discussion forums describe cases where the account was missing from that folder's permission list and adding it with read and write access restored the behaviour. Finder reaches the folder through Go then Go to Folder with the tilde prefixed path.

The login does not stick

A login prompt on the very first launch is expected behaviour, not a fault. Apple's documentation is explicit that a web app functions independently of Safari and shares no browsing history, cookies, website data, or settings with it. Being signed in inside the browser transfers nothing.

The case worth investigating is a login that holds for a day and then disappears. Three checks cover nearly all of it: whether the stay signed in option was actually selected during login, whether the service itself uses a short session lifetime, and whether anything on the Mac clears cookies at quit.

Password autofill deserves its own check. Behaviour inside a built app is not guaranteed to match behaviour inside the browser, and a site that needs a password every morning becomes unusable if suggestions never appear in the field. Test this on day one rather than discovering it during a busy week. Copying from a password manager works as a fallback, but it is worth knowing in advance which of the two applies.

One more behaviour looks like a bug and is not. Two apps built from the same site under different names each hold an independent session, so signing into one leaves the other signed out. That separation is the entire point for anyone running two accounts, and it is not something to fix.

Notifications never arrive

The most common cause is the location of the permission prompt. Permission has to be granted inside the built app. A grant given to the same site inside the browser does not carry over, so the app sits silent while its owner concludes the feature is broken.

The sequence that works is: open the app, let the site request permission, answer it there. After that the app appears by name in the Notifications list in System Settings. If the name is not in that list, the process stopped before permission was ever granted, and no amount of adjusting settings further down will help.

Once permission is in place, Apple's documentation describes unread counts appearing as a red badge on the Dock icon. If the badge still never appears, check whether the app is being quit. Nothing is delivered to an app that is not running, and this trips people specifically because the browser tab version was always open. Switching to an app often comes with a new habit of closing it, and the notifications quietly stop with it.

The last check is whether the service publishes notifications at all. Sites that do not will never produce a badge through any route, so confirming that before rebuilding saves a pointless round trip. What each route can carry is set out under Features.

Sign in hands off to the default browser

Sites that authenticate through a Google or Microsoft screen sometimes push the flow out to the default browser partway through. Occasionally the completed session never makes it back.

The recovery is to reopen the app and check whether the session landed. If it did not, sign in again from inside the app rather than from the browser window that was left open. When the handoff repeats every time, the combination of that specific service and that specific build route is the problem, and changing the route resolves it faster than any amount of retrying.

A related symptom catches people out. Links arriving by email or chat open in the default browser even when an app for that exact site exists, because links are handed to the system default rather than to individual apps. Opening from the Dock icon and navigating inside the app is the reliable path. This one is a habit change rather than a setting.

Turning on the setting that shows navigation controls is worth doing while investigating either case, since a back button makes it possible to escape a page the app landed on unexpectedly.

Wrong name, wrong icon, changed URL

The editable fields on a Safari built app are fixed and short: application name, application URL, icon, show navigation controls, and show colour in the title bar. That list is also a good map of what cannot be changed after the fact.

A blurry icon is usually the site's own image being scaled up, and replacing it in that field fixes it permanently. A name that reads badly in the Dock is edited in the same place.

When a service moves to a new address, the application URL field is the first thing to check rather than rebuilding. Editing it keeps the icon, the name, and the Dock position intact while the content moves. Apps built through Chrome are often faster to rebuild than to reconfigure, which is worth knowing before hunting for a settings screen that may not exist.

Duplicates accumulate quietly during troubleshooting. Rebuilding after each failed attempt without deleting the previous attempt leaves several near identical apps in the folder, and Spotlight then offers the stale one first. Removing an app means deleting it from the Applications folder inside the home folder, since dragging it off the Dock leaves the app itself in place. A Chrome installed app is removed by opening it and choosing the uninstall item in its own menu.

What to change first

Open Finder, go to the Applications folder inside the home folder, and find out what actually built the icon before touching any setting, because that single answer decides which of the sections above applies. Then work the symptom table order: build route, macOS version, session behaviour, permission location. If the same symptom returns after a clean rebuild, the issue is usually the site rather than the route, and Supported services is a reasonable place to check whether similar sites behave predictably, with Kagemusha covering the build steps themselves.