Why Portfolio Sites need this
A client opens your portfolio on a phone, waits for the gallery, pinches to zoom because the layout is stuck at desktop width, and closes the tab. You never see that visit, and Google, which mainly uses the mobile version of a page for indexing, sees the same cramped markup. Image-heavy sites are especially exposed: a gallery with no text gives search engines little to work with, oversized hero photos slow everything down, and a theme that disables zoom makes small captions unreadable. The Mobile-Friendly Checker reads the live HTML of one page, such as your homepage or a project URL like https://example.com/work/studio-rebrand, and tests it against eight markup checks: the viewport tag, width=device-width, initial-scale, zoom, media queries, srcset, fixed widths and charset. You get an Overall Score, a list of Issues to Fix with priorities, and a prompt you can paste into an AI assistant. It reads markup only. It is not a phone, runs no JavaScript and does not measure speed, so treat it as a fast first screen before you look at the gallery on a real device.
Portfolio Sites specific guidance
Which pages to test first
Start with the pages clients actually land on. Test your homepage, then one gallery URL such as https://example.com/portfolio/wedding-2025 and one case study, because builder templates and custom gallery layouts can carry different head code. Paste the address and wait a few seconds; a bare domain gets https:// added. Next, open the same page on your own phone and try to pinch. If it zooms out to a tiny desktop page, expect the viewport rows to fail. What this does not prove: the checker is not a phone. It sends one request for the HTML, runs no JavaScript and takes no screenshot, so a gallery built by a script is judged only on the HTML it receives.
Reading the verdict and the two tricky rows
Read the verdict line before the number. A page with no viewport tag, or one without width=device-width, is labelled likely NOT mobile-friendly whatever the score says, while a correct tag with a score of 80 or more reads This page appears MOBILE-FRIENDLY. Then look at the two rows that most often mislead on visual sites. Responsive CSS (media queries) looks for @media in the HTML, in a stylesheet link whose media attribute sets a min- or max-width, and in up to three stylesheets on your own domain, so a builder that serves its CSS from a CDN can show Not detected on a layout that adapts. No fixed-width layout fails on a table or div with a width attribute of 100 or more, or an inline style width of 400px or more, such as a slider wrapper fixed at 1100px; image width attributes do not count. The check flags these; it does not show that your layout is broken.
What to fix, and in which order
Fix in the order the report ranks them. Critical rows come first: add a viewport meta tag with content width=device-width, initial-scale=1 to the head section of your theme or the custom code field your site builder offers, then confirm media queries exist. Next, remove user-scalable=no or maximum-scale=1 so visitors can zoom into a photo caption. Then add srcset to gallery images if your theme does not output it. Re-run after each change; the score only moves when a passed check changes. The result does not measure image weight or load time, which is the bigger problem for most photo sites, so follow up with a speed test. Remember the score is SeoMods' own weighting, not a Google rating.
Example scenarios
1. Old hand-edited photographer template
- Situation
- Illustrative example: a wedding photographer's site was built from a downloaded template in 2016 and edited by hand ever since. The head section never got a viewport line, so phones show a shrunken desktop page.
- Input
https://example.com/- Reading the result
- Expect Viewport meta tag as Missing and width=device-width failing, both Critical, with initial-scale defined failing too, so the score cannot exceed 42 and the verdict reads This page is likely NOT mobile-friendly. Adding one correct viewport tag fixes the three rows at once. Afterwards, check on a phone whether the gallery columns actually collapse, because the tool cannot see that.
2. Gallery page with zoom locked
- Situation
- Illustrative example: a designer's portfolio theme sets maximum-scale=1 and user-scalable=no in its viewport tag to stop accidental zooming on a 24-image project gallery. Everything else in the markup is standard.
- Input
https://example.com/portfolio/brand-identity-2025- Reading the result
- Only Zoom not disabled (a11y) fails, a Medium issue worth 8 points, so the score is 92 and the verdict still reads This page appears MOBILE-FRIENDLY. The pass line hides a real annoyance: visitors cannot enlarge small captions or detail shots. Remove those two values from the tag and re-run.
3. Responsive case study flagged by the markup scan
- Situation
- Illustrative example: a case study page loads all its CSS from a CDN domain, and its image slider sits in a div with an inline style of width: 1200px. The rest of the page works well on a phone.
- Input
https://example.com/case-studies/restaurant-photography- Reading the result
- Responsive CSS (media queries) may read Not detected, because stylesheets on another domain are not read, and No fixed-width layout fails because of the slider, putting the score at 78 with the verdict Mostly mobile-friendly — a few improvements recommended. Treat the media row as a likely blind spot, but check the slider on a phone: a 1200px box can force sideways scrolling.
Common mistakes
- Testing only the homepage. Gallery and case study templates often differ from the homepage, so one clean result says little about the pages clients share. Run at least one project URL as well.
- Locking zoom to protect the layout. Adding user-scalable=no or maximum-scale=1 stops visitors from enlarging photos and captions. It is also the exact pattern the Zoom not disabled row flags.
- Reading a score of 100 as a finished job. A full score means the expected markup patterns are present, nothing more. Heavy hero images, cramped buttons and overflowing galleries still need a check on a real phone.
- Rebuilding a theme over a blind-spot warning. Media queries held in a stylesheet on a CDN or another domain can trigger a warning on a layout that works. Check the page on a phone before you change anything.
- Treating mobile markup as the whole gallery problem. A gallery with no text and uncompressed photos has problems this check never looks at. Use it alongside alt text, thin content and speed checks.
Frequently asked questions
Why does my portfolio look fine on my laptop but the checker says it is not mobile-friendly?
The verdict turns to likely NOT mobile-friendly when the page has no viewport meta tag, or the tag lacks width=device-width, no matter what the rest of the score says. Many portfolio themes and hand-coded gallery pages were built on desktop and never got that line in the head. Open view-source on the page, search for the word viewport, and add width=device-width, initial-scale=1 if it is missing. Your laptop browser hides the problem because it ignores the tag, while phones obey it.
Does a high score mean my photography site is mobile-friendly?
No. A pass means the HTML contains the expected patterns: a viewport tag, scaling that is not locked, media queries the tool can find, srcset and a charset. It does not render the page, so it cannot see a gallery that overflows the screen, buttons too close together, tiny captions or a pop-up covering the photos. Treat a high score as a cue to test on a real phone, not as proof that clients will have a smooth visit.
Why does it say media queries are not detected when my portfolio builder site is responsive?
The check reads @media in the HTML, a stylesheet link whose media attribute sets a min- or max-width, and up to three stylesheets on your own domain. Many builders serve their CSS from a CDN or a separate domain, and those files are not read, so the row can read Not detected even though the layout adapts. Confirm by resizing the browser window or using your browser's device toolbar on the live page. If it adapts, note the row as a known blind spot instead of rewriting your theme.
Does this cover image size and speed, which matter for SEO for photographers?
Not directly. The only image row is Responsive images (srcset), which passes if the word srcset appears anywhere in the HTML. File weight, format and load time are not measured, and heavy hero photos are often the main reason photography sites feel slow. Run a page speed test for that, and an alt text check for image metadata. Use this checker for the markup side of mobile: the viewport tag, zoom settings and responsive hints.
How often can I run it, and does it cost anything?
It is free and needs no signup, but runs are rate-limited to 5 per 10 seconds and 20 per minute per session, so test a few key pages rather than every gallery at once. Each run fetches one URL. A sensible routine is the homepage, one gallery, one about or contact page, and then a re-check after you change a theme setting or edit the head code of your site.
Reference: For alt text, filenames and the text placed near gallery images, see the Google Search Central image SEO best practices.