How to Review a Webflow Developer Portfolio: What to Actually Open

Reviewing a Webflow developer portfolio well takes seven checks, and none of them are the screenshots. Open the live URL, not the case study: the sitemap, the page source, an inner page, and the site at 991px, 767px and 479px will tell you in about ten minutes whether the build was finished or just delivered. Everything a portfolio chooses to show you is a design decision; everything in this list is evidence the developer did not curate.

• The sitemap. Read the lastmod dates to see when the build was really last touched.
• robots.txt. Check for staging-era blocking rules still live in production.
• An inner page's source. Look at the title tag and meta description on a page that was not the showpiece.
• The og:image tag. Confirm the file is a JPG or PNG, the only formats Webflow supports here.
• The Webflow fingerprints. Find the branding comment, the badge and the w- class prefix.
• The three stacked breakpoints. Resize to 991px, 767px and 479px and watch what breaks.
• A CMS-generated page. Open the third item in a collection, never the first.

What should you actually open in a Webflow developer portfolio?

Reviewing a Webflow developer portfolio means opening seven things, in this order, on a live client URL the developer names as their own work. Each row in the table below is one check, where it lives, and how to read the result. Every one of the seven is an artefact the live site emits whether or not anyone curated it.

Not every result carries the same weight, so here is how I score the seven. Checks 3 and 6, the inner page source and the three breakpoints, are close to disqualifying on their own: a missing or duplicated title tag and horizontal scroll at 991px or 767px are both visible to every visitor, and neither survives a real QA pass. Checks 1 and 5, the sitemap dates and the Webflow branding markers, are questions for the developer rather than verdicts, because a stale site and a visible badge can equally be the client's call. Checks 2, 4 and 7, the robots.txt rules, the og:image format and the CMS page, are craft signals where one alone is noise and two or more together are a pattern. A build worth shortlisting clears both disqualifiers outright, trips at most one craft signal, and has a straight answer for the two that may not be the developer's fault.

The two I open first are the sitemap and the og:image tag, because they are the two nobody dresses up for a portfolio. Both have turned up problems on builds whose case study pages were immaculate, and neither takes longer than a minute. This post covers the outside-in pass only. What to check inside the build itself, and how to run the wider vendor evaluation including a paid trial project, is already answered in evaluating a white-label Webflow developer, which owns that question on this site, and none of it is repeated here. If you are earlier than that and still deciding how to source the work at all, start from hiring a Webflow developer.

Why is the home page the wrong page to judge a Webflow build on?

The home page is the wrong page to judge a build on because the developer chose it. A portfolio is a curated set, and the home page is the single page inside that set which received the most attention per pixel. Judging a build from it tells you what the developer can do when they are being careful, which is not the question you are trying to answer. The question is what their system does on the pages nobody selected.

Open the second-level pages instead, and open at least one that is generated from the CMS rather than hand-built. Open the third item in a collection rather than the first, because the first item is usually the one that was on screen while the template was being styled. If the developer's CMS structure is sound, the third item looks as finished as the first. If it is not, the third item is where the padding collapses, the image aspect ratio changes, and an empty rich text field leaves a gap nobody styled.

How do you check when a Webflow portfolio site was last updated?

You check when a Webflow site was last updated by reading the lastmod dates in its sitemap.xml. Webflow's documentation states that "Webflow's auto-generated sitemap feature automatically generates a sitemap.xml for your site and updates it each time you publish your site", and that "Each URL in your sitemap now includes a <lastmod> tag, showing the date and time that page was last published" (Webflow Help Center, Create a sitemap in Webflow). That gives you a per-page publish timestamp on any Webflow site that has the feature switched on, without asking anyone.

Read it carefully rather than literally. The same Webflow article adds that "you'll need to republish your site before the updated timestamp appears in the sitemap", so a whole-site republish can refresh every date at once. Google treats the field the same way, using the lastmod value only "if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate" (Google Search Central, Build and submit a sitemap). What you are looking for is not one date but a spread: a portfolio site where the blog stopped in 2023 and the sitemap says every page was modified last Tuesday is telling you about a republish, not about maintenance.

A worked read makes the difference obvious. Take a candidate sitemap where the about page carries a lastmod of 2024-03-11, and eleven blog URLs all carry an identical lastmod of 2026-08-02 down to the same minute. Eleven identical timestamps are one republish, not eleven edits, so the recent-looking date proves nothing about the blog. The 2024 date on the about page is the real finding: no structural page on that site has been touched in over two years. What you now have is not a verdict on the build but a precise question to put to the developer, which is who has been maintaining the site since handoff and whether that was ever part of the deal.

What should a Webflow site's robots.txt say?

A Webflow site's robots.txt should carry a sitemap line and no blanket disallow. Webflow adds the sitemap address on your behalf, stating that "Whether you create or auto-generate your sitemap, Webflow automatically adds your sitemap.xml address to your site's robots.txt file", and the file itself is edited in Site settings, SEO tab, Indexing section (Webflow Help Center, Create a sitemap in Webflow). Reading /robots.txt therefore takes about fifteen seconds: look for a line beginning Sitemap:, and for the absence of Disallow: /.

A missing sitemap line means either the auto-generated sitemap was never switched on or someone edited the file by hand, and both are worth one question. A blanket Disallow: / on a production domain is a different order of problem: it is almost always a rule typed into that field before launch and never taken out. Webflow requires a republish before robots.txt changes take effect, so the rule persists exactly as written until somebody edits it and publishes again, and the site can sit invisible to search for months while everyone blames the content. Finding one is the most consequential result in this list and also the most forgivable, because it says the developer did not own a launch checklist rather than that they cannot build. The useful follow-up is not "why is this here" but "who was supposed to check".

What can you see in a Webflow site's page source?

A Webflow site's page source shows you what was configured, while the design only shows you what was drawn. Three fingerprints are worth searching for on any Webflow build: the Open Graph image format, the Webflow branding markers, and the class names.

• The Open Graph image format. Webflow is explicit that "AVIF and WebP images aren't supported for Open Graph images" and that "only JPG and PNG images are available when choosing from your site's assets" (Webflow Help Center, Control the look of social shares with Open Graph). An og:image pointing at an .avif or .webp file means someone ran the site's assets through image conversion after setting Open Graph, and never reshared a link to check. It is a two-minute fix that nobody made, on a page the developer chose to show you.

• The Webflow branding markers. By Webflow's documentation the "Made in Webflow" badge "will be on by default when you create a new site on all Workspace plans except on the Growth, Agency, and Enterprise plans", and can be hidden with "a Growth, Agency, or Enterprise Workspace plan or a paid site plan" (Webflow Help Center, Webflow branding). Turning the HTML branding setting off removes the comment <!-- This site was created in Webflow. https://www.webflow.com --> from the top of the source. A badge on a live client site is not proof of anything on its own, but it is a plan-level default that a delivery process should have caught.

• The class names. Webflow's own classes always carry a w- prefix, which is why Webflow warns that exported code "may still contain Webflow-specific terms and references, such as class names with the prefix w-" (Webflow Help Center, Webflow branding). Everything without that prefix was named by a person. Reading twenty of those names tells you more about whether a second developer can pick the project up than any case study paragraph will.

What breaks when you resize a Webflow site to 991px, 767px and 479px?

Resizing a Webflow site to its three stacked breakpoints exposes the styling nobody revisited after the desktop layout was signed off. Webflow stacks Tablet at 991px and below, Mobile landscape at 767px and below, and Mobile portrait at 479px and below, and a value set on the Desktop base applies at every one of them unless it is overridden there (Webflow Help Center, Breakpoints overview). Anything that looks wrong at 479px is usually a desktop value that needed overriding twice and was overridden once.

Four symptoms are worth watching for as you drag the window in, and each one points at a different shortcut. A fixed pixel width on a container produces horizontal scroll the moment the viewport is narrower than that value. Absolutely positioned children keep their offsets while everything around them stacks, so they drift across text at the narrowest width first. Grid children placed by explicit column and row do not reflow unless the grid was redefined at each breakpoint, which is the most common reason a two-column section stays two columns on a phone. And an image given a hard height with no object-fit distorts rather than crops. All four are quick to fix during a build and awkward to fix after handoff, which is why finding them at 479px tells you more about the delivery process than about the design.

What does a missing meta description on a portfolio site actually tell you?

A missing meta description tells you far less on its own than a missing title tag does, because the two have very different baselines on the open web. Title tags are present on 98.6% of desktop pages and 98.5% of mobile pages, while meta descriptions are present on 67.7% of desktop pages and 67.2% of mobile pages, according to the 2025 Web Almanac (HTTP Archive, 2025 Web Almanac, SEO chapter). Subtracting the published presence figure from 100 gives roughly one desktop page in three shipping with no meta description at all; that subtraction is mine, the Almanac publishes the presence number only.

Read as a baseline, this is what it means for a portfolio review. A missing title tag is close to a disqualifier, because almost nobody ships without one. A missing meta description on one page is background noise. A missing meta description on every CMS item in a collection is a template that was never configured, which is a different and much more useful finding.

What can you not tell from a Webflow portfolio?

A Webflow portfolio cannot tell you what happened inside the Designer or after the handoff. Class hygiene is partly visible from outside, but component structure, interaction complexity, collection field design and whether the client can safely edit their own content are all invisible from a live URL. So is the thing that matters most commercially, which is what the developer did when the project went sideways. If you are an agency planning to put this person behind your own brand, how that engagement is structured is a separate question, covered in the white label Webflow workflow.

Closing the invisible-work gap is what the rest of the hiring process is for. Performance targets and what to test have their own checklist in the Webflow QA checklist, and what to put to the developer on the call is covered in the questions to ask before hiring a Webflow developer. Credentials are a different signal again, and what Certified Partner status does and does not prove is set out in Webflow expert versus developer.

Where does a portfolio review go wrong?

Five failure modes send a portfolio review to the wrong answer. Each one has a named consequence you will feel later, and a fix that costs nothing at the time.

How do you get a second opinion on a Webflow developer's portfolio?

The quickest second opinion is to have someone run the seven checks alongside you on the specific URLs you are weighing up. Send me the two or three live URLs and I will do exactly that on a 15-minute call, and tell you which findings are build problems, which are plan or client decisions, and which single question to put to the developer next. You will leave with the actual results for your candidates, not a checklist to run yourself. Book the 15 minutes here.