Why your favicon doesn't show in Google Search — and everything else that silently broke after my Next.js deploy

Preetkamal Singh — Sun, 05 Jul 2026 06:51:53 +0000

My deploy was green. The site worked. The favicon showed in the browser tab. Done, right?

Then over the next weeks I discovered, one by one: Google showed a gray globe instead of my logo, my link previews rendered differently on every platform (broken image on Facebook and Discord, fine on Twitter), and Safari on iPhone was showing the Vercel triangle in my tab strip — a logo I never put anywhere.

None of these threw an error. Nothing failed in CI. Everything just silently didn't work. Here is every cause I found debugging it on my production app (jobcost.app), in the order you should check them, with the exact Next.js (App Router) fix for each.

1. Google ignores favicons that aren't a 48px multiple

Google requires the search-result favicon to be a square, and a multiple of 48px — 48×48, 96×96, 144×144 — or an SVG. The classic 16×16/32×32 favicon.ico renders fine in the browser tab and gets silently ignored by Google. The tab tells you nothing.

App Router fix — use the file convention, no manual tags:

app/
  icon.png        // square PNG, 96x96 or larger — Next.js generates the <link> tag
  apple-icon.png  // 180x180 — you need this one more than you think (see #2)
  favicon.ico     // keep for legacy browsers — but read #2 first

2. The Vercel triangle you never added: create-next-app's default favicon

This one hurt. Safari on my iPhone showed the Vercel logo in the tab strip for my own product. Clearing history did nothing.

Cause: create-next-app ships a default favicon.ico (the Vercel/Next triangle). Depending on your version it lives in app/ or public/ — and if you replaced one location, the template file can survive in the other. public/favicon.ico will happily keep serving the triangle after you've added a beautiful app/icon.png.

Three-part fix:

Search your repo for every favicon.ico — check public/ specifically. Delete the template one; keep exactly one, yours, in app/favicon.ico.
Add app/apple-icon.png (180×180). Safari prefers the apple touch icon for tab strips and bookmarks; without it, it falls back to that stale .ico.
Know that Safari caches favicons separately from history. "Clear History" does not clear it. Settings → Safari → Advanced → Website Data → delete your site's entry. And tabs already open keep the icon from when they loaded — test with a fresh tab, or you'll chase a ghost like I did.

Verify like an engineer, not a browser-refresher: open yourdomain.com/favicon.ico and /apple-icon.png directly in a private tab. What those URLs serve is the truth; everything else is cache.

3. You have twitter:image but no og:image

My link previews were inconsistent: fine on X, broken image everywhere else. Cause: my head had twitter:image but no og:image. X reads its own tag; Facebook, WhatsApp, LinkedIn, Discord, Telegram, iMessage all want og:image. Miss it and every platform except X shows a broken card.

The Facebook Sharing Debugger even warns you — "Inferred Property: the og:image property should be explicitly provided" — but only if you think to look.

Related trap: if you have both old manual <meta> tags (from a Head component or next-seo) and the new metadata export, they fight — I ended up with og:image content="" rendering empty. One source of truth only. Delete every manual OG tag and use the export:

// app/layout.tsx
export const metadata: Metadata = {
  metadataBase: new URL("https://yourdomain.com"), // required to resolve relative image paths
  openGraph: {
    title: "Your Title",
    description: "Your description.",
    url: "https://yourdomain.com",
    type: "website",
    images: [{ url: "/og-image.png", width: 1200, height: 630 }],
  },
  twitter: { card: "summary_large_image", images: ["/og-image.png"] },
};

Then verify in view-source: — exactly one og:image tag, absolute URL inside. Only after the raw HTML is right do the checkers mean anything.

4. Your fix is deployed — but your CDN is serving the old version

This is the one that cost me the most hours: I had already fixed the meta tags, but Cloudflare kept serving the cached old HTML and images. Every checker kept "proving" my fix didn't work.

If you're behind Cloudflare (or any CDN): after deploying meta/icon changes, purge the cache for the affected paths (or purge everything). Then — separately — make Facebook re-fetch: Sharing Debugger → your URL → Scrape Again. Facebook holds its own cache of your old broken card and will show it for weeks otherwise.

Debugging order that saves your sanity: raw view-source → direct asset URLs in a private tab → purge CDN → re-scrape checkers. Truth flows in that direction.

5. robots.txt is silently blocking your icon

Google fetches your favicon with a crawler. If robots.txt blocks the icon's path — or a catch-all rule catches the /_next/ asset path — Google gives up with no warning anywhere. Check yourdomain.com/robots.txt in production and confirm what app/robots.ts actually outputs.

6. Your homepage isn't indexed yet

Google only shows a favicon for sites whose homepage it has indexed. Fresh domain, fresh deploy = no index = gray globe regardless of a perfect setup. Search Console → URL Inspection → homepage → Request Indexing.

7. Everything is right — Google is just slow

Even with all of the above correct, Google can take days to weeks to fetch and display a new favicon, and there is no "refresh favicon" button. Requesting reindexing nudges it; after that it's a queue. Sometimes the gray globe isn't a bug — it's a waiting room.

The pattern across all seven: every one of these failures is silent. Green deploy, working tab, zero errors — and broken visibility that you discover by accident weeks later.

The full post-deploy checklist

Favicon: square, 48px-multiple, stable URL, not robots-blocked
Template favicon.ico deleted from public/ AND app/ — yours in exactly one place
apple-icon.png 180×180 exists
og:image present (not just twitter:image), absolute URL, 1200×630, loads with 200
Exactly one set of OG tags in view-source — no duplicates fighting
CDN purged after every meta/icon change; Facebook re-scraped
Sitemap present and submitted; robots.txt allows what you think
Canonical points at the right domain; homepage indexing requested

I'm building a tool that checks all of this in one shot — paste your URL, get every silent post-deploy failure flagged with the exact Next.js fix. Free when it launches. Leave your email here and I'll send it to you →

Written by a dev who stared at a gray globe, a broken preview card, and a Vercel triangle he never asked for. If this saved you that time, the signup genuinely helps me.

City Simulation with LLMs — Predicting Traffic & Generating Natural-Language Reports

Preetkamal Singh — Wed, 17 Sep 2025 08:42:10 +0000

TL;DR: I built a city traffic simulation that ingests sensor data, predicts congestion, and uses an LLM to produce human-readable incident reports.

Live demo:https://vercel.com/kamalpannus-projects/trafficpredictorfrontend | Code: https://github.com/Kamalpannu/trafficPredictor-Backend
https://github.com/Kamalpannu/trafficpredictorfrontend

Problem

City operations teams need quick summaries of traffic hotspots from noisy sensor streams. Raw numbers are hard to scan under time pressure — so I built a system that predicts traffic issues and auto-generates plain-English reports.

Architecture

Data ingestion: simulated traffic sensors → time series store
Prediction service: Python model (simple regression + heuristic)
LLM service: LangChain wrapping an LLM to summarize predictions into reports
Frontend: React app for dashboards and report viewer
Dockerized and deployed via CI/CD

Key implementation


python
from fastapi import FastAPI
from pydantic import BaseModel
from langchain import OpenAI, LLMChain, PromptTemplate

app = FastAPI()
llm = OpenAI(api_key="YOUR_KEY", temperature=0.2)
prompt = PromptTemplate(
    input_variables=["summary"],
    template="You are a city ops assistant. Given this summary: {summary}\nWrite a 3-sentence incident report with suggested actions."
)
chain = LLMChain(llm=llm, prompt=prompt)

class Payload(BaseModel):
    summary: str

@app.post("/report")
async def report(payload: Payload):
    text = chain.run(payload.summary)
    return {"report": text}

Note: replace YOUR_KEY with your environment variable or secrets management.

What I learned

LLMs are great at turning numeric summaries into useful prose, but they require clear prompts and guardrails.

Keep the LLM step after deterministic prediction — don’t let it invent numbers.

Results

Generated concise reports that a non-technical operator can act on.

Demo and sample reports: see https://github.com/Kamalpannu/trafficPredictor-Backend
https://github.com/Kamalpannu/trafficpredictorfrontend

Full source code and deployment steps: https://vercel.com/kamalpannus-projects/trafficpredictorfrontend

DEV Community: Preetkamal Singh